Technický dlh brzdí vývoj: ako ho zmerať a čo riešiť prvé

Technický dlh brzdí vývoj vtedy, keď každá nová funkcia trvá dlhšie ako tá predošlá. Pre firmu to znamená roadmapu, ktorá sa posúva, a vývojárov, ktorí hasia namiesto toho, aby stavali.

Zmerať sa dá bez drahého nástroja, z histórie gitu a z chýb. Opraviť treba najprv dlh v kóde, ktorý sa mení najčastejšie, nie ten najškaredší.

AI dnes píše všetok náš kód a za výsledok ručí senior. Filip predtým 7 rokov vyvíjal jeden SaaS produkt. Dlh v produkte, ktorý žije roky, nevyriešite jedným šprintom. Splácate ho priebežne.

Ako spoznáte, že vás brzdí technický dlh?

Dlh sa neohlási sám. Prejaví sa ako pomalosť, ktorú si každý vysvetlí inak. Tlačidlo, ktoré malo trvať deň, trvá týždeň. Zaškrtnite, čo o vašom tíme platí. Každý nezaškrtnutý bod je jeden signál dlhu.

Ako zmerať technický dlh bez drahého nástroja?

Nepotrebujete platformu na analýzu kódu. Potrebujete odpovede na otázku, kde vás zmeny stoja najviac.

Najsilnejší signál je kombinácia prvých dvoch riadkov. Súbor, ktorý sa mení často a zároveň z neho chodia chyby, je dlh s úrokom. Zoznam najčastejšie menených súborov vám dá jeden príkaz:

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

Ku každému súboru z výsledku si poznačte chyby, ktoré sa ho týkali. Prvých pár riadkov je váš zoznam.

Čo opraviť ako prvé?

Nie to, čo je najškaredšie. To, čo vás stojí najviac času práve teraz. Poradie, ktoré používame:

Na koniec patria estetika a prechod na novší framework „lebo je novší“. Kód, na ktorý mesiace nikto nesiahne, môže byť škaredý. Nestojí vás nič. Ak sa nepoužíva vôbec, nesplácame ho, ale zmažeme. Tak to robíme aj vo vlastných repozitároch: nepoužitý kód a nástroje, ktoré nikto nevolá, idú preč.

Ak je dlh v jednej časti taký veľký, že zvažujete prepis, začnite rovnako. Najprv testy na súčasné správanie, až potom rozhodnutie. Ako nastaviť testy a review, ktoré zlú zmenu naozaj zastavia, rozpisujeme v článku Ako zaviesť AI do vývojového tímu.

Ako dlh splácať bez zastavenia roadmapy?

V rovnakom toku ako funkcie. Nie v „refaktoringovom šprinte“, ktorý sa stále posúva, lebo prišla urgentná funkcia.

• Pevný podiel kapacity. Dohodnite ho s produktom vopred a nesiahajte naň pri prvej urgencii.
• Splácajte tam, kde pracujete. Keď robíte funkciu v dlhom module, upracte ho v tom istom pull requeste.
• Najprv test, potom zmena. Test na súčasné správanie zachytí, čo by ste inak pokazili.
• Žiadny nový dlh bez záznamu. Ak vedome volíte skratku, zapíšte ju ako úlohu s dôvodom.

Takto to vyzerá na jednej funkcii z roadmapy:

AI tu mení ekonomiku. Testy na existujúci kód, presuny a premenovania boli drahé, preto sa odkladali. S AI sú lacné. Bez pravidiel a review však AI dlh rovnako rýchlo pridáva. Čo jej preto dávame do repozitára, opisujeme v článku Pravidlá pre AI kód v tíme.

Prvé kroky na tento mesiac:

1. Vytiahnite z gitu zoznam najčastejšie menených súborov.
2. Ku každému si poznačte chyby za posledné mesiace.
3. Vyberte tri miesta, ktoré blokujú najbližšiu funkciu z roadmapy.
4. Dohodnite s produktom pevný podiel kapacity na dlh.
5. Overte, že CI vie zastaviť zlé zlúčenie.

Kedy to neodporúčame

• Dlh vás nebrzdí, len sa vám nepáči. Ak sa ten kód nemení, nechajte ho tak. Kapacitu dajte do roadmapy.
• Produkt sa o pár mesiacov vypína alebo nahrádza. Splácať dlh v kóde, ktorý končí, sa neoplatí.

Chcete dlh splácať s niekým, kto to robí denne?

Senior sa zapojí do vášho repozitára a pull requestov od prvého týždňa. Spláca dlh v ceste roadmapy, popri funkciách, nie namiesto nich. Takto pracujeme ako externý vývojár pre produktový tím.

Napíšte nám, ktorá časť systému vás brzdí najviac. Ozveme sa do dvoch pracovných dní a spolu vyberieme, čo vyriešime ako prvé.

Ak sa chcete najprv porozprávať, dohodnite si meeting na 15 minút s Filipom.

Ktorý súbor vo vašom repozitári sa bojí otvoriť celý tím?

Časté otázky

Ako zmerať technický dlh?

Najjednoduchšie z histórie gitu a z chýb. Súbory, ktoré sa menia najčastejšie a zároveň v nich vznikajú chyby, sú dlh, ktorý vás naozaj stojí čas. K tomu sledujte, ako sa predlžujú odhady pri malých zmenách.

Čo opraviť ako prvé?

Dlh v kóde, ktorý potrebujete pre najbližšiu funkciu z roadmapy. Potom často menený kód s chybami. Kód, na ktorý nikto nesiaha, nechajte tak, aj keď je škaredý.

Ako vysvetliť technický dlh vedeniu?

Cez čas a riziko, nie cez kvalitu kódu. Ukážte, o koľko dlhšie trvajú zmeny v konkrétnej časti a koľko chýb z nej prichádza. Najlepšie na funkcii z roadmapy, na ktorú vedenie čaká.

Zvyšuje AI technický dlh?

Bez pravidiel a review áno, lebo píše rýchlo a bez kontextu. S pravidlami v repozitári, testami a review od niekoho iného ho pomáha splácať. Testy a presuny kódu sú s AI lacné.