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

Question

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

« рефакторинг » преобразует код, чтобы улучшить его дизайн, чтобы снизить стоимость изменений.Без этого вы, как правило, получаете более уродливые кодовые базы, для которых труднее писать тесты.

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

Если какой-либо рефакторинг был выполнен, слияние в «ветвях функций» становится намного сложнее, если не невозможно.

Нужно ли нам просто отказаться от возможности делатьлюбой рефакторинг?

См. также « Как вы справляетесь с напряженностью между рефакторингом и необходимостью объединения ?»

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

В настоящее время существуют некоторые лучшие инструменты слияния (например, SemanticMerge ), основанные на синтаксическом анализе языка, предназначенные дляиметь дело с кодом, который был перемещен и изменен.JetBrains (создатель ReShaper) только что опубликовал блог по этому вопросу.

За многие годы было проведено множество исследований , наконец, некоторые продуктывыход на рынок.