Технічний борг

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

Цінність цієї метафори полягає в тому, що компроміс можна обговорити з людьми, які не пишуть код. Формулювання запиту на рефакторинг як погашення боргу повідомляє про те, чого не повідомляє запит на переписування модуля, а саме: вартість вже сплачена, у вигляді повільнішої доставки та вищого рівня дефектів, і що питання полягає в тому, чи продовжувати її сплачувати. У початковому формулюванні Каннінгема також наголошувалось, що борг виникає через зростаючу розбіжність між структурою коду та поточним розумінням проблеми командою, що є ширшою ідеєю, ніж просто написання недбалого коду вчасно.

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

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

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

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

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