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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Любая работа, которая не проверена, может быть потеряна - ваш компьютер может иметь катастрофический сбой. В этом случае, чем дольше вы ждете, тем больше работы вы теряете.
2. Чем больше работы вы выполняете без регистрации, тем больше кода нужно будет интегрировать другим, когда вы наконец решите, что он запекается. Это повышает вероятность возникновения конфликтов и проблем слияния.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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