Кращі практики перейменування, рефакторингу та зміни змін у командах

Які найкращі практики щодо рефакторингу та перейменування в командному середовищі? Я придумую це з урахуванням кількох сценаріїв:

1. Якщо бібліотека, на яку зазвичай посилаються, відремонтована, ввести нескінченну зміну в будь-яку бібліотеку чи проект, на який посилається. Наприклад, довільно змінюючи назву методу.

2. Якщо проекти будуть перейменовані і рішення повинні бути відновлені з оновленими посиланнями на них.

3. Якщо структура проекту буде змінена на "більш організовану", вводячи папки та переміщуючи існуючі проекти чи рішення на нові місця.

Деякі додаткові думки / запитання:

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

2. Хто повинен брати на себе відповідальність за виправлення помилок, пов’язаних із переломною зміною? Якщо розробник вніс невід'ємні зміни, чи повинні вони нести відповідальність за потрапляння в порушені проекти та їх оновлення, або вони повинні попереджати інших розробників і спонукати їх змінити речі?

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

4. Це питання формального процесу спілкування чи це може бути органічно?

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

Отже, порада номер один щодо Мартіна Фаулера - не публікувати ваші інтерфейси (назви проектів та структури) передчасно .

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

Також, якщо можливо, розгляньте можливість додавання нового методу (знецінюючи існуючий) замість перейменування існуючого. Це гарантує, що клієнтський код не порушується, і надає перехідний період для оновлення коду для відповідності останньому API. Недолік - це те, що він ускладнює ваш API. Хоча стан є лише тимчасовим, однак це може зайняти чимало часу, перш ніж можна безпечно видалити застарілі методи API (у випадку бібліотеки класів Java, років).

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

Зауважте, що це одна з основних причин наявності сервера збірки, який виконує тести.

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