Как провести рефакторинг в ветке, не сойдя с ума?

Question

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

Решения, которые я знаю, это либо

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

Чем вы занимаетесь?

Answer 1

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

Постоянное объединение с магистралью и из нее, как правило, является хорошей практикой.

Зачем в таком случае вообще работать в филиале?Потому что у вас больше контроля (вы можете остановить слияние с trunk, чтобы стабилизировать его для выпуска, например, не прекращая проверки в вашей ветке разработки).Потому что вы можете обеспечить высокий уровень проверки при слиянии с магистралью / из нее, не сильно влияя на скорость проверки ветки разработки.

Answer 2

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

Answer 3

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

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

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

Answer 4

Изменения должны быть либо быстро (так что не слишком много изменений под вашим руководством) или же Местные новости (таким образом, вас интересуют изменения только в небольшом количестве мест).

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

По сути, вы не можете допустить ситуации, когда 20 программистов в компании каждый день меняют названия 50% методов в базе кода.И если уж на то пошло, если несколько человек всегда проводят рефакторинг в одних и тех же местах в одно и то же время, то они все равно только отменяют работу друг друга.

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

Кроме того, "реорганизовать всю систему, чтобы использовать фабрики повсюду" - это не задача."Рефакторинг этого интерфейса и его реализаций для использования фабрик" - это задача.

Answer 5

Именно в этом преуспевает хорошая распределенная венчурная система.Но я предполагаю, что вы уже привержены SVN.

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

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

Answer 6

Рискуя показаться очевидным, я бы посоветовал вообще избегать ветвления.Объем накладных расходов, к которым это приводит, нельзя недооценивать.Даже если вы думаете, что больше не можете откладывать (выпуск одной системы в производстве, сборка второй версии, но также изменение запросов на выпуск первой), все равно попытайтесь найти другой способ:Действительно ли вы не можете изолировать функциональность без ветвления (напримерразделить "общий" проект и несколько подпроектов)?Неужели вы действительно не можете интегрировать весь код в head (напримерсоздавать классы стратегий, которые учитывают различия, или создавать переключатели для включения или выключения новых функций)?

Если вам обязательно нужно разветвляться, я бы выбрал вариант 1.Старайтесь вносить как можно меньше изменений и делайте это часто.

Answer 7

Совершайте рано, совершайте часто.

Или в данном случае...Объединяйтесь рано, объединяйтесь часто.

Answer 8

Ключом к успеху является непрерывная интеграция...1 небольшая порция изменений за раз...