Технички дуг у развоју апликација: шта је, узроци и методе управљања

Шта је технички дуг у развоју апликација

Технички дуг — концепција коју је вео Уорд Канингем 1992. године да би описао јаз између тренутног стања кода и идеалне архитектуре. Термин повлачи аналогију са финансијским дугом: ако узмете технички кредит (изаберете брзо решење), камата (сложеност одржавања) се акумулира током времена.

За разлику од грешака, технички дуг није грешка у логици — то је архитектурни компромис који убрзава тренутни развој, али успорава будући. На пример, копирање дела кода уместо издвајања заједничке функције убрзава имплементацију за сат времена, али додаје недеље одржавања при промени захтева.

Према McKinsey (2025), компаније са високим нивоом техничког дуга троше 20–40% више ресурса на имплементацију нових функција у поређењу са конкуренцијом. То чини управљање дугом не техничком опцијом, већ пословном потребом.

Основни узроци настанка техничког дуга

Скраћени рокови — најчешћи узрок. Тим бира „урадити брзо, касније преписати”, али „касније” никада не дође. Производне верзије акумулирају компромисе, а систем постепено губи архитектурни интегритет.

Недостатак code review-a доводи до тога да неоптимална решења доспевају у главну грану без дискусије. Истраживање SmartBear (2024) показује: пројекти без обавезног прегледа кода акумулирају технички дуг 2,3 пута брже од оних који практикују паровско програмирање или формалне инспекције кода.

Промена захтева — још један извор. Архитектура дизајнирана за једне пословне услове разбија се при промени контекста. Програмери надограђују нове слојеве преко старе логике уместо преобликовања, што води ка порасту цикломатске сложености.

Недостатак тестова чини рефакторизацију ризичном. Тим се плаши да препише код јер није јасно који сценарији ће се покварити. Затворен круг: без тестова нема безбедног рефакторисања, без рефакторисања се не могу додати тестови.

Врсте техничког дуга: стратешки и ненамерни

Стратешки технички дуг — свесни избор тима да одложи архитектурна побољшања ради брзог покретања. MVP производи, прототипови и A/B тестови су класични примјери. Такав дуг се планира и отплаћује након провјере хипотезе.

Ненамерни технички дуг настаје због непознавања најбољих пракси, недостатка архитектурне визије или лоше комуникације у тиму. Не планира се, не процењује се и акумулира се без контроле. Према ThoughtWorks (2024), управо ненамерни дуг чини 60–70% укупног техничког дуга у типичном пројекту.

Архитектурни технички дуг — застарели обрасци и антиобрасци, као што су God Object или Spaghetti Code. Технички дуг тестирања — недостатак јединичних, интеграционих и UI тестова. Технички дуг инфраструктуре — ручно постављање, недостатак CI/CD-а, застареле верзије алата.

Како измерити технички дуг у пројекту

Време имплементације — кључна метрика. Ако додавање једноставне функције траје неколико дана уместо сати — технички дуг је висок. SonarQube пружа квантитативну процену кроз показатељ Debt Ratio: однос времена поправке свих пронађених проблема према укупном времену развоја.

Цикломатска сложеност — метрика која показује број независних путања у коду. Нормална сложеност је до 10 по функцији. Вриједности изнад 25 указују на озбиљан архитектурни дуг. Алати као што су CodeClimate и NDepend аутоматски прате ову метрику у репозиторијуму.

Технички коефицијент — однос броја линија кода додатих током рефакторизације према броју линија додатих при стварању нове функционалности. Коефицијент испод 0,1 указује да тим не посвећује пажњу квалитету кода.

Учесталост инцидената — посредни показатељ. Пораст броја грешака након издавања без промене обима функционалности говори о акумулирању дуга. Праћење путем Sentry или Crashlytics помаже да се прати ова динамика у дугорочној перспективи.

Стратегије управљања техничким дугом

Backlog техничког дуга — издвојена листа задатака за рефакторизацију и побољшање кода. Сваки задатак се процењује на основу сложености и утицаја на брзину развоја. Препоручује се издвајање 20–30% спринта на задатке из овог backlog-а, како саветује Martin Fowler (2024) у препорукама за управљање техничким дугом за agile тимове.

Правило извиђача — остави код чишћим него што си га затекао. Свака промјена у legacy коду треба да буде праћена микрорефакторисањем: преименовање промењљиве, издвајање методе, додавање теста. Кумулативни ефекат оваквих микропобољшања значајно смањује дуг кроз 6–12 месеци.

Quadrant анализа — класификација техничког дуга по двије осе: важности и хитности. Критични дуг (Reckless + Prudent према Fowlerовој класификацији) захтјева хитно рјешавање. Некритични се планира у backlog. RCA (Root Cause Analysis) за сваки критични случај спречава понављање проблема.

Методе рефакторизације и отплате дуга

Strangler Fig pattern — постепена замена модула система без заустављања производа. Нови модул се поставља поред старим, промет се постепено преусмерава. Овај образац је посебно ефикасан у микросервисној архитектури, где се сваки сервис може замијенити независно.

Big Rewrite — потпуно преписивање система из почетка. Најризичнији приступ: према Standish Group (2024), 75% пројеката потпуног преписивања премашују буџет или крше рокове. Користити само када технички дуг блокира сваки развој, а трошкови одржавања премашују трошкове преписивања.

Покривање тестовима — основ безбедног рефакторисања. Прије промјене legacy кода додај тестове карактеризације који биљеже тренутно понашање. Затим изврши рефакторизацију под заштитом ових тестова. Према Michael Feathers (2023), овај приступ смањује ризик уношења грешака при рефакторисању за 70%.

Примјер: рефакторизација издвајањем методе

def processOrder(order) {
    // Пре: 60 линија са валидацијом,
    // израчунавање попуста и слање епоште
}

def validateOrder(order) { /* extracted */ }
def calculateDiscount(order) { /* extracted */ }
def sendConfirmation(order) { /* extracted */ }