Я хотел бы предотвратить ситуацию, когда два разработчика проводят рефакторинг одного и того же кода одновременно, не говоря об этом сначала, возможно, используя какой-то инструмент, возможно, плагин Eclipse. Вы можете помочь?
У нас есть 4,5 миллиона строк кода и более 20 команд разработчиков на четырех континентах.
В идеале я хотел бы, чтобы второй из упомянутых ранее разработчиков заметил, что кто-то еще работает над тем же фрагментом кода, и поговорите с первым, прежде чем что-то модифицировать.
Знаете ли вы о решении?
refactoring
Роджер К.С. Вернерссон
источник
источник
Ответы:
Многие системы контроля версий 2-го поколения работают с использованием подключенной «проверки», которая сообщает серверу, что вы собираетесь изменить файл. Примеры включают TFS, SourceGear Vault и многие другие. Таким образом, вы можете технически выполнить ваше требование. Однако, как отметил Адам Батлер, эти типы инструментов имеют свои собственные проблемы (без долгих споров - ограниченная поддержка автономной работы и, как правило, контрпродуктивный рабочий процесс разработки).
Я бы определенно предложил какой-то иерархический подход к распределению работы по рефакторингу. Разработчики могут быть логически сгруппированы в подгруппы, каждая из которых отвечает за определенные области кода. В зависимости от того, как вам нравится структурировать команды, у каждого из них может быть «ведущая» роль, которая отвечает за высокоуровневый дизайн области команды. Эта структура должна быть хорошо известна разработчикам, и она должна упростить взаимодействие для рефакторинга. Я уверен, что этот подход для некоторых кажется слишком формальным и обратным, но я думаю, что более 20 разработчиков должны использовать «бесплатный для всех» подход к рефакторингу большой системы. Некоторые рефакторинги будут проходить на высоком уровне (например, как модуль X будет взаимодействовать с модулем Y), в этом случае вам понадобятся люди, которые могут звонить на соответствующем уровне. Не каждый разработчик в команде должен принимать архитектурные решения, поэтому иерархия почти навязывается в любом случае, даже если кто-то не знает об этом.
Таким образом, в основном, есть инструменты для удовлетворения основных требований, которые вы выдвинули, но ни один инструмент не заменит надлежащих коммуникаций и будет иметь небольшое количество людей, управляющих общей архитектурой вашего проекта.
источник
источник
Существуют / были системы контроля версий, которые заставляют разработчиков проверять код, прежде чем они смогут редактировать, но у них есть свои проблемы. Лучше практиковаться в том, чтобы разработчики часто фиксировали и обновляли. Один разработчик может затем пометить класс как устаревший и зафиксировать, а затем, если другой разработчик обновится до того, как запустит свой рефакторинг, он увидит намерение.
источник
Технология не может решить социальные проблемы. Вы должны заставить своих разработчиков общаться друг с другом и координировать их работу. С 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 - это огромная песочница для игры, поэтому в хорошо спроектированном и спроектированном решении вы редко сталкиваетесь с ситуацией, когда несколько команд разработчиков сталкиваются друг с другом. Тот факт, что это происходит более чем случайно, говорит о некоторых серьезных потенциальных недостатках дизайна, которые следует рассмотреть.
источник
Несколько вещей:
источник