Як говорити про Legacy Code англійською мовою
Вивчіть дипломатичні англійські фрази для обговорення застарілого коду, його ризиків, а також аргументів на користь рефакторингу — без відкидання людей, які його створили.
Розмови про старі коди на диво легко помилитися англійською, тому що природне лексичне володіння для опису старих, важко змінюваних систем може звучати як особиста критика того, хто їх написав — включаючи, іноді, вас самих кілька років тому. Метою є чесне описування ризиків і обмежень без натяку на звинувачення, особливо зважаючи на те, що початкові автори можуть досі бути у вашій команді або у кімнаті.
Опис поточного стану нейтральним чином
Виконувати з фактами, а не судженнями про якість.
- «Цей модуль був написаний до того, як ми встановили конвенцію тестування, тому на даний момент він не має автоматизованого тестування.»
- «Ця система передувала нашим поточним стандартам архітектури — вона була побудована під різними обмеженнями, з іншим масштабом в голові»
- «Цей код зростав органічно протягом декількох років і декількох команд, тому оригінальний намір дизайну не повністю задокументований ніде»
Зміна цін може бути ризикованою
Ризик у рамках властивостей системи, а не компетентності кого-небудь.
- Оскільки тут немає тестового покриття, навіть невелика зміна несе реальний ризик непомітної регресії
- «Бизнес-логіка і доступ до бази даних тісно пов’язані в цьому файлі, тому торкаючись одного часто означає торкаючись іншого, чи ви маєте намір, чи ні.»
- «Існує багато неявної поведінки, закодованої в цій функції, яка не очевидна при її читанні — деякі краї випадки мають сенс тільки після того, як ви знаєте історичний інцидент, який їх спричинив»
Приклади застосування рефракції
Зв’язати технічні аргументи з бізнес-результатами, які цікавлять зацікавлених осіб.
- «Рефакторинг цього модуля зменшить час, який потрібно для доставки пов’язаних функцій, оскільки зараз кожна зміна тут займає приблизно втричі більше часу, ніж очікувалося»
- «У нас було три виробничих інциденти, що походять з цієї області за останні шість місяців — це сильний сигнал, що поточний дизайн досяг своїх меж»
- «Це не про переписування заради самого себе — це про зменшення постійних витрат на кожну майбутню зміну, яка торкається цієї частини системи»
При цьому слід пам’ятати, що цей код є прикладом старого коду
Іноді оригінальний автор присутній, і розмова потребує додаткової уваги.
- «Цей код вирішував справжні проблеми протягом довгого часу — контекст тільки змінився з того часу, і це нормально для будь-якої довговічної системи»
- «Я не ставлю під сумнів оригінальні рішення тут — вони мали сенс, враховуючи те, що було відомо на той час. Я хочу зауважити, що наші поточні обмеження різні»
- «Ніщо з цього не є критикою вас особисто — кожна система цього віку накопичує такий же вид складності, незалежно від того, хто її написав»
Розглянемо інтенсивне покращення
Рідні носії часто оформляють спадщину роботи з точки зору поступових, низькоризичних кроків, а не одного великого переписування.
- «Замість повного переписування, давайте почнемо з додавання тестів характеризації навколо поточної поведінки, щоб майбутні зміни мали безпечну сітку»
- «Ми можемо вирізати один добре визначений модуль за раз і модернізувати його в ізоляції, замість того, щоб ризикувати торкатися всього відразу»
- «Мета цього кварталу не в тому, щоб закінчити рефакторинг — це зробити наступну зміну в цій області значно безпечнішою, ніж остання»
Словник-довідник
| Term | Meaning |
|---|---|
| Technical debt | The implied future cost of choosing a quicker, less ideal solution now |
| Characterization test | A test written to document a system’s current behavior before refactoring it, without judging whether that behavior is correct |
| Tight coupling | When components are so interdependent that changing one frequently requires changing another |
| Big-bang rewrite | Replacing an entire legacy system at once, as opposed to incremental modernization |
| Strangler pattern | Gradually replacing a legacy system by routing new functionality to a new system while the old one shrinks over time |
Ключеві моменти
- Описувати застарілий код за його спостережуваними властивостями (відсутність тестового покриття, тісне з’ єднання, недокументований намір), а не за його якістю.
- Різниця між ризиком та аргументами рефакторингу навколо бізнес-результатів — частота інцидентів, швидкість доставки — не тільки естетичні переваги чистого коду.
- Коли оригінальний автор присутній, явно відокремте «контекст змінився» від будь-яких наслідків про їх компетентність.
- Надавайте перевагу інкрементним поліпшенням мови (тестам характеризації, шаблону душника) над «переписуванням всього», як тому, що це зазвичай кращий план, так і тому, що це простіше зробити.
- Нехай розмова зосереджена на поточних обмеженнях системи, а не на приписуванні відповідальності за те, як вона стала такою.
Навигація Nuance: Специфічний словник для обговорення коду
Ефективне спілкування про застарілий код не просто про те, щоб сказати «це погано». Це тонкий баланс між визнанням його існуючого стану і запропонуванням конструктивних поліпшень. Для не рідних носіїв англійської мови це може бути особливо складним завдяки тонким нюансам професійного словника. Давайте розглянемо деякі конкретні фрази, які допоможуть вам керувати цими розмовами з більшою впевненістю, зосередившись на точності, а не на прямоті.
Однією з ключових областей є опис накопиченого технічного боргу. Замість того, щоб просто сказати «цей код занадто заплутаний», використовуйте більш точні терміни, такі як «кодова база накопичила значний технічний борг», або «є демонстрабельне збільшення складності через минулі рішення». Важливо пояснити * чому * це важливо. Фрази на кшталт «Це впливає на підтримку і вводить потенційні ризики для майбутнього розвитку» є набагато ефективнішими, ніж нечітка критика. Під час перегляду коду, розгляньте можливість використання таких фраз, як « цей розділ може отримати користь від переробки, щоб поліпшити читабельність і зменшити навантаження на когнітивні функції ». Уникайте обвинувачувальної мови; зосередьтеся на * впливі * існуючої структури. Аналогічно, при обговоренні запитів на витягування, сказати «Ця PR вводить значну кількість накопиченого боргу» краще, ніж «Це жахливий код»
Іншим важливим аспектом є обговорення навколо зменшення ризику. Замість того, щоб сказати « цей код небезпечний », спробуйте сказати « Нам слід оцінити потенційні ризики, пов’ язані з продовженням використання цього коду — особливо щодо масштабованості і майбутніх додатків функціональності ». Після цього ви можете розробити: « Потокова архітектура створює проблеми з продуктивністю, і нам слід дослідити стратегії для зменшення цих обмежень ». Крім того, будьте готові обговорити * компроміси *. Поширеною фразою є « Хоча повне переписування вирішить ці проблеми, на даний момент це неможливо через [причину — наприклад, обмеження часу, розподіл ресурсів]. » Це дозволяє вам визнати проблему, пропонуючи реалістичний розв’ язок або пропонуючи поетапні поліпшення. Пам’ ятайте, демонстрація розуміння * бізнес- контексту * зміцнює ваш аргумент; додавання “Це відповідає нашій стратегічній меті мінімізації операційного ризику” може бути неймовірно потужним.
Нарешті, пам’ ятайте, що документація є ключем, особливо, коли йдеться про застарілі системи. Фрази на кшталт « Існуюча документація обмежена і потребує оновлення, щоб точно відображати поточний стан кодової бази » є корисними для ініціювання розмов про передачу знань і поліпшення розуміння. Не бійтеся задати прояснюючі питання; такі фрази, як «Чи можете ви розглянути обґрунтування цього рішення щодо дизайну?» або «Чи можемо ми задокументувати припущення, зроблені під час розробки?» демонструють активний підхід і будують довіру з вашими колегами. Ці невеличкі зміни у словнику можуть суттєво поліпшити ефективність вашого спілкування і допомогти створити середовище для співпраці навіть з найскладнішими базами коду.