Как вы управляете рефакторингом с большой базой кода и многими разработчиками?

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

У нас есть 4,5 миллиона строк кода и более 20 команд разработчиков на четырех континентах.

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

Знаете ли вы о решении?

Многие системы контроля версий 2-го поколения работают с использованием подключенной «проверки», которая сообщает серверу, что вы собираетесь изменить файл. Примеры включают TFS, SourceGear Vault и многие другие. Таким образом, вы можете технически выполнить ваше требование. Однако, как отметил Адам Батлер, эти типы инструментов имеют свои собственные проблемы (без долгих споров - ограниченная поддержка автономной работы и, как правило, контрпродуктивный рабочий процесс разработки).

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

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

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

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

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

Если вы уходите notice that someone else is working on the same piece of code and talk to the first one before modifying anything, как вы сказали, вам нужна система контроля версий (CVS / SVN / GIT). Я не уверен, хотя, но если вы хотите включить это, вам понадобятся некоторые продвинутые вещи (какой-то механизм запуска / некоторые пользовательские вещи, возможно).

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

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

Несколько вещей:

1. Отдельные модули для работы над
2. Говоря об изменениях, прежде чем они будут сделаны [со всеми разработчиками]
3. Модульное тестирование [для проверки и предотвращения взлома связанных вещей]
4. Как другие упоминали VCS