Dług techniczny: jak go mierzyć i co naprawić najpierw?

Dług techniczny spowalnia rozwój, gdy każda nowa funkcja trwa dłużej niż poprzednia. Dla firmy oznacza to roadmapę, która ciągle się przesuwa, i programistów, którzy gaszą pożary zamiast budować.

Można go zmierzyć bez drogiego narzędzia, na podstawie historii git i błędów. Najpierw warto spłacić dług w kodzie, który zmienia się najczęściej, a nie w tym najbrzydszym.

Większość naszego kodu pisze AI. Senior sprawdza każdą zmianę i odpowiada za produkcję. Przez lata rozwijaliśmy jeden produkt SaaS. Długu w produkcie, który żyje latami, nie rozwiąże się w jednym sprincie. Spłaca się go na bieżąco.

Jak poznać, że dług techniczny Państwa spowalnia?

Dług sam się nie zgłasza. Objawia się jako powolność, którą każdy tłumaczy inaczej. Przycisk, który powinien zająć dzień, zajmuje tydzień. Proszę zaznaczyć, co dotyczy Państwa zespołu. Każdy niezaznaczony punkt to jeden sygnał długu.

Jak zmierzyć dług techniczny bez drogiego narzędzia?

Nie potrzebują Państwo platformy do analizy kodu. Potrzebują Państwo odpowiedzi na jedno pytanie: gdzie zmiany kosztują najwięcej?

Najsilniejszym sygnałem są dwa pierwsze wiersze razem. Plik, który często się zmienia i do tego wciąż generuje błędy, to dług z odsetkami. Listę najczęściej zmienianych plików daje jedno polecenie:

git log --since="6 months ago" --format= --name-only | sort | uniq -c | sort -rn | head -20

Przy każdym pliku z wyniku proszę zanotować błędy, które go dotyczyły. Kilka pierwszych wierszy to Państwa lista.

Co naprawić najpierw?

Nie to, co najbrzydsze. To, co teraz kosztuje najwięcej czasu. Kolejność, którą stosujemy:

Estetyka i przejście na nowszy framework „bo jest nowszy” są na samym końcu. Kod, którego nikt nie dotyka od miesięcy, może pozostać brzydki. Nic Państwa nie kosztuje. Jeśli w ogóle nie jest używany, nie spłacamy go, tylko go usuwamy. Tak samo robimy we własnych repozytoriach: nieużywany kod i narzędzia, których nikt nie wywołuje, znikają.

Jeśli dług w jakiejś części jest tak duży, że rozważają Państwo przepisanie, warto zacząć tak samo. Najpierw testy obecnego zachowania, potem decyzja. Jak testy i review naprawdę zatrzymują złą zmianę, opisujemy w artykule Claude Code best practices dla zespołu: 7 zasad, które działają.

Jak spłacać dług bez zatrzymywania roadmapy?

W tym samym rytmie co funkcje. Nie w „sprincie refaktoryzacji”, który ciągle się przesuwa, bo pojawiła się pilna funkcja.

• Stała część mocy zespołu. Proszę ustalić ją z góry z produktem i nie sięgać po nią przy pierwszym alarmie.
• Spłata tam, gdzie Państwo pracują. Gdy budują Państwo funkcję w zadłużonym module, proszę posprzątać go w tym samym pull requeście.
• Najpierw test, potem zmiana. Test obecnego zachowania wyłapie to, co inaczej by się zepsuło.
• Żadnego nowego długu bez zapisu. Jeśli świadomie idą Państwo na skróty, proszę zapisać to jako zadanie z uzasadnieniem.

Tak to wygląda na jednej funkcji z roadmapy:

AI zmienia tu rachunek. Testy istniejącego kodu, przenoszenie i zmiana nazw były drogie, więc je odkładano. Z AI są tanie. Bez reguł i review AI dokłada jednak długu równie szybko. Co zostawiamy jej w repozytorium, opisujemy w artykule Reguły dla kodu AI w zespole.

Pierwsze kroki na ten miesiąc:

1. Proszę wyciągnąć z git listę najczęściej zmienianych plików.
2. Przy każdym zanotować błędy z ostatnich miesięcy.
3. Wybrać trzy miejsca, które blokują następną funkcję z roadmapy.
4. Ustalić z produktem stałą część mocy zespołu na dług.
5. Sprawdzić, czy CI potrafi zatrzymać zły merge.

Kiedy tego nie polecamy

• Dług Państwa nie spowalnia, po prostu się nie podoba. Jeśli ten kod się nie zmienia, proszę go zostawić. Moc zespołu lepiej przeznaczyć na roadmapę.
• Produkt za kilka miesięcy zostanie wyłączony lub zastąpiony. Spłacanie długu w kodzie, który się kończy, nie opłaca się.

Chcą Państwo spłacać dług z kimś, kto robi to codziennie?

Senior od pierwszego dnia wchodzi do Państwa repozytorium i pull requestów. Spłaca dług na drodze roadmapy, obok funkcji, a nie zamiast nich. Tak pracujemy jako zewnętrzny programista dla zespołów produktowych.

Proszę napisać, która część systemu najbardziej Państwa spowalnia. Odezwiemy się w ciągu dwóch dni roboczych z kilkoma pytaniami o Państwa pracę. Potem ustalimy, co zrobimy najpierw.

Jeśli wolą Państwo najpierw porozmawiać, proszę zarezerwować 15-minutową rozmowę wstępną.

Którego pliku w Państwa repozytorium cały zespół boi się otworzyć?

Najczęstsze pytania

Jak zmierzyć dług techniczny?

Najprościej na podstawie historii git i błędów. Pliki, które zmieniają się najczęściej i jednocześnie generują błędy, to dług, który naprawdę kosztuje Państwa czas. Do tego warto obserwować, jak rosną szacunki przy małych zmianach.

Co naprawić najpierw?

Dług w kodzie, którego potrzebują Państwo do następnej funkcji z roadmapy. Potem często zmieniany kod z błędami. Kod, którego nikt nie dotyka, lepiej zostawić w spokoju, nawet jeśli jest brzydki.

Jak wytłumaczyć dług techniczny zarządowi?

Językiem czasu i ryzyka, nie jakości kodu. Proszę pokazać, o ile dłużej trwają zmiany w konkretnej części i ile błędów z niej pochodzi. Najlepiej na funkcji z roadmapy, na którą czeka zarząd.

Czy AI zwiększa dług techniczny?

Bez reguł i review tak, bo pisze szybko i bez kontekstu. Z regułami w repozytorium, testami i review wykonanym przez kogoś innego pomaga go spłacać. Testy i przenoszenie kodu są z AI tanie.