Co to jest dług techniczny?
Dług techniczny to skumulowany koszt wyboru szybszej, mniej czystej implementacji w zamian za wolniejszą i droższą pracę w przyszłości. Metafora (ukuta przez Warda Cunninghama, 1992) jest zamierzona: podobnie jak dług finansowy, płacisz odsetki w postaci błędów, spowolnień i przeróbek, dopóki ich nie „spłacisz”.
Skąd bierze się dług techniczny
- Celowe kompromisy: „wyślij teraz, zrefaktoryzuj następny sprint”, aby dotrzymać terminu.
- Luki w wiedzy: wzorce wybrane, zanim zespół dobrze poznał domenę.
- Rozpad z biegiem czasu: to, co było czystym kodem w 2018 r., może zostać niedopasowane do bazy kodu z 2026 r.
- Pominięte testy, dokumenty lub typy: szybkie pominięcie, drogie dodanie z powrotem.
Objawy podczas sprintów
- Prędkość tendencja spadkowa: ten sam zespół, ten sam wysiłek, mniejsza wydajność.
- Szacunki się posypały: pozornie drobne zmiany zwykle wymagają trzykrotności planowanego wysiłku.
- Powtarzanie się błędu: ta sama pierwotna przyczyna wciąż pojawia się w nowych zgłoszeniach.
- Historie „Strachu”.: obszary kodu, których nikt nie chce dotykać.
Jak sobie z tym poradzić
- Śledź to wyraźnie: rejestruj pozycje zadłużenia jako zadania zaległości, a nie niewypowiedziany folklor zespołu.
- Zarezerwuj pojemność sprintu: wiele zespołów przeznacza 10–20% każdego sprintu na spłatę zadłużenia.
- Powiąż spłatę z pracą fabularną: spłacaj dług w modułach, które już dotykasz, aby uzyskać funkcję.
- Reguła harcerska: pozostaw plik czystszy niż go zastałeś.
Typowe błędy
- „Wielki Wybuch” pisze na nowo: prawie zawsze powyżej budżetu i rzadko ukończone. Refaktoryzuj przyrostowo.
- Równe traktowanie wszystkich długów: spłacaj tylko długi, które spowalniają zespół teraz lub w pobliżu funkcji krytycznych.
- Brak widoczności: dług, który żyje tylko w głowach inżynierów, nigdy nie jest traktowany priorytetowo w stosunku do funkcji.