Як говорити про рефакторинг пріоритетів в англійській мові

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

Ключовий словник

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

** Вплив на швидкість ** — вплив якості коду або його відсутності на швидкість, з якою команда може передавати нову роботу. “Вплив на швидкість вимірюваний — наші останні три можливості в цьому модулі кожна тривала на 40% довше, ніж подібні можливості в інших місцях кодової бази.”

** Ризик регресії ** — ймовірність того, що зміна призведе до появи нової вади, часто підвищена у погано структурованому або неперевіреному коді.

• “Кожна зміна цього файла спричиняє високий ризик регресії, оскільки немає тестового покриття, а логіка глибоко переплетена з трьома іншими модулями.” *

** Інкрементальний рефакторинг ** — підхід рефакторингу, який виконується невеликими, низькоризичними кроками разом з звичайною роботою над функціональністю, а не великим переписуванням. “Замість того, щоб пропонувати повне переписування, я пропоную інкрементальний рефакторинг — ми очищуємо один модуль кожного спринту разом зі звичайною роботою над функціональністю.”

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

** Інвестиційна рамка ** - опис роботи з рефакторингу з точки зору повернення з часом, подібно до фінансової інвестиції, щоб резонувати з бізнес-зацікавленими сторонами.

• “Я розглядав рефакторинг як інвестицію: два тижні, в обмін на приблизно на 20% швидшу доставку цього модуля в майбутньому.” *

** Радіус вибуху (зміни) ** — скільки частин системи буде змінено зміною, це важливо, якщо ви вважаєте, що чутлива область має бути зроблена безпечнішою перед подальшими змінами.

• “Будь- які зміни у цьому модулі мають великий радіус дії — помилка у цьому модулі раніше призвела до знищення трьох не пов’ язаних між собою можливостей.” *

** Нефункціональна вимога ** — атрибут якості, наприклад, підтримка, продуктивність або масштабованість, на відміну від певної можливості, яка спрямована на користувача. “Здатність до обслуговування є нефункціональною вимогою, так само як і продуктивність — вона не з’ являється в демо, але безпосередньо впливає на те, наскільки швидко ми можемо надати майбутні можливості.”

Розробка бізнес-плану

• “Я б хотів запропонувати, щоб ми витратили два спринти на цей рефакторинг. Бізнес-причиною є те, що наші останні три функції тут кожна пропустила свій термін, і цей модуль є загальною причиною. ”
• «Це не про естетику коду — це про те, що кожна виправлення помилки тут зараз займає в середньому три дні, порівняно з півдня в інших місцях»
• «Якщо ми не звернемося до цього зараз, наступний запит функції в цій області, ймовірно, займе ще більше часу, і ризик виробничого інциденту зростає»

Переговори про час для рефакторингу

• «Чи можемо ми виділити 20% цього спринту на сплату боргу в цьому модулі, а не розглядати це як рішення «все або нічого»?»
• «Я не прошу про повний перепис — інкрементальний підхід означає, що ми можемо зупинитися в будь-який момент, якщо пріоритети зміняться»
• “А що, якщо ми прив’язаємо цей рефакторинг безпосередньо до наступного запиту на функцію в цій області? Ми б перефакторизували конкретний шлях, який торкається функції, а не весь модуль»

Відповідь на відсіч

• “Я розумію тиск, щоб спочатку випустити нову функцію. Чи можемо ми погодитися на менший, обмежений рефакторинг, який розблокує тільки цю функцію, і переглянути решту пізніше?»
• “Я слышу беспокойство по поводу риска по времени. Щоб бути ясним, ризик не робити це полягає в тому, що подібні функції будуть тривати довше, що з часом збільшується»
• «Це справедливе питання — ось приблизна оцінка вартості в будь-якому випадку: два тижні рефакторингу зараз, порівняно з оціненим додатковим тижнем на функцію, якщо ми не зробимо цього»

Професійні поради

1. ** Перекладайте якість коду на час і ризик, а не на естетику. ** « Це збереже нам приблизно тиждень на функцію » звучить набагато більше, ніж « код занадто заплутаний »
2. Запропонуйте додаткові варіанти поряд з повним рішенням. Надання зацікавленим сторонам меншої, менш ризикованої альтернативи робить легшим сказати «так» на щось.
3. ** Прив’ язувати рефакторинг до конкретних майбутніх робіт, коли це можливо. ** « Давайте перефакторуємо шлях, який торкається цієї наступної можливості » легше затвердити, ніж відкритий проект очищення.

Практичні вправи

1. Напишіть два речення, що перекладають « цей код неправильний » на аргумент, що впливає на бізнес, для менеджера продукту.
2. Напишіть коротку пропозицію (4- 5 речень) щодо інкрементального перероблення, пов’ язаного з майбутньою можливістю.
3. Написати відповідь зацікавленій стороні, яка відкидає запит на рефакторинг, запитуючи «не може це почекати?»

Розширення вашого словника: рефакторинг у глобальній команді

Ми описали основні принципи комунікації про рефакторинг — розуміння його цінності, чітке його формулювання і передбачення опору. Але давайте будемо чесні, навіть з твердим розумінням цих концепцій, навігація розмов навколо технічного боргу може відчуватися складно, особливо коли працюєш з колегами з різних сфер. Зазвичай перешкодою є не обов’язково що сказати, а скоріше конкретна використана мова, і як ця мова сприймається. Багато розробників, які вивчають професійну англійську, знаходять себе за замовчуванням надто буквальні переклади або борються з нюансами фразування, що є життєво важливим для передачі терміни і стратегічну важливість. Цей розділ зосереджено на забезпеченні носіїв мови, для яких мова не є рідною, словником і структурами речень, необхідними для впевненого обговорення пріоритетів рефакторингу у рамках глобальної команди.

Однією з областей, де це часто проявляється, є опис *впливу * не рефакторингу. Замість того, щоб просто сказати «Цей код поганий», що може звучати обвинувачуючим або надто технічним, розгляньте такі фрази, як «Поточний варіант являє собою підвищений ризик нестабільності, оскільки він сильно залежить від недокументованих припущень». Або, більш безпосередньо до менеджера продукту, ви можете сказати: «Не звертаючись до цього зараз, ми потенційно стикаємося з [кількісно вимірюваними наслідками - наприклад, «15% збільшення звітів про помилки», або «затримка випуску функції X»] - по суті, приоритизація рефакторингу зменшує цей ризик». Важливо, щоб навчитися сформулювати наслідки замість того, щоб просто вказувати на проблеми, є ключовим. Іншою корисною фразою, коли ви просите про час для рефакторингу, є « Ця робота буде активно зменшувати ймовірність майбутнього технічного боргу і дозволить нам підтримувати плавну швидкість розробки ». Це не буде звучати так, ніби ви просто виправляєте щось пошкоджене; ви демонструєте передбачуваність і робите свій внесок у загальну ефективність.

Давайте розглянемо приклад повідомлення Slack: «Привіт команда, я планую короткий рефактор модуля автентифікації користувача. Це стає все складнішим з недавніми додаваннями можливостей, і, чесно кажучи, ми ризикуємо ввести значні вади, якщо ми продовжимо цей шлях без розгляду основної архітектури. Я намагаюся завершити його протягом двох днів - це поліпшить підтримку і зменшить наші технічні борги.” Зауважте, як використовуються такі фрази, як “технічні борги” - термін, що все частіше зустрічається в глобальних технічних командах, що став стандартним словником для опису довгострокових проблем з якістю коду. Використання цих термінів показує, що ви розумієте ширший контекст обговорення, а не лише безпосередню проблему.

Нарешті, при написанні описів PR, уникайте надто детальних технічних пояснень, якщо ви не запитали про це. Сфокусуйтесь на результаті і стратегічному обґрунтуванні. Хороший приклад: « Перебудувати модуль автентифікації користувача, щоб поліпшити безпеку та підтримку. Ця робота розглядає виявлені вразливості і спрощує майбутні зусилля з розробки, вирівнюючи їх зі стандартами компанії для безпечної практики кодування. “Знову ж таки, це приоритизує вплив на гранульовані деталі, ключову відмінність при спілкуванні через мовні бар’єри і різні рівні технічної експертизи.