Як вам керувати рефакторингом з великою базою коду та багатьма розробниками?

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

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

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

Ви знаєте рішення?

Багато систем управління джерелами 2-го покоління працюють за допомогою підключеної "каси", яка повідомляє сервер, що ви маєте намір змінити файл. Приклади включають TFS, SourceGear Vault та багато інших. Таким чином ви можете технічно виконати свою вимогу. Як зазначав Адам Батлер, ці інструменти мають власні проблеми (не вступаючи в тривалі дискусії - обмежена підтримка роботи в режимі офлайн і взагалі контрпродуктивний робочий процес розвитку).

Я б напевно запропонував би якийсь ієрархічний підхід до розподілу роботи рефакторингу. Розробники можуть бути логічно згруповані в підгрупи, кожна з яких відповідає за конкретні області коду. Залежно від того, як вам подобається структурувати команди, кожна з них може мати роль "провідної", яка відповідає за високий рівень дизайну району команди. Ця структура повинна бути добре відома розробникам, і вона повинна спростити спілкування для рефакторингу. Я впевнений, що такий підхід для деяких видається занадто формальним і зворотним, але я вважаю, що переважніше, ніж 20+ розробників використовувати підхід «безкоштовно для всіх» для рефакторингу великої системи. Деякі реконструкції відбуватимуться на високому рівні (наприклад, як модуль X спілкуватиметься з модулем Y), в такому випадку вам знадобляться люди, які можуть телефонувати на відповідному рівні. Не кожен розробник в команді повинен приймати архітектурні рішення, тому ієрархія майже не нав'язується в будь-якому випадку, навіть якщо хтось вирішить не знати про це.

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

1. Переконайтеся, що розробникам призначені конкретні модулі.
2. Майте систему відстеження завдань / помилок, яка відстежує кожну зміну рефакторингу. Призначте кожну проблему лише одному розробнику
3. Деякі системи контролю версій мають можливість блокувати файл, щоб лише один розробник міг мати права на оновлення файлу. Я ніколи не використовував цю функцію, але якщо розробники постійно наступають один на одного, це, можливо, ви хочете розглянути.
4. Проведіть одиничні тести, щоб навіть якщо розробники працюють над одним файлом, ви знаєте, що їх зміни не порушують додаток жодним чином.
5. Все вищесказане допоможе, якщо ваш рефакторинг міститься в модулях. Однак якщо хтось зробить рефакторинг на наскрізну проблему, таку як реєстрація або безпека, це вплине на багато файлів за визначенням. З цим потрібно поводитися обережно, особливо якщо ви вже не скористалися Aop підходами.

Існують / були системи контролю версій, які виробляють код розробників на замовлення, перш ніж вони можуть редагувати, але у них є власний набір проблем. Краща практика - змусити розробників брати на себе зобов’язання та часто оновлювати їх. Один розробник може потім позначити клас як амортизований та взяти на себе зобов’язання, якщо інший розробник оновиться, перш ніж запустити рефактор, він побачить наміри.

Технологія не може вирішити соціальні проблеми. Потрібно змусити своїх розробників поговорити між собою та координувати їх роботу. З 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