Technický dluh

Typické příčiny technického dluhu

1. Nekompetentní vývojáři

   Pokud zaměstnáváte nezkušené vývojáře, pravděpodobně „nabastlí“ kód tak, aby program fungoval dle požadavků, ale samotný kód je strašlivý, protože to vývojáři zkrátka neumí lépe. Typické je porušování základních pravidel, jako je KISS (keep it simpe, stupid) či DRY (don't repeat yourself).

2. Přílišný tlak na termíny

   Při vývoji software bývá obecně kladen extrémní tlak na rychlost. Například SaaS aplikace na trhu získá největší podíl, pokud daný problém zákazníků vyřeší jako první. Určitá vlastnost programu musí být implementována hned, jen tak ji lze dobře prodat (protože později už to bude běžný standard). Atd. Vývojáři jsou tedy ze strany managementu tlačeni k rychlému dodání výsledků, na úkor dlouhodobé udržitelnosti a rozšiřitelnosti software.

3. Nesprávné odhady času

   Tlak na termíny zvyšují i další faktory. Typicky je to špatný odhad času potřebného na vývoj, pokud na začátku není k dispozici přesné a kompletní zadání. Nebo pokud se zadání v průběhu vývoje změní, ať už v důsledku změny pohledu zákazníka, změn parametrů trhu či třeba změn legislativy. Odhady pracnosti pochopitelně také haprují, pokud tým na daném typu projektu pracuje poprvé.

4. Špatná architektura programu

   Jsou-li vývojáři nezkušení, nepostaví aplikaci správně, například na MVC architektuře, nebo strukturu aplikace celkově špatně navrhnou. Nejhorší variantou je pak tzv. špagetový kód, který prakticky nelze upravovat s rozumnými náklady. Ale problém může vznikat také postupně – jak se program rozrůstá, původní struktura aplikace přestává stačit. Nebo je potřeba změnit datový model apod. To se často děje při agilním přístupu, který vývoj značně fragmentuje a může se pak ztrácet celkový pohled.

5. Zastaralé vývojové postupy

   Technický dluh často vzniká ve chvíli, kdy je projekt vyvíjen živelně, bez důkladnější analýzy. Dalším častým zdrojem problémů bývá, když vývojáři nepíší testy, které lze před publikací nové verze automatizovaně spustit a tím ověřit, že se úpravou programu nic nerozbilo. Ale i když aplikaci poctivě vyvíjíte podle nejnovějších poznatků, vývojové postupy se časem zdokonalují a pokud se nedokážete držet trendů, vaše aplikace rychle zastará.

6. Chybějící dokumentace

   Určitě si to umíte představit – program funguje už roky, postupně na něm přibývají funkce, několikrát se vyměnili odpovědní lidé, nikdo už vlastně neví, co vše je v kódu „zadrátováno“. A pokud budeme chtít udělat zásadní změnu, nelze vůbec odhadnout, co vše to ovlivní, jak to bude náročné a kolik to vlastně bude stát.

7. Zastarávání technologií

   Další příklad, kdy technický dluh na projektu narůstá samovolně. Například si necháte postavit nový e-shop na serverovém jazyku PHP v té době aktuální verze. Ale PHP se postupně vyvíjí, vznikají nové verze. Takže po pár letech už daný e-shop nesplňuje aktuální požadavky na bezpečnost, rychlost apod., i když byl třeba napsán téměř dokonale. A nakonec ho už ani nedokážete provozovat, protože zkrátka neseženete hosting, který by původní verzi PHP podporoval.

Druhy technického dluhu

Podle toho, jak dluh vzniknul

• Nevědomý technický dluh – nedostatky implementace, které nevznikly úmyslně. Většinou pramení z nezkušenosti vývojářů. O dluhu nikdo neví, a ten přesto projekt ničí.
• Vědomý technický dluh – víme, že nestíháme, tak to teď nějak nacvakáme a k dokonalosti to opravíme příště. Takový postup nemusí být špatně, na e-shopech se to například obvykle děje v extrémně exponované předvánoční sezóně.
  • Krátkodobý technický dluh – předpokládáme, že to opravíme hned v příštím vývojovém cyklu.
  • Dlouhodobý technický dluh – dluh, který v systému přežívá dlouho, byť se o něm ví.

Podle toho, kde se dluh nachází

• Technický dluh v kódu – typické je třeba nesprávné pojmenování funkcí či proměnných (takže se v kódu obtížně orientuje), opakování stejného kódu na různých místech (takže je obtížné danou věc rychle upravit), velká provázanost kódu nebo vytváření příliš složitých komponent…
• Designový technický dluh – například když kvůli rychlosti implementujeme prvek uživatelského rozhraní tak, že není v souladu s design manuálem.
• Technický dluh v testech – vzniká, když danou funkci rovnou neprokryjeme automatickými testy a při dalším vývoji nelze tedy nelze ověřovat, že funguje správně.
• Technický dluh v dokumentaci – dokumentace vůbec neexistuje, nebo je aplikace v jiném stavu než její dokumentace. Takže například nelze projekt rychle předat jinému vývojáři.

Důsledky technického dluhu

Typické důsledky

• Všechny úpravy trvají déle – každá minuta, kterou vývojáři stráví nad špatným kódem, se počítá jako úroky technického dluhu. A jak dluh roste, prodlužuje se i doba úprav.
• Nesedí odhady pracnosti – u špatného kódu je prostě obtížné odhadovat pracnost úpravy. A v kódu navíc čekají různá překvapení, která mohou čas úprav protáhnout i několikanásobně.
• Tým nestíhá termíny – praktický důsledek předchozích dvou problémů. Při větším technickém dluhu se pak termíny posunují opakovaně.
• Stoupá počet chyb v aplikaci – software není odladěný, konzistentní a stabilní. Možná také funguje příliš pomalu.
• Vývoj je dražší a dražší – až někdy dosáhne ceny, kterou už není nikdo ochoten zaplatit.
• Vývojáři jsou demotivovaní – nepracují stejně efektivně jako dříve, práce je nebaví, či dokonce z projektu odcházejí.

Technický dluh zvyšuje fluktuaci zaměstnanců

Na projektu s příšernou kódovou základnou nechce nikdo pracovat dobrovolně. Podle studie společnosti Stepsize z roku 2021, kterou provedli mezi více než 300 vývojáři z celého světa, 82 % inženýrů a programátorů je se svou prací v důsledku technického dluhu nespokojeno. A 51 % vývojářů dokonce opustilo kvůli technickému dluhu svou práci, nebo to minimálně zvažují.

A pokud o zaměstnance přijdete, nové lidi už neseženete – schopní vývojáři pochopitelně dají přednost projektům s čistým a elegantním kódem. A jestliže i tak nějaké získáte, technický dluh ztěžuje onboarding a programátorům trvá dlouho, než kód programu pochopí a do projektu se zapracují.

Kdy technický dluh nevadí

Vytváření technického dluhu nemusí vždy znamenat, že je něco špatně. Kromě již zmiňované vánoční sezóny u e-shopů existují i další příklady, kdy byznys zkrátka převáží nad udržitelností. Třeba pokud splněním šibeničního termínu získáme zajímavou zakázku. Jen je pak potřeba technický dluh splatit dodatečně. A počítat s tím, že upravovat projekt běžící v ostrém provozu bývá několikanásobně dražší, než když jej rovnou postavíte správně.

Někdy dokonce dává smysl co nejrychleji postavit celou funkční aplikaci, byť nebude pokrytá testy, patřičně zdokumentovaná a v jejím kódu se vyzná jen její autor. Například jste-li start-up a potřebujete si co nejlevněji a nejrychleji potvrdit, že o váš produkt vůbec bude na trhu zájem. Tzv. Minimum Viable Product.

Jak technický dluh snižovat

Vysvětlovat technický dluh zaměstnancům

Zaprvé je třeba o technickém dluhu hovořit napříč celou organizací. Významným krokem už bývá, když jeho existenci vůbec veřejně přiznáte a uděláte z toho téma. Dále je potřeba vysvětlit lidem – nejen programátorům a softwarovým inženýrům, ale také manažerům – proč je technický dluh pro společnost takový problém a proč se firmě vyplatí investovat zdroje do jeho průběžného snižování, i když tato práce zdánlivě nepřináší žádný zisk

Změna procesů

Zadruhé, napříč celou firmou je potřeba hledat a zavádět procesy, které technický dluh sníží. A které také zajistí, že se dluh nebude zbytečně zvyšovat. Začíná to třeba už u obchodníků, kteří by měli při kalkulaci projektu započítávat patřičné rezervy k odhadům pracnosti. Firma by také měla hledat cesty, jak se lépe bránit vnějším tlakům, které mění zadání v průběhu vývoje, zapracovat na design systému, pravidelně své vývojáře vzdělávat apod.

Dokumentace technického dluhu

Je třeba technický dluh – alespoň ten známý – průběžně zaznamenávat na jedno místo. Pokaždé, když se vývojáři úmyslně dopustí nějaké zkratky či narazí na problém, který by šel vyřešit lépe, měli by si o tom učinit poznámku. Ale ne do samotného kódu, protože pak neexistuje celkový přehled. A daný dokument by měl být dostupný pro všechny zúčastněné, včetně managementu.

Existují také nástroje, které umožňují v kódu identifikovat místa s největší pravděpodobností technického dluhu (např. SonarQube).

Prioritizace problémů

Technický dluh se může v systému kumulovat na mnoha úrovních. Je tedy potřeba dobře zvážit priority a zaměřit úsilí vývojářů tam, kde se úpravami dluh nejvíce sníží. Či kde úprava programu nejvíce zabrání dalšímu hromadění technického dluhu do budoucna.

Refaktoring kódu

Refaktoring znamená úpravy kódu programu tak, že se sice nepřidává nová funkčnost, ale vylepšuje se čistota kódu, jeho čitelnost, dlouhodobá udržitelnost a budoucí rozšiřitelnost. Kód programu se upravuje v malých krocích, kdy po každé změně pomocí testů ověříme, že funkčnost aplikace zůstala plně zachována.

Většinou není možné investovat z ničeho nic všechen čas vývojářů do refaktoringu, protože pak v aplikaci nepřibývají nové funkce – a to zákazníci špatně nesou. Také management obvykle očekává, že vývojáři mají kód aplikace v pořádku. Refaktoring kódu je tedy potřeba dělat průběžně. V závislosti na velikosti technického dluhu dává smysl do něj investovat cca 20–40 % času vývojářů.

Celkové přepsání programu

Dosáhne-li technický dluh opravu kritické výše, nezbude než přepsat program úplně od nuly. Je to však velmi složitý proces. Nejdříve musíte celou aplikaci zmapovat, popsat veškerou její funkčnost. Obvykle neexistuje dokumentace, takže je třeba projít celý kód programu řádek po řádku a přesně pochopit, co dělá. To samo je u špatně strukturovaného programu opravdu náročné.

Následně začnete vyvíjet nový program, což trvá dlouho, dle složitosti software v řádu desítek měsíců či jednotek roků. To znamená, že musíte paralelně udržovat starou i novou verzi aplikace. A po celou dobu děláte veškeré úpravy dvakrát. Také potřebujete dva vývojářské týmy – a ty musíte oba zaplatit.

Autor pojmu

Termín „technický dluh“ poprvé použil jako metaforu Ward Cunningham ve svém článku v roce 1992. Od té doby se však obsah pojmu mírně posunul.