Совместимо ли использование «функциональных веток» с рефакторингом?

Ветви функций, безусловно, значительно усложняют рефакторинг. Они также усложняют такие вещи, как непрерывная интеграция и развертывание, поскольку вы увеличиваете количество параллельных потоков разработки, которые необходимо создать и протестировать. Вы также избегаете центрального принципа «непрерывной интеграции» - что все работают над одной и той же кодовой базой и «непрерывно» интегрируют свои изменения с остальными изменениями в команде. Как правило, когда используются функциональные ветки, функциональная ветвь не создается или тестируется постоянно, поэтому первый раз, когда код «функциональной ветки» запускается в процессе производственной сборки / тестирования / развертывания, это когда он «готов» и объединен. в багажник. Это может создать целый ряд проблем на позднем и критическом этапе вашего процесса разработки.

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

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

Мне нравится этот провокационный тезис (отказ от рефакторинга), потому что он обогащает дискуссию :)

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

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

• В функциональных ветках я провожу рефакторинг только в том случае, если они подготавливают мою функцию к тому, чтобы ее было легче реализовать. Я всегда стараюсь сосредоточиться только на функции. Ветви должны как минимум отличаться от ствола / основной линии.
• Если взять обратное, у меня иногда даже есть ветки рефакторинга, где я выполняю более крупные рефакторинги (возвращение нескольких шагов очень просто, и я не отвлекаю своих коллег по магистрали). Конечно, я скажу своей команде, что я делаю этот рефакторинг и пытаюсь спланировать его во время цикла разработки очистки (назовите это спринтом, если хотите).
• Если упомянутая вами политика важна, я бы инкапсулировал усилия по рефакторингу внутри компании и добавил бы их к оценке. На мой взгляд, клиенты со средним рейтингом увидят более быстрый прогресс при более высоком качестве кода. Скорее всего, они не поймут рефакторинг (что имеет смысл, потому что это выходит за их рамки ...), поэтому я скрываю это от них
• Чего я бы никогда не сделал, так это рефакторинга ветки выпуска, целью которой является стабильность. Здесь разрешены только исправления ошибок.

В заключение я бы планировал свои рефакторинги в зависимости от кодовой строки:

• feature-branch: только более мелкие (если они "помогают" моей функции)
• refactoring-branch: для более крупных, где цель рефакторинга не совсем ясна (я часто называю их «каракулями рефакторинга»)
• trunk / mainline: Хорошо, но мне нужно общаться с разработчиками по функциональным веткам, чтобы не создавать кошмар интеграции.
• релиз-ветка: никогда

Рефакторинг и слияние - это две комбинированные темы, на которые фокусируется внимание Plastic SCM. Фактически, есть две важные области, на которых нужно сосредоточиться: первая - это работа (во время слияния) с файлами, которые были перемещен или переименован в ветке. Хорошая новость заключается в том, что все SCM «нового века» позволяют делать это правильно (Plastic, Git, Hg), в то время как старые просто терпят неудачу (SVN, Perforce и даже более старые).

Другая часть имеет дело с отредактированным кодом внутри того же файла: вы знаете, вы перемещаете свой код, а другой разработчик модифицирует его параллельно. Это более сложная проблема, но мы тоже уделяем ей внимание с помощью нового набора инструментов слияния / сравнения. Найдите информацию о xdiff здесь и xmerge (cross- объединение) здесь. Хорошее обсуждение того, как найти здесь перемещенный код (по сравнению с "за пределами сравнивать").

В то время как проблема «слияния каталогов» или структуры является ключевой (независимо от того, делает ли это система или нет), вторая проблема больше связана с инструментарием (насколько хороши ваши инструменты трехстороннего слияния и сравнения). Вы можете получить Git и Hg бесплатно для решения первой проблемы (и даже Plastic SCM теперь тоже бесплатен).

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

Теперь есть несколько более совершенных инструментов слияния (например, SemanticMerge), которые основаны на синтаксическом анализе языка и предназначены для работы с кодом. который был перемещен и изменен. JetBrains (создание ReShaper) только что опубликовал person Ian Ringrose    schedule 16.07.2014