Dług technologiczny (technical debt) to koszt przyszłej pracy, który powstaje, gdy w kodzie wybierasz rozwiązanie szybsze zamiast lepszego. Termin ukuty przez Warda Cunninghama w 1992 roku jest metaforą pożyczki — od każdego skrótu płacisz odsetki w postaci wolniejszych zmian, większej liczby błędów i droższego utrzymania. Ten artykuł pokazuje, jak rozpoznać dług, jak go zmierzyć i jak zaplanować jego spłatę, żeby nie zbankrutować.
Najważniejsze: Dług techniczny nie jest złem — każdy system go ma. Złem jest dług, którym nikt nie zarządza. Praktyczna zasada: dług celowy (świadomy skrót) planujesz do spłaty, dług przypadkowy mierzysz narzędziami i spłacasz przy okazji zmian. Punkt alarmowy to moment, gdy wdrożenie nowej funkcji zajmuje dłużej niż jej napisanie.
Skąd bierze się dług techniczny
Dług nie bierze się z lenistwa programistów — bierze się z presji czasu i zmieniających się wymagań. Typowe źródła w projektach, które widuję:
- presja terminu — funkcja „na wczoraj" pisana bez testów i refaktoryzacji,
- zmiana wymagań — kod pisany pod inne założenia biznesowe niż obecne,
- brak wiedzy — rozwiązania, które w momencie pisania wydawały się dobre, a w praktyce są pułapką,
- rotacja zespołu — każda zmiana wykonawcy zostawia kod w innym stylu i z innymi skrótami,
- zaniedbane aktualizacje — wersje PHP, frameworka i bibliotek odległe o lata od wspieranych,
- kopiowanie zamiast abstrakcji — ten sam mechanizm powielony w kilkunastu miejscach, każdy z własnymi błędami.
Warto rozróżnić dług celowy od przypadkowego. Celowy to świadoma decyzja: „wiemy, że to skrót, wracamy do tego po wdrożeniu". Przypadkowy to skutek niewiedzy lub pośpiechu, którego nikt nie zapisał. Ten drugi rośnie najszybciej, bo nie ma go na żadnej liście — dopóki nie zacznie blokować projektu. Framework pojęciowy rozwinął Martin Fowler, dzieląc dług na cztery typy: roztropny i lekkomyślny, świadomy i nieświadomy. Najgroźniejszy jest dług lekkomyślny i nieświadomy — szybkie obejścia bez zrozumienia konsekwencji, o których nikt nie pamięta.
Jak dług techniczny wpływa na biznes
Dług techniczny nie pojawia się w fakturach — pojawia się w opóźnieniach. Zespoły pracujące w zadłużonym kodzie raportują to samo na trzy sposoby:
- wolniejsze wdrożenia — funkcja, która powinna zająć dzień, zajmuje tydzień, bo każda zmiana pociąga nieprzewidziane skutki,
- więcej błędów — im mniej testów i jaśniejszej struktury, tym częściej poprawka jednego elementu psuje inny,
- trudniejszy onboarding — nowa osoba potrzebuje miesięcy, żeby zrozumieć system, albo nie jest w stanie go zrozumieć wcale,
- rosnące koszty utrzymania — stare technologie i wiedza, która odeszła z byłymi pracownikami, podnoszą cenę każdej godziny pracy,
- zablokowany rozwój — decyzje produktowe podejmowane nie na podstawie „co warto", ale „co da się jeszcze dopisać".
Punkt, w którym dług staje się problemem zarządczym, ma prosty test: porównaj czas potrzebny na wdrożenie typowej zmiany z czasem jej napisania. Gdy wdrożenie zajmuje więcej — dług zaczął dominować nad kodem.
Jak zmierzyć dług techniczny
Długu nie da się policzyć co do złotówki, ale da się go zmierzyć na tyle dobrze, żeby podejmować decyzje. Cztery praktyczne metryki:
- analiza statyczna — PHPStan i Psalm zwracają liczbę błędów typów i podejrzanych konstrukcji; trend w czasie mówi więcej niż wartość bezwzględna,
- pokrycie testami — procent kodu objętego testami, a jeszcze lepiej: pokrycie ścieżek krytycznych biznesowo,
- czas wdrożenia zmiany — mierzony regularnie (np. od commita do produkcji) i rozbity na etapy; wydłużanie to najczystszy sygnał rosnącego długu,
- częstotliwość błędów regresji — ile zmian wprowadza poprawki błędów w innych miejscach; rosnąca liczba to znak, że moduły są zbyt splecione,
- wiek zależności — ile wersji dzieli twoje biblioteki od aktualnych i ile z nich jest poza wsparciem bezpieczeństwa.
Do obrazu całości dokłada się audyt kodu legacy — przegląd architektury, bezpieczeństwa i wydajności z roadmapą. Metryki bez mapy długu mówią „jest źle", mapa mówi „tu i tu, w tej kolejności".
Jak spłacać dług techniczny
Najczęstszy błąd to traktowanie spłaty długu jako osobnego projektu — „najpierw pół roku porządków, potem wracamy do funkcji". Taki projekt prawie zawsze przegrywa z presją biznesową. Sprawdzone podejścia wyglądają inaczej:
- reguła skauta — zostawiasz kod odrobinę lepszy, niż go zastałeś, przy każdej zmianie; kumuluje się to zaskakująco szybko,
- budżet długu — stała część czasu zespołu (typowo 10–20%) idzie na spłatę długu i porządki techniczne, zaplanowana z góry,
- spłata przy okazji — moduł, który i tak zmieniasz dla funkcji, refaktoryzujesz przy okazji; to najtańsza forma spłaty,
- refaktoryzacja modułowa — moduły o najwyższym ryzyku dostają osobny, zaplanowany projekt modernizacji,
- koniec z nowym długiem — nowy kod piszesz z testami, statyczną analizą i przeglądem kodu; dług spłacany bez zatrzymania nowego długu nigdy się nie kończy.
Kluczowe jest powiązanie spłaty z biznesem. „Refaktoryzacja modułu rozliczeń" brzmi jak koszt. „Skrócenie czasu wdrożenia zmian w fakturowaniu z dwóch tygodni do dwóch dni" brzmi jak inwestycja — i nią jest.
Dług techniczny a legacy code
Dług techniczny i legacy code to dwie strony tej samej monety. Legacy code to kod, który przetrwał i wciąż działa. Dług techniczny to narosłe w nim skróty, których spłata jest warunkiem dalszego rozwoju. System może być stary i mieć niski dług (mały, stabilny, dobrze przetestowany) — albo młody i mocno zadłużony (napisany w pośpiechu w zeszłym roku).
Dlatego decyzja „co dalej" nie zależy od wieku kodu, lecz od poziomu długu i planów biznesowych. Jeśli planujesz rozwój — dług trzeba spłacać, a narzędzia i kolejność działań rozkładam w przewodniku o refaktoryzacji legacy code i w pillarze o modernizacji legacy code. Jeśli system ma żyć bez zmian — wystarczy pilnować bezpieczeństwa i aktualizacji.
Od czego zacząć jeszcze w tym tygodniu
Trzy działania, które nie wymagają projektu ani budżetu
- Uruchom PHPStan na najniższym poziomie i zapisz liczbę błędów — to twoja linia bazowa. Powtarzaj pomiar co miesiąc.
- Sprawdź, ile zależności jest poza wsparciem bezpieczeństwa — narzędzia typu
composer outdatedi bazy podatności pokażą to w kwadrans. - Zmierz czas od commita do produkcji dla ostatnich dziesięciu wdrożeń — jeśli rósł, masz odpowiedź, gdzie boli najbardziej.
Te trzy liczby wystarczą, żeby rozmowa o długu technicznym przestała być rozmową o odczuciach, a stała się rozmową o danych.
Najczęściej zadawane pytania
Czym różni się dług techniczny od długu technologicznego?
To dwa określenia tego samego zjawiska. „Dług techniczny" (technical debt) to termin oryginalny, ukuty przez Warda Cunninghama. „Dług technologiczny" funkcjonuje w polskim biznesie jako jego odpowiednik — czasem w węższym znaczeniu przestarzałych technologii, a nie samych skrótów w kodzie.
Czy dług techniczny da się spłacić całkowicie?
Nie i nie powinno to być celem. Część długu to świadome, opłacalne decyzje — jak szybkie wdrożenie funkcji przed ważnym terminem. Celem jest zarządzanie długiem: znajomość jego poziomu, plan spłaty dla najbardziej kosztownych pozycji i zero tolerancji dla nowego długu przypadkowego.
Kiedy dług techniczny staje się krytyczny?
Gdy blokuje realizację celów biznesowych: wdrożenia trwają tygodniami, błędy regresji zdarzają się przy każdej zmianie, a znalezienie osób znających system graniczy z cudem. Sygnałem jest też moment, gdy zespół zaczyna planować prace wokół problemów zamiast je rozwiązywać.
Ile kosztuje spłata długu technicznego?
To zależy od skali, ale punkt startowy nie jest drogi. Audyt techniczny to 2 000 zł netto jednorazowo — dostajesz mapę długu i roadmapę spłaty. Dalsze koszty rozkładają się na etapy modernizacji, które i tak wykonujesz przy okazji rozwoju produktu. Pełne widełki opisuję w artykule o kosztach modernizacji legacy.