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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку

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

Термін впроваджено в 1992-му році Вардом Канінгемом[1].

Технічний борг можна прирівняти до монетарного боргу[2]. Якщо технічний борг не погашено, він може акумулювати «відсотки», внаслідок чого з часом стає все важче втілювати зміни. Проігнорований технічний борг сприяє зростанню програмної ентропії. Він не обов'язково є поганим явищем, і часом є необхідним для подальшого просування проекту. З іншого боку, деякі експерти стверджують, що метафора «технічний борг» схильна применшувати вплив цього явища, наслідком чого є неефективна пріоритезація роботи, необхідної для його погашення[3][4].

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

Причини[ред. | ред. код]

Загальними причинами технічного боргу є (комбінація):

  • Тиск бізнесу, коли бізнес розглядає запуск продукту якомога раніше, до того, як усі необхідні зміни зроблено, та нагромаджує технічний борг з цих незавершених змін.
  • Брак розуміння або процесів, коли бізнес є сліпим до концепції технічного боргу та приймає рішення без врахування можливих наслідків.
  • Брак створення малозалежних компонентів, коли функції не є модульними, через що проект є недостатньо гнучким для адаптації до змін бізнесових потреб.
  • Брак набору тестів, що заохочує швидке та ризиковане латання багів.
  • Брак документації, коли код створюють без необхідної супровідної документації. Час на створення такої документації є боргом, який необхідно буде погасити.
  • Брак співпраці, коли знання не поширюють в межах організації і ефективність бізнесу страждає, або коли недостатньо курують молодших розробників.
  • Паралельне програмування водночас на двох або більше гілках може призвести до накопичення технічного боргу через зусилля, які колись необхідно буде потратити на злиття змін у єдину кодову базу. Що більше змін відбувається в ізоляції, тим більшим в результаті є борг. 
  • Відтермінування рефакторингу — В той час як проектні вимоги розвиваються, може стати очевидним, що місцями код став громіздким та мусить бути порефактореним задля відповідності до майбутніх вимог. Чим довше цей рефакторинг відкладають на потім, і що більше коду пишуть в рамках поточного вигляду, тим більше назбирується боргу, який необхідно буде погасити до завершення рефакторингу.
  • Брак відповідності до стандартів, коли ігнорують стандартні індустрійні особливості, фреймворки, технології. Одного разу настане час інтеграції зі стандартами, і зробити це раніше буде дешевше (подібно до «відтермінування рефакторингу»).
  • Брак знань, коли розробник просто не знає, як писати елегантний код.
  • Брак володіння, коли програмні напрацювання, замовлені ззовні, доводиться рефакторити чи переписувати на місці власними інженерами. 
  • Погане технічне керівництво з недостатньо продуманими командами, що поступають вниз ланцюгом команд, радше підвищує, а не знижує, технічний борг.
  • Зміни специфікації в останній момент; мають потенціал до проникнення протягом всього проекту, без достатнього часу чи бюджету на впровадження в документацію та перевірку.
  • Скоуп Допінг (з англ. Scope Doping), неконтрольоване зменшення обсягу робіт чи їх відкладання проектними менеджерами або технічними працівниками. Явище трохи відмінне від Тиску бізнесу в тому, що, хоч ТБ може бути причиною, СД також спричинить тиск бізнесу внаслідок неконтрольованого обсягу робіт, який було відтерміновано.

Різновид[ред. | ред. код]

Важливо розрізняти види технічного боргу. У дискусійному блозі TechnicalDebtQuadrant[5] Мартін Фаулер виокремлює 4 «квадранти» виду боргу, базуючись на двох дихотомних категоріях: перша категорія це Необачне проти Розважливого, друга — Навмисне проти Ненавмисного.

Наслідки[ред. | ред. код]

«Відсоткові платежі» полягають одночасно у необхідному місцевому утриманні та відсутності утримання іншими користувачами проекту. Безперервна розробка у батьківському проекті може підвищити вартість «сплати боргу» в майбутньому. Борг сплачують просто завершенням недоробленої роботи.

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

Якщо на проекті зроблено достатньо роботи для того, щоб не було перепон для його запуску, то останній відбудеться, і проект перенесе в собі значний об'єм технічного боргу. Якщо програму буде опубліковано, то ризики втілення будь-якого подальшого рефакторингу, спрямованого на зменшення технічного боргу значно зростають. Внесення змін до вже опублікованого коду несе в собі ризик перебоїв у роботі, справжніх фінансових втрат та можливо легальни наслідків, якщо контракти містили домовленості сервісного рівня (з англ. service-level agreements, SLA). З цієї причини ми можемо дивитись на перенесення технічного боргу у публікацію продукту майже як на підвищення відсоткової ставки, і єдиною можливістю її пониження є скасування або відкликання розгортування програми.

В той час, як закон Менні Лемана вже визначив, що розвиток програм невпинно підвищує їх складність та погіршує структуру, якщо не проводяться роботи для їхньої підтримки, Ворд Канінгем був першим, хто провів порівняння між технічною складністю та боргом у звіті досвіду за 1992 рік.

У статті 2004 року, Рефакторинг до шаблонів, Джошуа Керієвскі представляє порівнюваний аргумент стосовно витрат, пов'язаних з архітектурною недбалістю, які він описує як «борг проектування»[6].

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

Граді Буч порівнює, як розвиток міст є схожим на розвиток програмно насичених систем, і як брак рефакторингу може призвести до технічного боргу.

У відкритому програмному забезпеченні відкладання відправлення локальних змін до батьківського проекту є технічним боргом.

Див. також[ред. | ред. код]

Примітки[ред. | ред. код]

  1. Joe Xavier. How to make debt pay. TechCrunch. Процитовано 2016-12-05. 
  2. Allman, Eric (May 2012). Managing Technical Debt. Communications of the ACM 55 (5): 50-55. doi:10.1145/2160718.2160733. 
  3. Jeffries, Ron. Technical Debt – Bad metaphor or worst metaphor?. Архів оригіналу за November 10, 2015. Процитовано November 10, 2015. 
  4. Knesek, Doug. Averting a 'Technical Debt' Crisis. Процитовано April 7, 2016. 
  5. Fowler, Martin. Technical Debt Quadrant. Процитовано 20 November 2014. 
  6. Kerievsky, Joshua (2004). Refactoring to Patterns. ISBN 0-321-21335-1.