Вирішення конфліктів злиття за рахунок рефакторингу

Нещодавно я взяв участь у дискусії про те, як впоратися з рефакторингом взагалі (що саме по собі цікава тема). Врешті-решт виникло таке питання:

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

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

Гарне питання. Найкраща стратегія, яку я можу придумати, - це:

Профілактика

Поєднання безперервної інтеграції та створення невеликих рефакторинга часто (замість випадкових великих рефакторингах) пройде довгий шлях до мінімізації витрат та частоти таких конфліктів.

Я думаю, щоб відповісти на ваше запитання, спершу ми повинні зрозуміти, чому трапляються конфлікти, і який справжній сенс і процес злиття?

Конфлікти виникають тільки тоді , коли два або більше розробників працюють на тому ж файлі в той же час , а потім вони обидва намагаються перевірити. Перший розробник не отримає якийсь - який конфлікт, звичайно. Але другий (третій, четвертий тощо) мав би конфлікти. Чому, оскільки у нього є якийсь код, який частково або повністю відрізняється від існуючого коду на сервері.

Це по суті означає, що другий розробник має на увазі щось інше, ніж перший розробник. Ця різниця може відрізнятися від стилю, наприклад, використовувати new UserManager().GetUserName()замість UserManager userManager = new UserManager(); userManager.GetUserName();до рівня, про який ви згадали, а це означає, що обидва розробники мали різні ідеї, як перефактурувати код, щоб поліпшити його.

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

Наприклад, якщо ви попросите двох розробників покращити бібліотеку онлайн-платежів, і їх робота перекриється, це означає, що принаймні в деяких місцях є 2 різні рішення. Отже, про одне з таких рішень слід обговорити і прийняти, таким чином, зареєструвавшись як найкраще рішення.

Я не згоден щодо запобігання цим обставинам, оскільки ми, як правило, повинні бути більш реальними, ніж теоретичними. Іноді хлопець справді хороший у CSS, тоді як інший дуже хороший у розмітці ASP.NET. Але їх робота може конфліктувати, коли вони повинні працювати на сторінці входу, щоб вона працювала. Я маю на увазі, якщо ми думаємо реально (не ідеально), ми можемо бачити, що багато разів трапляється це явище (конфлікт).

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

Якщо немає активного управління завданнями, у вас виникають конфлікти.

Якщо, однак, у вас є щоденні зустрічі протистояння або керівник , ви не можете мати цю проблему.

Або поговоріть (щоденно встаньте) або поговоріть з менеджером.

Це банально запобігає розмові.

Мати окрему загальну гілку для розробки певної функції, часто зливатися / тягнути / натискати - ось і все.

І спілкуватися . Поговоріть з іншими розробниками про код навіть під час запуску. Навіть при кодуванні)))

Переконайтеся, що злиття є максимально простим. Рефакторинг, як правило, є досить механічним процесом, який змінює багато існуючих рядків : переміщення оголошень змінних, зміни пробілів, форматування, послідовність операцій. Створення функцій, як правило, набагато більш творче починання, що часто призводить до нового коду плюс кілька незначних змін до існуючого коду. Тепер, якщо розробник, який виконує рефакторинг, записує етапи (наприклад, як регулярні вирази), застосувати їх до коду з додатковою функціональністю може бути набагато простіше, ніж навпаки. Виходячи з цього, я б сказав, що як правило, слід застосувати спочатку найскладніші зміни, а потім послідовно простіші зміни.