Dług techniczny

Dług techniczny to skumulowany koszt decyzji wdrożeniowych, które były celowe w danym momencie, ale spowalniają lub zwiększają ryzyko przyszłych zmian. Metafora ta pochodzi od Warda Cunninghama: pożyczanie pod zastaw przyszłych możliwości szybszego wprowadzania zmian, z odsetkami płaconymi od każdej kolejnej zmiany, aż do momentu spłaty długu. Podobnie jak dług finansowy, nie jest on z natury zły, a istotne rozróżnienie polega na tym, że dług zaciągnięty celowo z jakiegoś powodu jest zaciągnięty z zaniedbania.

Wartość tej metafory polega na tym, że kompromis staje się możliwy do omówienia z osobami, które nie piszą kodu. Ujęcie wniosku o refaktoryzację jako spłaty długu przekazuje coś, czego nie przekazuje wniosek o przepisanie modułu, a mianowicie, że koszt jest już ponoszony, w postaci wolniejszej realizacji i wyższego wskaźnika defektów, a pytanie brzmi, czy nadal go ponosić. Oryginalne sformułowanie Cunninghama podkreślało również, że dług powstaje z rosnącej rozbieżności między strukturą kodu a aktualnym zrozumieniem problemu przez zespół, co jest szerszą koncepcją niż po prostu pisanie niechlujnego kodu pod presją terminu.

Pod tym terminem grupuje się kilka odrębnych kwestii, które wymagają różnych reakcji. Celowe zadłużenie, zaciągane świadomie, aby dotrzymać realnego terminu i mieć plan jego rozwiązania, jest uzasadnioną decyzją inżynierską. Przypadkowe zadłużenie, powstałe w wyniku poprawy zrozumienia zespołu po ustaleniu projektu, jest nieuniknione i stanowi normalny koszt uczenia się. Zadłużenie z zaniedbania, wynikające z braku testów, nieudokumentowanego zachowania i nieutrzymywanych zależności, kumuluje się po cichu i jest najdroższą kategorią, ponieważ sprawia, że ​​każda zmiana jest bardziej ryzykowna. Przestarzałe zależności w szczególności niosą ze sobą ryzyko naruszenia bezpieczeństwa, a nie tylko niedogodności.

Symptomy są widoczne w metrykach dostaw, zanim pojawią się w kodzie. Rosnące szacunki kosztów podobnej pracy, rosnący udział mocy obliczeniowej przeznaczanej na defekty, niechęć do ingerencji w konkretne obszary oraz zmiany w jednym miejscu, które powodują awarie niezwiązane z nimi rzeczy, wskazują na znaczny wzrost odsetek. Zespoły często zgłaszają te objawy jako problemy z mocą obliczeniową i proszą o więcej osób, co zazwyczaj pogarsza sytuację w krótkim okresie.

Zarządzanie nim wymaga, aby prace były widoczne w tym samym procesie planowania, co wszystko inne. Zadłużenie ujęte na osobnej liście, którym zajmuje się tylko wtedy, gdy istnieją wolne moce przerobowe, nigdy nie jest rozpatrywane, ponieważ nigdy nie ma wolnych mocy przerobowych. Przydzielenie mu stałej części każdego cyklu lub powiązanie działań naprawczych z pracami w obszarach podlegających zmianom to dwa podejścia, które przetrwają presję komercyjną. Alternatywa, okresowe, duże przeróbki, jest zazwyczaj objawem zbyt długiego odkładania prac i niesie ze sobą znacznie większe ryzyko niż stopniowe ulepszenia.

Przedstawienie argumentów za naprawą sprawdza się lepiej w kontekście realizacji niż w kontekście inżynieryjnym. Stwierdzenie, że zmiana w danym obszarze zajmuje obecnie trzy razy więcej czasu niż w obszarach porównywalnych, poparte dowodami z niedawnych prac, łączy problem z czymś, na czym interesariusze nietechniczni już się koncentrują, podczas gdy opisanie problemów architektonicznych nie. Tam, gdzie dług niesie ze sobą ryzyko, a nie koszt, jak w przypadku nieutrzymywanych zależności lub braku pokrycia testami ścieżek krytycznych, ujęcie go jako ekspozycji z prawdopodobieństwem i wpływem jest skuteczniejsze niż ujęcie go jako jakości. W obu przypadkach kwantyfikacja bieżących kosztów przekształca preferencje inżynierskie w uzasadnienie biznesowe, które może konkurować z pracami nad funkcjonalnościami o wydajność.

Nie wszystkie długi powinny być spłacane. Kod, który działa, zmienia się rzadko i nie powoduje problemów, może pozostać niezmieniony, niezależnie od jego wyglądu, a wysiłek włożony w jego ulepszenie nie przynosi żadnych korzyści. Ekonomicznie rozsądne podejście koncentruje działania naprawcze tam, gdzie zmiany są częste i gdzie odsetki są faktycznie spłacane. Uwidocznienie tego kompromisu i zarezerwowanie dla niego wyraźnej możliwości w planowaniu jest normalną częścią tego, jak działa system. rozwój produktów zaangażowanie jest ustrukturyzowane i należy do dyskusji na temat planu działania w ramach studio produktowe zamiast traktować to jako kwestię inżynieryjną, niezwiązaną z rozmową o produkcie.