Technický dluh: kdy je běžnou součástí vývoje a kdy začíná brzdit projekt
Technický dluh vzniká téměř v každém projektu. Někdy vědomě, někdy nenápadně. Na začátku to bývá drobný kompromis: rychlejší řešení, odložený refaktor, chybějící test, plugin navíc, ruční proces nebo rozhodnutí, které v danou chvíli dávalo smysl.
V poslední době k tomu přibývá ještě jedna vrstva: rychlá řešení vytvořená s pomocí AI. Ta umí vývoj výrazně zrychlit, ale pokud výstup nikdo pořádně nezkontroluje, snadno vznikne kód, který sice funguje, ale nezapadá do zbytku projektu. Obchází existující pravidla, přidává další styl práce nebo jen přesouvá problém na později.
Projekt tak může dál fungovat a navenek působit v pořádku. Problém se často ukáže až ve chvíli, kdy ho chcete posunout dál: přidat novou funkci, upravit existující proces, aktualizovat technologie nebo projekt převzít do dlouhodobé správy.
Technický dluh není vždy špatně
Technický dluh je běžná součást vývoje. Někdy dává smysl zvolit jednodušší řešení, rychle ověřit nápad a neinvestovat zbytečně moc do části, která se může brzy změnit.
Problém není samotný kompromis. Problém je, když se kompromisy začnou hromadit bez kontroly. Jeden rychlý zásah v šabloně, jedna výjimka v business logice, jeden plugin navíc nebo jedna ruční úprava na produkci samy o sobě nemusí vadit. Dohromady ale časem vytvoří systém, kterému se špatně rozumí a do kterého se hůř bezpečně zasahuje.
Dobrý technický dluh je vědomý, pojmenovaný a má důvod. Špatný technický dluh vzniká mimochodem, nikdo o něm nevede evidenci a postupně se stane běžným stavem projektu.
Kde technický dluh nejčastěji vzniká
Technický dluh často nevznikne jedním velkým špatným rozhodnutím. Spíš se do projektu postupně skládá z drobných kompromisů, které v danou chvíli dávají smysl.
Typicky jde o:
- rychlý hotfix, ke kterému už se nikdo nevrátí,
- úpravu uprostřed noci, protože něco hořelo,
- plugin navíc místo jednodušší úpravy na míru,
- napojení na API bez pořádného ošetření chyb,
- ruční proces, který měl být jen dočasný,
- chybějící testy u části, která se často mění,
- kód vygenerovaný AI bez důkladné kontroly.
Samostatně tyhle kompromisy nemusí vadit. Horší je, když se začnou sčítat a nikdo se k nim nevrací.
Najednou je objednávkový proces rozdělený mezi controller, model, listener a několik pomocných funkcí. Stejná pravidla jsou zkopírovaná na více místech. Integrace nemá timeouty, retry logiku ani dobré logování. Jednoduchá změna se pak ověřuje složitě, protože chybí testy, staging nebo jasná dokumentace.
Podobné je to i s AI. Vygenerovaný kód může lokálně fungovat, ale pokud nikdo nezkontroluje, jestli zapadá do architektury projektu, může do codebase přidat další odlišný přístup. Krátkodobě ušetří čas, ale dlouhodobě zvýší nejistotu při každé další změně.
Jak poznat, že technický dluh už vadí
Technický dluh začne být znát ve chvíli, kdy se běžné změny dělají zbytečně složitě.
Malá úprava trvá nečekaně dlouho. Jedna změna rozbije něco jinde. Aktualizace se odkládají, protože nikdo neví, co se po nich stane. Chyby se špatně dohledávají. Nový vývojář se v projektu těžko orientuje. Dokumentace neodpovídá realitě nebo úplně chybí.
Často se přidá i to, že se tým začne některým částem projektu vyhýbat. Ne proto, že by nebyly důležité, ale protože každý zásah v nich bolí a nese zbytečně velké riziko.
V tu chvíli technický dluh přestává být jen interní technická věc. Začíná ovlivňovat cenu, rychlost a bezpečnost dalšího vývoje.
Ne každý dluh má stejnou prioritu
Technický dluh nemá smysl řešit podle toho, co vývojáře nejvíc štve. Důležitější je dopad.
Některý dluh jen zhoršuje čitelnost kódu. Jiný prodlužuje vývoj každé nové funkce. Některý brání aktualizacím. Některý zvyšuje riziko bezpečnostního problému, ztráty dat nebo výpadku důležité části systému.
Seniorní práce s technickým dluhem není o tom opravit všechno, co v kódu nevypadá hezky. Je o tom poznat, které části projektu skutečně zvyšují riziko, které brzdí další vývoj a které naopak nemá smysl řešit hned, protože by náklady převýšily přínos.
Nejdřív má smysl řešit věci, které blokují bezpečné změny, zvyšují provozní riziko nebo komplikují další rozvoj. Teprve potom přichází na řadu menší úklid, sjednocení stylu a postupné zlepšování méně kritických částí.
Jak s technickým dluhem pracovat
Technický dluh se neřeší jedním univerzálním způsobem. Někdy stačí postupná údržba a cílený refaktor. Jindy dává větší smysl část projektu stabilizovat, doplnit monitoring, ověřit zálohy, připravit staging a až potom řešit větší změny.
Nejdůležitější je neřešit technický dluh pocitově. Starší kód nemusí být automaticky problém a nový přepis nemusí být automaticky lepší. Rozhodující je dopad: co dnes brzdí změny, co zvyšuje riziko výpadku, co ohrožuje bezpečnost nebo data a co bude s růstem projektu čím dál dražší.
Ne vždy je nejlepší starý projekt donekonečna opravovat. U některých projektů může být bezpečnější a dlouhodobě levnější postavit problematickou část znovu. Typicky u starších WordPress webů, kde se roky vrstvily pluginy, ruční zásahy, custom úpravy a zastaralé technologie.
To ale neznamená, že přepis je automaticky správná cesta. AI dnes dokáže výrazně zrychlit samotné psaní kódu, ale nezruší potřebu porozumět projektu. Nenahradí znalost domény, historických rozhodnutí, integrací, datových vazeb ani edge casů, které se v projektu nasbíraly během reálného provozu.
Pokud je současný stav příliš křehký, nepřehledný a každá úprava stojí neúměrně moc energie, může být nový čistý základ rozumnější než další záplaty. Pokud ale projekt funguje, má jasnou logiku a problémy jsou jen v několika konkrétních místech, bývá lepší postupná modernizace.
Dobrý první krok je technický audit. Ten pomůže rozlišit, co stačí opravit, co má smysl postupně modernizovat a kde už se vyplatí uvažovat o přepisu. Cílem není mít dokonalý projekt. Cílem je dostat technický dluh pod kontrolu tak, aby nebrzdil další rozvoj a nezvyšoval riziko každé změny.
Závěr
Technický dluh není něco, čemu se dá úplně vyhnout. Každý projekt v čase dělá kompromisy. Některé jsou rozumné, jiné se později ukážou jako problém.
Důležité je nenechat je bez kontroly. Jakmile začnou běžné úpravy bolet, aktualizace se odkládají a nikdo si není jistý, co se po změně rozbije, nejde už jen o kvalitu kódu. Technický dluh začíná ovlivňovat cenu, rychlost i bezpečnost dalšího vývoje.
Někdy stačí projekt postupně uklidit. Jindy dává větší smysl stabilizace, migrace nebo nový čistý základ. Bez technického auditu se to ale často jen hádá.
Pokud máte web nebo aplikaci, která už nějakou dobu běží a každá další změna je čím dál méně předvídatelná, audit ukáže, kde projekt opravdu stojí, co má smysl řešit hned a kde už další záplaty přestávají dávat smysl.