Technický dluh: Co to je, jak vzniká a jak ho efektivně řešit

S pojmem technický dluh jsem se poprvé setkal už na začátku své vývojářské dráhy – a musím říct, že čím víc projektů máte za sebou, tím lépe mu začnete rozumět. Jde o situaci, kdy se kvůli tlaku na rychlost a výsledky udělá záměrný kompromis: místo ideálního řešení se zvolí to rychlé. Funguje to, ale jen krátkodobě. Dlouhodobě vás tenhle „dluh“ dožene – a někdy i s úroky.

Termín „technický dluh“ poprvé použil Ward Cunningham už v roce 1992. Označil tak kód, který není úplně správně napsaný – což může znít banálně, ale ve světě vývoje to má velké dopady. Dnes tím myslíme nejen špatně napsaný kód, ale obecně i věci, které jsme ve vývoji odložili: neudělané testy, chybějící dokumentaci, zastaralé technologie… zkrátka všechno, co jsme (vědomě nebo ne) nechali „na potom“.

Kdy vzniká technický dluh?

Technický dluh se neobjeví jen tak. Vzniká hlavně ve chvílích, kdy musíte něco odevzdat rychle, a kvalita jde na chvíli stranou. Zkušenější vývojář už tuhle rovnováhu většinou zná, ale i tak může nastat situace, kdy je třeba zatnout zuby a vědomě udělat kompromis. Typicky třeba:

• Když projekt tlačí termíny a není čas dělat věci pořádně.
• Když je málo lidí nebo financí a prioritou je vůbec něco spustit.
• Když tým nemá dost zkušeností a nevědomky dělá rozhodnutí, která později způsobí problémy.
• Když se často mění zadání nebo se projekt „vaří za pochodu“.
• Nebo když projekt běží na staré technologii, ale není prostor na její aktualizaci.

Sám jsem se několikrát dostal do situace, kdy jsem věděl, že tohle řešení není ideální – ale zkrátka nebylo možné to v danou chvíli udělat jinak. Rozdíl je v tom, jestli si ten dluh přiznáte, zaznamenáte si ho a časem ho splatíte. Nebo ho zametete pod koberec… a necháte ho bobtnat.

Typy technického dluhu

Technický dluh nevypadá vždy stejně. Někdy jde o vědomé rozhodnutí – „teď to obejdeme, později to opravíme“. Jindy si vývojářský tým ani neuvědomí, že si nějaký dluh právě vytváří. Může se schovávat ve složitém kódu, který se už nikdo neodváží upravit. Nebo v testech, které „se dodělají později“. Anebo třeba v dokumentaci, která měla vzniknout, ale nikdy nevznikla.

Ve světě vývoje se často používá rozdělení podle Seaman & Guo (2011), které dává velmi dobrý rámec:

• dluh za kód – nečistý, neefektivní nebo špatně navržený kód, který funguje, ale brzdí další vývoj.
• dluh za testování – chybějící testy nebo testy, které měly být napsány, ale nebyl na ně čas.
• dluh v dokumentaci – projekty bez dokumentace nebo s dokumentací, která už neodpovídá realitě.
• dluh za vady – bugy, o kterých víme, ale z nějakého důvodu jsme je ještě neopravili.
• dluh za infrastrukturu – například rozhodnutí o upgradu serveru nebo frameworku, které odkládáme. 

V praxi ale často uvažuji ještě jiný pohled – vědomý vs. nevědomý dluh.

• Vědomý dluh je ten, který si zapíšete do backlogu s tím, že se k němu vrátíte. Například když rychle spouštíte novou funkci před sezónní špičkou a víte, že část logiky je třeba časem přepsat. Typicky to vídám u e-shopů v prosinci nebo u projektů, kde se ladí MVP.
• Nevědomý dluh je zrádnější – vzniká z neznalosti nebo nedostatku zkušeností. Vývojář udělá rozhodnutí, které vypadá rozumně, ale ve skutečnosti si zadělá na problém. Tyto dluhy se odhalí často až s odstupem – třeba když do projektu nastoupí nový vývojář a nestačí se divit, jak je něco řešené.

A pak je tu ještě pohled na krátkodobý vs. dlouhodobý dluh.

• Krátkodobý dluh je v pořádku, pokud s ním počítáte a máte plán ho co nejdříve „splatit“. Třeba v dalším sprintu.
• Dlouhodobý dluh vzniká, když se určité rozhodnutí odkládá měsíce nebo roky – například kvůli přechodu na novější verzi frameworku, modernizaci databáze nebo přepsání klíčové části systému, která už dávno nevyhovuje zátěži.

V neposlední řadě se můžete setkat s dělením technického dluhu na krátkodobý a dlouhodobý. Krátkodobý dluh vzniká s předpokladem, že bude vyřešen v blízké budoucnosti, typicky v následujícím vývojovém cyklu. Týmy, které se rozhodnou pro krátkodobý technický dluh, musí mít pevný plán na jeho splacení, aby se zabránilo jeho přeměně na dlouhodobý problém. Naopak dlouhodobý technický dluh vzniká při užívání zastaralých technologií, se kterými jsou spojeny vyšší náklady na údržbu, nebo při tvorbě aplikace, jež je postavena na špatně navržené databázové architektuře nevyhovující velkému množství dat. Ačkoliv si vývojáři uvědomují nutnost redesignu, kvůli omezeným zdrojům a jiným prioritám tento úkol neustále odkládají. 

Jaké následky má technický dluh?

Technický dluh je trochu jako neviditelná zátěž – dlouho o něm nemusíte vědět, ale v určitou chvíli vám začne komplikovat život. Pokud ho včas nesplatíte, může výrazně zpomalit vývoj, zkomplikovat údržbu nebo dokonce ohrozit celý projekt.

Z vlastní zkušenosti můžu říct, že nejčastěji se to projeví ve chvíli, kdy chcete do systému přidat novou funkci, a zjistíte, že vás původní řešení brzdí víc, než by mělo. V tu chvíli už nejde jen o „neideální“ kód – jde o peníze, čas a především o nervy 😬.

Obecně jako nejčastější následky technického dluhu Rios et al. (2020) zmiňují:

• Zvýšení nákladů na údržbu a vývoj: Rychlá řešení, která „nějak fungují“, si často vyžádají složité opravy nebo přepis. A to stojí čas a peníze.
• Nízká udržovatelnost systému: Špatně navržený nebo nedokumentovaný kód ztěžuje orientaci novým vývojářům. Každý zásah je pak riziko a vývoj se zpomaluje.
• Zpoždění v dodávkách: Když se nové funkce musí přizpůsobovat starému neflexibilnímu řešení, vývoj se zadrhne. Co mělo trvat den, trvá týden.
• Finanční ztráty: Ať už přímé (více hodin vývoje), nebo nepřímé – třeba když kvůli technickému dluhu nestihnete vydat novou funkci, která měla přinést tržby.
• Rework a přepisování kódu: V krajních případech se nevyhnete přepisování celých částí systému. To je vždycky náročné a někdy i zbytečně frustrující.

A proč to celé vůbec řešit?

Protože technický dluh není jen technický problém. Je to dlouhodobý rizikový faktor, který může výrazně ovlivnit směřování celého projektu. Když se s ním pracuje vědomě a průběžně, není to problém. Ale jakmile se na něj zapomene, začne se sčítat… a nakonec se mu stejně nevyhnete.

Jak technický dluh snížit (nebo se ho úplně zbavit)

S technickým dluhem se setkávám prakticky v každém projektu, který má nějakou historii. Důležité ale je, že s ním lze pracovat – a hlavně: má smysl s ním pracovat. I malý dluh, který pravidelně řešíte, vás ve vývoji téměř nezpomalí. Naopak neřešený technický dluh dokáže pohltit desítky hodin měsíčně, aniž by si toho klient nebo někdo z týmu na první pohled všiml.

Tady je pár konkrétních přístupů, které se mi v praxi osvědčily:

• Refaktorování kódu – Refaktoring je něco, co by měl vývojový tým dělat průběžně – ne až „až bude čas“. Jde o úpravy a zjednodušení stávajícího kódu tak, aby byl přehlednější a udržitelnější. Funkčnost zůstává stejná, ale údržba je pak výrazně snazší. Často se to děje v rámci pull requestů – pokud to tým dělá správně.
• Průběžná dokumentace – Zní to nudně, ale dobrá dokumentace šetří spoustu času. Pokud máte u každé funkce krátký popis, víte, proč tam je, a jak funguje. Když pak projekt za rok převezme někdo jiný, nebude se muset hrabat ve stovkách řádků. A neudělá zbytečné chyby.
• Automatizované testování a CI/CD – Ne všechno se dá uhlídat ručně – a právě tady nastupuje automatizace. Pravidelné testy a kontinuální integrace (např. GitHub Actions, GitLab CI nebo Bitbucket Pipelines) pomáhají odhalit chyby dřív, než se dostanou do produkce. A čím méně chyb, tím méně dluhu.
• Aktualizace technologií – Setkal jsem se s projekty, které běžely roky na frameworku, který už ani neměl podporu. Problém nastane ve chvíli, kdy něco přestane fungovat nebo se objeví bezpečnostní riziko. Udržovat technologie aktuální – ať už jde o PHP, Laravel, WordPress nebo knihovny v JavaScriptu – je investice, která se vždy vyplatí.

Závěr: technický dluh je přirozený – ale musí se řídit

Závěrem bych chtěl říct jednu důležitou věc – technickému dluhu se nedá úplně vyhnout, a je to v pořádku. Každý projekt je o prioritách a hledání rovnováhy. Důležité ale je, aby byl dluh vědomý, evidovaný a časem splacený.

Pokud máte vývoj postavený na zdravých základech a s jasným procesem, technický dluh vás nebrzdí. Jen připomíná, že některé věci čekají na svou chvíli.