Šta je tehnički dug i kada ga treba otplatiti?

Tehnički dug je jaz između načina na koji je vaš softver napravljen i načina na koji bi morao da bude napravljen da bi se lako menjao. Kao i finansijski dug, nije automatski loš - to je pozajmljena brzina, i naplaćuje kamatu.

Kamata se pojavljuje kao vreme. Izmena koja bi trajala jedan dan traje tri, jer mora da se napravi na četiri mesta, a niko nije siguran šta još od nje zavisi.

Kako izgleda van inženjeringa

Osnivači retko vide tehnički dug direktno. Vide njegove simptome i obično ih pripisuju timu, a ne bazi koda.

• Procene stalno rastu za funkcije koje zvuče slično onima koje već imate.
• Svako izdanje pokvari nešto što nema veze sa onim što je menjano.
• Samo jedna osoba može bezbedno da dira određeni deo.
• Male izmene zahtevaju nesrazmerno mnogo testiranja.
• Inženjeri počinju rečenice sa „stvarno bi trebalo da prepišemo...".

Ako bi ista funkcija pre godinu dana trajala dve nedelje, a sada traje šest, ta razlika je otplata kamate.

Nije svaki dug isti

Trpanje svega u isti koš je ono što ove razgovore čini neproduktivnim. Postoje otprilike četiri vrste, i zaslužuju različite odgovore.

Samo poslednja kategorija opravdava zaustavljanje rada na funkcijama. Prve tri se rešavaju pažljivim radom na uobičajenom inženjerskom poslu.

Odakle dolazi

Dug se nagomilava iz razloga koji su u tom trenutku imali smisla.

Rokovi su očigledan razlog: prečica koja omogućava izdanje je zaista ispravna odluka kada je alternativa propušteno lansiranje. Promenljivi zahtevi su drugi - model podataka projektovan za jedan oblik proizvoda nosi dug onog dana kada proizvod postane nešto drugo, a da niko nije pogrešio.

Odlazak ljudi doprinosi više nego što se očekuje. Kod koji je napisao neko ko je otišao teže se menja ne zato što je loš, već zato što je obrazloženje iza njega otišlo sa tom osobom.

Sve više doprinosi i generisani kod: brzo se proizvodi i lako prihvata, a da niko ne stekne mišljenje o tome da li se uklapa u strukturu oko sebe.

Kako odlučiti šta popraviti

Korisno pitanje nije „da li je ovo dug?" - po nekom merilu, većina baze koda jeste. Korisno pitanje je „da li nas ovaj dug išta košta?"

Dug u kodu koji niko ne dira ne košta ništa. Neelegantan modul koji dve godine nije trebalo menjati može da ostane neelegantan zauvek. Dug u delu u koji isporučujete svake nedelje je skup, a njegova otplata odmah vraća vreme.

Zato praktičan test ima dva dela: koliko često ovo menjamo i koliko boli svaka izmena? Sve što ima visok rezultat u oba vredi popraviti sada. Sve što je nisko u bilo kom od njih može da sačeka, možda i zauvek.

Popravite dug koji se nalazi tamo gde radite, a ne dug koji vam najviše smeta.

Šta uraditi povodom njega

Tri pristupa, poređana po tome koliko su često pravi odgovor.

1. Popravljajte usput. Kada vas funkcija odvede u neuređen deo, ostavite ga malo boljim. Ovo rešava većinu duga gotovo bez vidljivog troška.
2. Zakažite konkretnu popravku. Za poznat problem sa poznatom cenom - krhku putanju plaćanja, spor upit - rezervišite je kao posao sa definisanim ishodom, a ne kao „vreme za refaktorisanje".
3. Ponovo napravite podsistem. Samo kada deo sistema zaista ne može da nosi ono što vam treba, i uz poređenje sa cenom njegovog održavanja.

Budite oprezni sa potpunim prepisivanjem. Gotovo uvek je skuplje i sporije nego što se očekuje, a suptilna ponašanja originala reprodukuje tek posle bolnog ponovnog otkrivanja. Delimična, namerna zamena određenog podsistema je gotovo uvek bolji izbor.

Kako o tome razgovarati sa timom

Inženjeri dug često pominju tehničkim terminima, zbog čega zvuči kao lična sklonost. Prevod koji ga pretvara u poslovni razgovor su trošak i rizik.

Pitajte: koliko nas ovo trenutno košta po funkciji, šta nas sprečava da uradimo i šta se dešava ako ga ostavimo još godinu dana? Inženjer koji može da odgovori na to identifikovao je stvaran dug. Onaj koji ne može možda opisuje razliku u stilu - što je u redu, ali je to drugačiji razgovor.

Ako želite spoljnu procenu stanja baze koda, upravo to radi naša revizija koda.

Česta pitanja