Является ли фиксация / проверка в коде каждый день хорошей практикой?

63

Я читал заметку Мартина Фаулера о непрерывной интеграции, и он в обязательном порядке перечисляет «Каждый человек присоединяется к главной линии каждый день».

Я не люблю фиксировать код, если раздел, над которым я работаю, не завершен и на практике я фиксирую свой код каждые три дня: один день для исследования / воспроизведения задачи и внесения некоторых предварительных изменений, второй день для завершения изменений и третий день, чтобы написать тесты и очистить его ^ для представления. Я не чувствую себя комфортно, отправляя код раньше.

Теперь я извлекаю изменения из репозитория и интегрирую их локально, как правило, два раза в день, но я не делаю это часто, если не смогу выполнить меньшую часть работы.

Вопрос: является ли ежедневное совершение такой хорошей практикой, что я должен изменить свой рабочий процесс, чтобы приспособиться к нему, или это не рекомендуется?

Изменить: Я думаю, я должен был уточнить, что я имел в виду «совершать» в значении этого CVS (он же «толчок»), так как это, вероятно, то, что Фаулер имел бы в виду в 2006 году, когда он написал это.

^ Порядок является более произвольным и зависит от задачи, моя цель состояла в том, чтобы проиллюстрировать промежуток времени и действия, а не точную последовательность.

санки
источник
20
Вы можете зафиксировать свой код, если он компилируется и выполняет некоторую полезную логику. Лучше делать код короткими циклами, если вы работаете в командной среде.
Е.Л. Юсубов
4
Мартин Фаулер предполагает VCS, который не распространяется?
user16764
4
Обратите внимание на дату этой статьи: 1 мая 2006 года. Git и Mercurial даже не начались до апреля 2005 года, и у меня сложилось впечатление, что они действительно начали набирать обороты примерно в 2008 году. Я не могу найти на сайте Фаулера никаких статей, которые ссылаются на к одному из них до 2009 года. Таким образом, эта статья 2006 года явно предполагает централизованную систему контроля версий, такую ​​как SVN. Совет не распространяется на команды, использующие DVCS.
Kyralessa
2
@Kyralessa: В статье даже говорится, что «Subversion - это современная [система контроля версий]».
Че
4
Сначала код, а затем тесты?

Ответы:

43

Я не согласен с этим правилом и согласен с тем, что сказал Мейсон Уилер . Я хотел бы добавить несколько идей.

Я пытаюсь выполнить фиксацию каждый раз, когда у меня есть значимое изменение для фиксации: это может происходить несколько раз в день, если я исправляю несколько небольших ошибок, или раз в неделю, если я работаю над большим программным обеспечением, которое не может использоваться остальными код любым значимым способом, пока он не достигнет согласованного состояния.

Кроме того, я интерпретирую фиксацию как публикацию значимой ревизии, которая вносит новые функциональные возможности в базу кода. Я думаю, что нужно попытаться очистить код перед фиксацией, чтобы другие разработчики могли понять значение и цель изменений, когда они смотрят историю изменений. Чем меньше изменений видят другие разработчики в истории, тем лучше: когда я смотрю историю изменений, я хочу видеть приращения, которые добавляют значимую функциональность; Я не заинтересован в каждой маленькой идее, которую каждый разработчик имел и хотел попробовать, прежде чем они достигли решения.

Кроме того, я не думаю, что было бы хорошей идеей использовать сервер SVN (или любую другую систему управления версиями) в качестве средства резервного копирования, для которого передается текущий снимок кода (при условии, что он компилируется): вы можете использовать USB-накопитель или внешний USB-накопитель или сетевой диск для зеркалирования текущего кода, чтобы он не потерялся в случае поломки компьютера. Контроль версий и резервное копирование данных - это две разные вещи. Публикация ревизии - это не то же самое, что сохранение снимка кода.

Наконец, я думаю, что не должно быть проблемой фиксировать время от времени (т. Е. Только тогда, когда кто-то действительно удовлетворен текущим состоянием кода), и избегание конфликтов слияния не является хорошим оправданием для частой фиксации (слишком). Многие конфликты слияний происходят, когда разные люди работают с одними и теми же файлами одновременно, что является плохой практикой (см., Например, эту статью , пункт 7). Конфликты слияний должны быть уменьшены путем разделения проекта на модули с понятными интерфейсами и как можно меньшим количеством зависимостей, а также путем координации работы разработчиков так, чтобы код, над которым они работают, перекрывался как можно меньше.

Просто мои 2 цента.

РЕДАКТИРОВАТЬ

Другая причина против преждевременных коммитов, которая пришла мне в голову, заключается в том, что (очень) ошибочную версию нельзя проверить. Если вы делаете коммит на транке, а ваша группа тестирования проводит тестирование каждый день, у них может не быть тестируемой версии в течение нескольких часов (или в течение дня). Даже если вы не попытаетесь исправить ошибку и просто отменить изменения, восстановление может занять несколько часов. С пятью тестерами, работающими в вашей команде, вы потратили 5 х 2 = 10 часов времени команды из-за неактивности. Это случилось со мной однажды, поэтому я действительно стараюсь избегать преждевременных коммитов во имя коммитов как можно скорее .

Джорджио
источник
23
«Коммит» - это не «публикация». «Фиксация» означает «снимок»; «публикация» называется «push» в scm-lingo. Конечно, SVN просто объединяет обе концепции в одно, делая многие разумные рабочие процессы невозможными, но это ограничение инструмента, а не рабочих процессов управления исходным кодом в целом.
tdammers
3
Revision control and data backup are two different thingsДа, я определенно чувствую это.
Сани
1
@tdammers: я имел в виду публикацию неофициальным способом: пока код находится на моем компьютере, это мои личные изменения в общем коде. Как только я фиксирую это, он публикуется, известен остальной части команды и является частью официальной истории проекта.
Джорджио
1
В этом случае «коммит», вероятно, неправильное слово. Многие SCM допускают локальные коммиты, и обмен вашим кодом с остальной частью команды - это отдельное действие, обычно называемое «push». Опять же, SVN объединяет две концепции вместе, но это является ограничением инструмента, и если он мешает вашему рабочему процессу, подумайте о переключении на другую SCM.
tdammers
@tdammers: Иметь четкое различие между локальной фиксацией и публикацией было бы шагом вперед. В SVN я могу использовать для этого отдельную ветку. Но опять же, мне интересно, почему я хотел бы отслеживать изменения, которые не имеют большого смысла для меня? Я не уверен, что хочу новую ревизию (даже частную) только потому, что сейчас 5 часов и я иду домой. Я предпочитаю иметь резервную копию вместо этого.
Джорджио
107

Я фиксирую код несколько раз в день . Всякий раз, когда я достигаю точки, когда код достаточно полон, чтобы компилировать и не ломать другие вещи, это происходит.

Вам следует подумать о том, чтобы прервать работу, чтобы вы могли безопасно регистрироваться несколько раз в день.

Основания для этого два:

  1. Любая работа, которая не проверена, может быть потеряна - ваш компьютер может иметь катастрофический сбой. В этом случае, чем дольше вы ждете, тем больше работы вы теряете.
  2. Чем больше работы вы выполняете без регистрации, тем больше кода нужно будет интегрировать другим, когда вы наконец решите, что он запекается. Это повышает вероятность возникновения конфликтов и проблем слияния.
Одед
источник
2
Если у вас есть серьезные проблемы с конфликтами и проблемами слияния, это означает, что ваш менеджер проекта не выполняет свою работу. Множество случаев, связанных с похожей функциональностью, должны передаваться одному и тому же разработчику, чтобы у вас не было двух или более кодеров, мешающих работе друг друга.
Мейсон Уилер
14
@MasonWheeler - после 3 дней работы, которая еще не была совершена, очень велика вероятность того, что один из них коснулся кода, который есть у других одновременно. Если у вас есть куча программистов, делающих это, то лучший менеджер проекта не сможет избежать возникновения конфликтов.
Одд
3
@Oded: Возможно. Я предполагаю, что мой ответ окрашен моим опытом работы с достаточно большой кодовой базой, так что все наши разработчики (около дюжины программистов в команде), как правило, имеют непересекающиеся обязанности. Не уверен, насколько он будет отличаться от небольших проектов.
Мейсон Уилер
3
@ArtB - Что делать, если есть кто-то вроде вас, который проверяет только каждые 3 дня? Или раз в неделю? Вы полагаетесь на то, что другие поступают правильно.
Отредактировано
3
Когда я прочитал вопрос, мой ответ был «это все равно что спросить, если это хорошая идея, чтобы принимать душ каждую неделю»?
Эндрю Гримм
39

Рабское следование любой методологии или практике без понимания причин, стоящих за ней, никогда не будет хорошей идеей. Вот откуда берутся культовые программы.

Поэтому «я должен совершать каждый день, потому что так сказал Мартин Фаулер», просто глупо. И иногда это тоже непрактично. Если вы работаете над сложной новой функцией, вы, возможно, не достигнете точки, в которой стоит зарегистрироваться, пока вы не поработали над ней в течение нескольких дней.

Это не означает, что вы должны убедиться, что все идеально, прежде чем проверить это. Это хороший способ потерять работу, если что-то пойдет не так. Правильная вещь, чтобы сделать, это разработать и использовать здравое суждение по этому вопросу Эмпирические правила могут только вам очень помочь.

Мейсон Уилер
источник
1
Тогда, если это сложная интеграция / разработка функций, все еще большая потеря не в том, чтобы фиксировать это, может быть, не в магистраль, а по крайней мере в ветке для этой функции, вот для чего нужны ветки!
Винсент Б.
2
Что вы имеете в виду «стоит проверить»? Если это не нарушает чужой код, почему бы вам не проверить это?
Кирк Бродхерст
2
«Что вы имеете в виду« стоит проверить »? Если это не нарушает чей-либо код, почему бы вам его не зарегистрировать?»: Потому что я не хочу хранить старые копии кода только потому, что они существовали в некоторых момент времени. Я также хочу сохранить старую копию кода, если он содержит некоторую полезную информацию, которую я мог бы получить в будущем. В противном случае я просто создаю бесполезный шум в истории изменений.
Джорджио
3
+1. Однажды я работал в команде, где нам приходилось каждый день проверять код в VCS, даже если этот код был скачком или бесполезным расследованием. Это оказалось неэффективным и расточительным, особенно потому, что требовалось периодическое обслуживание для очистки VCS. Это произошло из-за сочетания паранойи из-за потенциального риска потерять немного времени, чтобы что-то переделать, и из-за того, что менеджер прочитал в книге, которую вы должны совершать каждый день. Возможно, это крайний пример, но если серьезно, если вы не знаете, стоит ли проверять что-то, вы, вероятно, плохо подходите для этой работы.
С.Робинс
14

Одед дал две важные причины, чтобы сделать код как можно чаще. Я добавлю еще несколько:

  1. При работе с вашим фрагментом кода другим может потребоваться некоторые функции для этого кода. Они не должны ждать 6 дней, чтобы получить это. В этом случае мои коллеги обычно создают прототип в моем фрагменте кода, фиксируют его, я добавляю тело и фиксирую его снова. И это обычно делается за несколько часов.

  2. «Общий» код предназначен для того, чтобы каждый мог увидеть каждое изменение как можно скорее. Если часть кода, над которой вы работаете, полностью отделена от работы других, и вам не придется их ждать, то рекомендуется создать ветку, над которой вы будете работать, а затем, если все прошло успешно, объединить ее с основная линия.

superM
источник
1
Почему этот ответ с (ИМО) является единственным правильным и точным ответом (пункт 2) с таким низким рейтингом? Конечно, это точка ветви! @ Мейсон Уилер: Итак, вам нравится писать несколько дней подряд без коммитов? Тогда зачем использовать систему контроля версий ?!
Винсент Б.
2
Это правильный ответ. Если ваша задача состоит в том, чтобы проделать много дней, прежде чем ее можно будет использовать, тогда ответвьте. В противном случае вы фиксируете всякий раз, когда это работает, чтобы убедиться, что члены группы имеют последнюю версию, они могут проверить, работает ли она, и идентифицируют добавленные / отсутствующие функции как можно скорее.
Кирк Бродхерст
«Таким образом, вам нравится кодировать несколько дней подряд без единовременного коммита? Тогда зачем использовать систему контроля версий? Скорее, вам решать, совершать ли вы несколько раз в день или работаете три дня подряд без обязательств. Я действительно не вижу смысла в фиксации какой-то незаконченной функции, которую никто не может использовать: просто сделайте резервную копию, на следующий день вы можете закончить ее и зафиксировать.
Джорджио
8

Я твердо верю в совершение каждого логического изменения, которое стоит сохранить. Зафиксируйте часто, и если код не стоит хранить, верните его в чистое состояние. Чем дольше вы ждете, чтобы отправить / опубликовать свой код обратно, тем сложнее его реализовать и тем больше проблем вы столкнетесь. Вы также получите отзывы о ваших взносах намного быстрее:

  • они ломают сборку?
  • Вы дублируете усилия другого члена команды?
  • вы делаете что-то неправильно?
  • или люди ждут от тебя чего-то?

Небольшие изменения намного проще в управлении.

Также стоит отметить разницу между разными системами контроля версий. Некоторые из них, такие как Git (распределенный), позволят вам фиксировать и контролировать всю историю локально, только когда вы готовы к публикации. Другие, такие как SVN (централизованный), объединят два шага, делая маленькие коммиты очень неэффективными.

Не забывайте, что ваши коммиты по сути меняют документацию. Когда дела пойдут не так, вы будете рады иметь больше истории, чем недостаточно. Один коммит на недельную работу кажется мне бесполезным. Я бы просто прочитал каждую измененную строку кода, а не сводку по каждому логическому фрагменту.

Адриан Шнайдер
источник
5

Я думаю, что большинство ответов здесь пропускает один из основных пунктов в заявлении Мартина Фаулера. Это связано с непрерывной интеграцией . Код, который не проверен (помещен / опубликован / объединен) в основную линию, не проверяется.

Это не должно восприниматься как побуждение к принятию любого кода, который вы имеете на своем локальном компьютере, всякий раз, когда пора выходить из офиса. Как указали здесь несколько других, это было бы плохо, могло нарушить сборку и вызвать нестабильную магистраль.

Тем не менее, рекомендуется попытаться вносить изменения небольшими шагами, которые можно зарегистрировать на главной линии, не вызывая проблем. Это стимулирует развитие кода, а не разрывает его на части и переписывает.

Теперь, что хорошего в этом способе работы?

  1. Отсутствие больших фрагментов кода или революционных изменений снижает вероятность поломки сборки.
  2. Если ваш коммит нарушает сборку, то довольно просто определить, в чем проблемы, отменить его и затем быстро зафиксировать фиксированную версию.
  3. Убедившись, что все тесты выполняются для каждого небольшого изменения в коде, вы гарантируете, что не будете вводить тонкие ошибки или регрессии, которые могут возникнуть из-за того, что код выходит за пределы схемы непрерывной интеграции.

Конечно, не все изменения поддаются такому подходу. Как отмечали другие, ни одно правило не является абсолютным. Однако для изменений, которые, как ожидается, будут оставаться вне основной линии в течение длительного времени, создайте альтернативную главную линию со своей собственной схемой непрерывной интеграции и следуйте тому же подходу к ней. С сегодняшними распределенными VCS это довольно легко сделать.

Harald
источник
+1: «Конечно, не все изменения поддаются такому подходу». Я думаю, что это точка. Я нахожу совет Фаулера в порядке, но нужно судить от случая к случаю. Вместо этого этот совет часто обобщается до абсолютного правила и применяется без дальнейшего рассмотрения.
Джорджио
@ Джорджио, я абсолютно согласен с тобой в этом. Ни один совет не должен восприниматься как абсолютные правила, независимо от того, кто стоит за ним.
Геральд
Еще несколько идей по этому поводу. «Код, который не проверен (помещен / опубликован / объединен) в основную линию, не проверен». Я согласен с тем, что это хороший принцип, и не следует ждать несколько недель, прежде чем регистрироваться и проверять свой код. Однако слепое применение этого принципа может привести к сломанному приложению , которое не может даже быть проверено (я видел это вживый: вся команда испытателей простаивает в течение нескольких дней и не может проверить что - либо пока код не будет возвращен в работоспособное состояние). Может быть, то, что написали другие пользователи, применимо к некоторым ситуациям, но это не так.
Джорджио
1
Проверка в нестабильном коде никогда не подходит. Коммит, который нарушает CI, должен быть возвращен. Если вы часто вносите небольшие инкрементные изменения, вероятность такого разрушения меньше, чем если бы у вас было большое изменение, которое оставалось непроверенным в течение длительного времени. Также может быть легче вернуться, если это нарушит сборку. Но, как вы говорите, иногда нет выхода за рамки разрушительных изменений. Затем, во что бы то ни стало, отполируйте его как можно лучше и тщательно протестируйте перед его использованием. Дело не в следовании правилам, а в понимании того, откуда приходит совет.
Геральд
3

Аргументы для проверки каждый день:

  • Код хранится и резервируется от сбоя жесткого диска
  • Активность может быть записана в заметках коммитов ( что я делал в четверг ...? )
  • Интеграция с существующей кодовой базой происходит раньше и небольшими порциями, мы надеемся выявить конфликты или проблемы слияния раньше
  • Ваша команда видна из того, над чем вы работали
  • Ваши коллеги могут быстрее работать с вашими интерфейсами, предоставляя им больше времени для интеграции с вашим «большим сложным фрагментом кода».
  • Ваш код будет проверен в реальных условиях раньше или, по крайней мере, подвергнется большему использованию, чем вы дадите, что приведет к более раннему выявлению ошибок или упущений.

Аргументы против проверки каждый день:

  • Не нужно или не хочу
  • Мой код еще не очищен, это беспорядок
  • Нет времени

Я не верю, что есть какая-либо веская причина регистрироваться менее, чем ежедневно, кроме лени или дезорганизации. Нет ничего хуже, чем видеть, что код, выполняемый в среде разработки, не соответствует коду в ветви разработки, потому что кто-то «еще не закончил» и, следовательно, не зарегистрировался.

Я хотел бы ошибиться в этом, поэтому, пожалуйста, дайте мне знать любой законный аргумент против ежедневной регистрации.

Кирк Бродхерст
источник
«Я не верю, что есть какая-либо веская причина регистрироваться менее, чем ежедневно, кроме лени или дезорганизации». Я верю в противоположность по той же причине. Я могу потратить время, чтобы посмотреть на текущее состояние кода и решить, содержит ли он некоторую релевантную информацию, которую стоит запомнить, или, если я ленив и неорганизован, я могу просто проверить это (и произвести дополнительные ревизии с небольшим количеством информации содержание), пока он компилируется.
Джорджио
1
Я понимаю вашу точку зрения, что не следует лениться и каждый день очищать свой код, чтобы его можно было проверить. С другой стороны, при работе над некоторым сложным кодом этого трудно достичь, поскольку очистка может занять несколько часов. , и вы не можете тратить несколько часов каждый день только на очистку вашего кода.
Джорджио
@ Джорджио Так ты тратишь несколько дней на очистку своего кода? Я привел несколько веских причин для ежедневной регистрации - ваша причина в том, что вам придется убирать свой код? Просто напишите более чистый код.
Кирк Бродхерст
Это не всегда возможно, например, если я разрабатываю с нуля какой-то сложный код (> 4000 LOC), который требует много экспериментов, чтобы получить право. Вполне возможно, что в конце дня код немного запутан, и я не хочу его исправлять, пока не доберусь до согласованного состояния, что происходит пару дней спустя. К сожалению, я не настолько умен, чтобы закончить, идеальный код формируется у меня в голове, и я всегда могу записать все это за несколько часов (то есть в конце одного дня). У меня был такой опыт в последнее время, и типичный цикл разработки (от одного непротиворечивого состояния до следующего) составлял 2, 3 дня.
Джорджио
@ Джорджио, у вас нет ветки разработки, в которую вы заходите? Код должен быть зарегистрирован, чтобы другие люди могли просматривать и тестировать его.
Кирк Бродхерст
2

Если вы имеете в виду «зафиксировать» как «объединить в основную линию», то вам определенно не следует делать это каждый день в программном проекте, который предоставляется заказчикам. Вы должны объединить изменения, которые сделаны и протестированы, чтобы основная линия всегда работала и была доступна, а не в неработающем состоянии с полуфабрикатами.

Однако роскошь работы с сегодняшним распределенным управлением версиями заключается в том, что вы можете поддерживать стабильную работу магистрали и в то же время выполнять git/hg/whatever commitкаждый раз, когда чувствуете, что хотите сохранить положение вещей. Я делаю это раз в несколько часов и определенно в конце каждого дня.

С помощью DVCS вы можете публиковать свои работы, совместно работать над ними с другими членами вашей команды и получать информацию об изменениях в основной ветке. Вы можете делать все это без ущерба для стабильности кода, от которого зависят ваши клиенты и / или другие команды.

Во времена, когда Subversion была новейшей технологией, и не было возможности разветвить и объединить ветки объектов без особой боли, лучше всего было бы использовать магистраль, в которой одновременно находилось несколько различных функций. Но это превосходство не масштабируется после 2010 года.

че
источник
2

В Team Foundation Server вы можете «отложить», что не совпадает с регистрацией, но просто делает резервную копию вашего кода, чтобы, если ваша машина умирает, вы не потеряли изменения.

Я также видел дома разработчиков программного обеспечения, у которых есть «линия разработчиков» и «основная линия». Разработчики могут свободно заходить на линию разработчиков, когда сочтут это нужным, и только руководитель группы имеет доступ к основной строке, поэтому он отвечает за копирование кода с dev на main, когда он будет готов к работе.

Мэтт Вилко
источник