Що таке технічний борг (technical debt) в IT проєктах?

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

Чистий код – мрія будь-якого розробника, але на практиці обставини часто змушують йти на компроміси. Тиск з боку бізнесу, дедлайни та обмежений бюджет можуть змусити до релізу функціоналу до того, як код буде відполірований до досконалості. Тимчасові рішення поступово перетворюються на "брудний код (код з душком / code smell)", який ускладнює подальшу роботу.

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

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

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

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

Існують часові межі (дедлайни) для реалізації функціоналу інтернет-магазину. Команда розробників вирішує швидко впровадити систему управління замовленнями. З початку вони вирішили використовувати просту структуру бази даних, де всі дані про замовлення, включаючи деталі товарів, інформацію про клієнтів і транзакції, зберігаються в одній таблиці. Це рішення дозволяє швидко запустити проєкти (MVP), але в міру зростання кількості замовлень і складності даних, така структура стає неефективною.

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

Рішення цієї проблеми вимагає значних зусиль по рефакторингу бази даних, включаючи перепроєктування таблиць, оптимізацію запитів та можливо впровадження нових технологій кешування. Такий рефакторинг займе час і ресурси, які могли бути використані на розвиток інших аспектів проєкту, але без цього кроку подальше зростання та ефективність онлайн-магазину будуть обмежені. І ось тут ми розуміємо що таке 'борг'. Необхідний рефакторинг можна оцінити в часі та грошах (оплата роботи команди). Не витративши цей час / гроші з самого початку, ми 'заборгували' самі собі, відклавши роботу над більш складною системою на потім. Але іноді технічний борг виправданий - ми робимо MVP та запускаємо проєкт, щоб почати заробляти. І тільки потім ми можемо рефінансувати отримані кошти в код.

Цей список неповний, але концептуально думаю можна зрозуміти суть.

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

Нерозуміння впливу від накопичення технічного боргу: Власники бізнесу можуть не бачити наслідків ігнорування технічного боргу, вважаючи його менш важливим, ніж безпосередній вихід продукту на ринок. Іноді доволі важко пояснити людині без знань про IT-процеси, чому треба витрачати гроші й час на переписування / написання коду. Усвідомлення приходить саме тоді, коли технічний борг починає впливати на бізнес. 

Монолітна архітектура: Відсутність модульності у проєктуванні системи обмежує гнучкість та вимагає великих зусиль для будь-яких змін чи вдосконалень, що уповільнює адаптацію до змінних бізнес-вимог.

Брак тестів: Відсутність комплексних тестів збільшує ризик помилок, що може призвести до серйозних збоїв у майбутньому.

Брак документації: Якщо проєкт розвивається без належного документування, нові члени команди витратять більше часу на вивчення системи, що знижує їх продуктивність. Також, нові розробники будуть відволікати старих питаннями. Можливо, під час код рев'ю буде більше запитів на виправлення коду (від розробників, які знають нюанси коду, архітектури, бізнес-процесів тощо).

Погана взаємодія / комунікація: Коли знання та досвід не поширюються в організації, ефективність праці падає. Т

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

Відтермінування рефакторингу: Зволікання з оптимізацією коду створює ситуацію, де код стає все більш незручним для підтримки і розширення.

Недотримання стандартів: Ігнорування встановлених стандартів та конвенцій може ускладнити майбутню інтеграцію і підтримку проєкту.

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

Розробка підрядниками: Програмні продукти розроблені підрядниками і потім інтегровані в проєкт, часто потребують додаткових витрат на їхню адаптацію і оптимізацію.

Погане керівництво: Неефективне керівництво може збільшувати технічний борг через недостатньо продумані процеси.

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

Scope Creep: Неконтрольоване зменшення або відкладання обсягу робіт може створити додатковий тиск і збільшити технічний борг через незаплановані зміни у проєкті.