Technický dluh je něco, s čím se dříve nebo později setká každý projekt. Na začátku působí nenápadně – pár kompromisů, trochu uspěchaný kód, odložená dokumentace. Všechno funguje a zdá se, že není důvod se vracet zpět. Jenže postupně začnou tyhle drobnosti růst. Nové funkce se přidávají složitěji, opravy trvají déle a vývoj začíná ztrácet dech.

Setkávám se s tím u menších webů ve WordPressu i u složitějších aplikací psaných na míru v Laravelu. Technickému dluhu se úplně vyhnout nedá, ale dá se řídit. A právě to rozhoduje o tom, jestli projekt bude dlouhodobě udržitelný, nebo se postupně zastaví.

Jak se zrodil pojem technický dluh

Termín „technický dluh“ poprvé použil Ward Cunningham už v roce 1992. Tehdy mluvil o kódu, který funguje, ale není správně napsaný. Dnes má pojem mnohem širší význam – zahrnuje cokoliv, co při vývoji odkládáme. Může to být test, který se měl dopsat, dokumentace, která nikdy nevznikla, oprava chyby, která se odsouvá, nebo i modernizace technologie, která už dávno zastarala.

Jinými slovy, technický dluh je všechno, co se odkládá „na později“ a časem to začne brzdit.

Kdy vzniká technický dluh?

Technický dluh má vždy svůj důvod. Většinou se objeví, když dostane přednost rychlost před kvalitou.

  • těsné termíny, kdy není čas dělat věci pořádně,
  • omezené zdroje, kdy je cílem vůbec něco spustit,
  • nezkušenost týmu, kdy rozhodnutí vypadají správně jen na první pohled,
  • časté změny zadání, které rozbijí původní architekturu,
  • zastaralé technologie, u kterých se modernizace pořád odkládá.

Sám jsem několikrát musel udělat kompromis, i když jsem věděl, že zvolená cesta není ideální. V takových chvílích je klíčové, jestli si dluh přiznáte a naplánujete jeho splacení, nebo ho necháte růst a komplikovat další vývoj.

Jaké typy technického dluhu rozlišujeme?

Technický dluh se může skrývat v různých částech projektu. Někdy je vědomý, kdy tým ví, že udělal kompromis a plánuje se k němu vrátit. Jindy vznikne nevědomě a projeví se až po čase, třeba když na projekt nastoupí nový vývojář a nestačí se divit, jak je něco řešené.

Nejčastější typy dluhů:

  • kód, který je neefektivní nebo zbytečně složitý,
  • testy, které se měly napsat, ale nikdy nevznikly,
  • dokumentace, která chybí nebo už dávno neodpovídá realitě,
  • bugy, o kterých všichni ví, ale nikdo je neopravuje,
  • infrastruktura, která se neaktualizovala a postupně přestává vyhovovat.

Důležité je i rozlišovat mezi krátkodobým dluhem, který má jasný plán rychlé nápravy, a dlouhodobým dluhem, který se odkládá měsíce i roky a postupně se stává brzdou celého projektu.

technický dluh
Zdroj: https://vincentdnl.com/en/drawings/technical-debt

Jaké následky má technický dluh?

Technický dluh se dlouho nemusí nijak projevovat. Jenže pak přijde chvíle, kdy potřebujete přidat novou funkci nebo upravit existující část systému, a najednou narazíte. Staré zkratky a kompromisy vás začnou brzdit. Vývoj se zpomalí, náklady rostou a frustrace týmu stoupá.

  • 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, což 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í.

Jak technický dluh řídit a snižovat

Technickému dluhu se úplně nevyhneš. Ale můžeš ho udržet pod kontrolou.

V praxi se mi osvědčilo: průběžně refaktorovat kód, psát stručnou, ale aktuální dokumentaci a spoléhat se na automatizované testy a CI/CD. Velký význam mají i aktualizace technologií. Projekty běžící roky na nepodporovaném PHP nebo starém frameworku jsou vždycky časovaná bomba.

Právě proto nabízím správu webu – pravidelné aktualizace, monitoring a dlouhodobou péči, která zabraňuje tomu, aby se technický dluh vůbec hromadil.

Závěr: Technický dluh je přirozený, ale nesmí se ignorovat

Technický dluh je něco, s čím musí každý tým počítat. Není to nutně špatně, ale nesmí se tvářit, že neexistuje. Důležité je mít ho pod kontrolou, zapisovat, plánovat a průběžně splácet.

Pokud se projekt staví na pevných základech, srozumitelných procesech a průběžné údržbě, technický dluh vás nezastaví. Jen připomene, že některé části systému si časem zaslouží pozornost.