Рефакторинг и контроль версий: как это сделать?

Что ж, на практике это редко бывает проблемой. Обычно разные члены команды работают над разными областями кода, поэтому конфликта нет. Кроме того, основная часть рефакторинга будет выполняться, когда вы выполняете свой TDD (что может быть даже до того, как вы вернете свой код, но определенно до того, как другие начнут его использовать и изменять).

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

Небольшие изменения совершаются часто.

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

Конечно, никто не сказал, что это будет легко.

Коммуникация.

Инструменты не могут решить эту проблему, если только конкретный инструмент не является вашим почтовым или мгновенным клиентом.

Это то же самое, как если бы вы вносили какие-либо другие важные изменения в общий проект - вы должны иметь возможность сказать своим коллегам / соавторам: «Эй, руки на пару часов, у меня скоро появятся большие изменения в модуле FooBar. в".

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

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

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

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

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

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

По моему опыту, конфликты слияния редко становятся проблемой при малом и среднем рефакторинге гибких проектов. Большие усилия по рефакторингу могут вызвать некоторую боль при слиянии, но если он выполняется небольшими порциями, боль можно значительно уменьшить. Боль при слиянии также можно уменьшить, используя Subversion в качестве SCM, поскольку SVN автоматически объединяет неконфликтные изменения.

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

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

• Почему 10 человек одновременно меняют один и тот же код?
• Есть ли более эффективные инструменты, которые помогут вам при рефакторинге / слиянии (возможно, распределенный контроль версий)?

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

С уважением

Когда я думаю, что рефакторинг будет сложно объединить, я делаю следующее:

1. Предупредить мою команду о приближении изменения и проверить, есть ли ожидающие изменения, которые будет сложно объединить.
2. Убедитесь, что я понимаю изменение, которое собираюсь внести, чтобы я мог сделать это быстро. При необходимости увеличьте охват тестированием прямо сейчас.
3. Синхронизируйте мою машину с последним источником.
4. Рефакторинг, тестирование и фиксация.
5. Сообщите моей команде, чтобы они синхронизировались с моими изменениями.

Обратите внимание: я вношу изменения в рефакторинг отдельно от функциональных изменений.