Технічний борг
Технічний борг (також відомий як борг проєктування або борг коду) — це концепція в програмуванні, що відображає додаткову розробницьку роботу, що виникає, коли код, який легко втілити в короткотерміновій перспективі, використовують замість застосування найкращого рішення.
Термін впроваджено в 1992-му році Вардом Канінгемом[1].
Технічний борг можна прирівняти до монетарного боргу[2]. Якщо технічний борг не погашено, він може акумулювати «відсотки», внаслідок чого з часом стає все важче втілювати зміни. Проігнорований технічний борг сприяє зростанню програмної ентропії. Він не обов'язково є поганим явищем, і часом є необхідним для подальшого просування проєкту. З іншого боку, деякі експерти стверджують, що метафора «технічний борг» схильна применшувати вплив цього явища, наслідком чого є неефективна пріоритезація роботи, необхідної для його погашення[3][4].
Коли починають вносити зміну до кодової бази, часто виникає потреба зробити й інші одночасні координовані зміни в кодовій базі чи документації. Інші необхідні, проте незавершені, зміни вважають боргом, який потрібно буде погасити в майбутньому. Так само, як і з фінансовим боргом, ці незавершені зміни викликають відсотки на відсотки, через що побудувати проєкт стає вкрай непокладним завданням. Хоча до цього терміну вдаються здебільшого в розробці програмного забезпечення, його теж можна застосувати і в інших сферах.
Загальними причинами технічного боргу є (комбінація):
- Тиск бізнесу, коли бізнес розглядає запуск продукту якомога раніше, до того, як усі необхідні зміни зроблено, та нагромаджує технічний борг з цих незавершених змін.
- Брак розуміння або процесів, коли бізнес є сліпим до концепції технічного боргу та приймає рішення без врахування можливих наслідків.
- Брак створення малозалежних компонентів, коли функції не є модульними, через що проєкт є недостатньо гнучким для адаптації до змін бізнесових потреб.
- Брак набору тестів, що заохочує швидке та ризиковане латання багів.
- Брак документації, коли код створюють без необхідної супровідної документації. Час на створення такої документації є боргом, який необхідно буде погасити.
- Брак співпраці, коли знання не поширюють в межах організації і ефективність бізнесу страждає, або коли недостатньо курують молодших розробників.
- Паралельне програмування водночас на двох або більше гілках може призвести до накопичення технічного боргу через зусилля, які колись необхідно буде потратити на злиття змін у єдину кодову базу. Що більше змін відбувається в ізоляції, тим більшим в результаті є борг.
- Відтермінування рефакторингу — В той час як проєктні вимоги розвиваються, може стати очевидним, що місцями код став громіздким та мусить бути порефактореним задля відповідності до майбутніх вимог. Чим довше цей рефакторинг відкладають на потім, і що більше коду пишуть в рамках поточного вигляду, тим більше назбирується боргу, який необхідно буде погасити до завершення рефакторингу.
- Брак відповідності до стандартів, коли ігнорують стандартні індустрійні особливості, фреймворки, технології. Одного разу настане час інтеграції зі стандартами, і зробити це раніше буде дешевше (подібно до «відтермінування рефакторингу»).
- Брак знань, коли розробник просто не знає, як писати елегантний код.
- Брак володіння, коли програмні напрацювання, замовлені ззовні, доводиться рефакторити чи переписувати на місці власними інженерами.
- Погане технічне керівництво з недостатньо продуманими командами, що поступають вниз ланцюгом команд, радше підвищує, а не знижує, технічний борг.
- Зміни специфікації в останній момент; мають потенціал до проникнення протягом всього проєкту, без достатнього часу чи бюджету на впровадження в документацію та перевірку.
- Скоуп Допінг (з англ. Scope Doping), неконтрольоване зменшення обсягу робіт чи їх відкладання проєктними менеджерами або технічними працівниками. Явище трохи відмінне від Тиску бізнесу в тому, що, хоч ТБ може бути причиною, СД також спричинить тиск бізнесу внаслідок неконтрольованого обсягу робіт, який було відтерміновано.
Важливо розрізняти види технічного боргу. У дискусійному блозі TechnicalDebtQuadrant[5] Мартін Фаулер виокремлює 4 «квадранти» виду боргу, базуючись на двох дихотомних категоріях: перша категорія це Необачне проти Розважливого, друга — Навмисне проти Ненавмисного.
«Відсоткові платежі» полягають одночасно у необхідному місцевому утриманні та відсутності утримання іншими користувачами проєкту. Безперервна розробка у батьківському проєкті може підвищити вартість «сплати боргу» в майбутньому. Борг сплачують просто завершенням недоробленої роботи.
Нагромадження технічного боргу є одною з основних причин невкладання в терміни. Важко оцінити скільки саме роботи необхідно зробити, аби відплатити борг. Кожна нова зміна тягне за собою невизначений обсяг незавершеної роботи на проєкті. Терміну не дотримуються, коли проєкт усвідомлює, що є більше боргу, аніж часу на його погашення. Для того, аби мати передбачуваний розклад запуску, команда розробників повинна обмежити обсяги поточної роботи задля того, щоб розмір незавершеної роботи (боргу) постійно був невеликим.
Якщо на проєкті зроблено достатньо роботи для того, щоб не було перепон для його запуску, то останній відбудеться, і проєкт перенесе в собі значний об'єм технічного боргу. Якщо програму буде опубліковано, то ризики втілення будь-якого подальшого рефакторингу, спрямованого на зменшення технічного боргу значно зростають. Внесення змін до вже опублікованого коду несе в собі ризик перебоїв у роботі, справжніх фінансових втрат та можливо легальни наслідків, якщо контракти містили домовленості сервісного рівня (з англ. service-level agreements, SLA). З цієї причини ми можемо дивитись на перенесення технічного боргу у публікацію продукту майже як на підвищення відсоткової ставки, і єдиною можливістю її пониження є скасування або відкликання розгортування програми.
В той час, як закон Менні Лемана вже визначив, що розвиток програм невпинно підвищує їх складність та погіршує структуру, якщо не проводяться роботи для їхньої підтримки, Ворд Канінгем був першим, хто провів порівняння між технічною складністю та боргом у звіті досвіду за 1992 рік.
У статті 2004 року, Рефакторинг до шаблонів, Джошуа Керієвскі представляє порівнюваний аргумент стосовно витрат, пов'язаних з архітектурною недбалістю, які він описує як «борг проєктування»[6].
До діяльності, що може стати відтермінованою, належать: створення та підтримка документації, написання тестів, вдавання до TODO коментарів та хапання за попередження компілятора та статичного аналізу коду. Серед інших сутностей технічного боргу є знання, якими не поділились в межах організації та код, який є занадто заплутаним для легкого внесення в нього змін.
Граді Буч порівнює, як розвиток міст є схожим на розвиток програмно насичених систем, і як брак рефакторингу може призвести до технічного боргу.
У відкритому програмному забезпеченні відкладання відправлення локальних змін до батьківського проєкту є технічним боргом.
- Запахи коду (симптоми низької якості коду, що може докладатись до технічного боргу)
- Програмна ентропія
- Затоплені кошти
- Коментар (програмування)
- Ірраціональна ескалація
- Bus factor
- ↑ Joe Xavier. How to make debt pay. TechCrunch. Процитовано 5 грудня 2016.
- ↑ Allman, Eric (May 2012). Managing Technical Debt. Communications of the ACM. 55 (5): 50-55. doi:10.1145/2160718.2160733.
{{cite journal}}:|access-date=вимагає|url=(довідка) - ↑ Jeffries, Ron. Technical Debt – Bad metaphor or worst metaphor?. Архів оригіналу за 10 листопада 2015. Процитовано 10 листопада 2015.
- ↑ Knesek, Doug. Averting a 'Technical Debt' Crisis. Процитовано 7 квітня 2016.
- ↑ Fowler, Martin. Technical Debt Quadrant. Процитовано 20 листопада 2014.
- ↑ Kerievsky, Joshua (2004). Refactoring to Patterns. ISBN 0-321-21335-1.