Technický dluh není bordel v kódu: jak poznat dluh, který stojí opravdu peníze

„Tohle je celé jeden velký technický dluh.“ Tuhle větu slyším na auditech pořád — a skoro pokaždé jí každý u stolu myslí trochu něco jiného. Někdo legacy framework, někdo dlouhou metodu, někdo prostě kód, který nepsal on. A přesně tady problém začíná: když slovo znamená všechno, přestane se podle něj dát rozhodovat.

01Slovo, které přestalo něco znamenat

Zkuste si to. Na příští poradě se zeptejte tří lidí, co je podle nich váš největší technický dluh. Dostanete tři různé odpovědi — a každá bude o jiné vrstvě problému. To není maličkost. Technický dluh má být rozhodovací pojem: má vám říct, do čeho investovat čas a do čeho ne.

Když ale „dluh“ splyne s „ošklivým kódem“, zůstane vám z něj jen pocit. A s pocitem se dá udělat jedno ze dvou špatných rozhodnutí: buď ho ignorovat, dokud něco nespadne, nebo spustit velký refaktoring, který management po dvou měsících zařízne. Užitečná verze toho slova vypadá jinak — a začíná u toho, kdo ji vymyslel.

02Co Cunningham doopravdy řekl

Metaforu dluhu zavedl Ward Cunningham — ano, ten od úplně první wiki — na začátku 90. let. Jeho pointa byla překvapivě jemná: je v pořádku dodat kód s neúplným pochopením problému, pokud ho pak, jak se vaše chápání zlepšuje, průběžně narovnáváte. Tomu narovnávání se říká refaktoring a je to splátka dluhu.

Všimněte si, co tím Cunningham říká a co ne. Dluh není ten neuklizený kód. Dluh je mezera mezi tím, co kód vyjadřuje, a tím, co jste se mezitím o doméně naučili. Cunningham to později řekl natvrdo: psát schválně špatný kód a říkat tomu „dluh“ nikdy nebyla jeho myšlenka.

Původní metafora je tedy skoro opak toho, jak ji většina týmů používá. Není to „byli jsme nedbalí“. Je to „dodali jsme, abychom se učili — a teď kódu dlužíme aktualizaci“.

03Bordel není dluh

Z toho plyne nepříjemný, ale praktický závěr. Tři sta řádků v jedné metodě, zkopírovaný blok, proměnná $tmp2 — pokud za nimi není žádná znalostní mezera ani vědomý kompromis, není to dluh. Je to prostě nízká kvalita.

Proč na tom rozdílu záleží? Protože každé z toho se léčí jinak:

• Bordel z nedostatku péče se neřeší „splácením“, ale standardy a review — je to problém kvality. Bordel z nedostatku dovednosti je technicky pořád ještě dluh, ale splátkou je učení, ne refaktoring. Ani v jednom případě nepomůže hodit to do backlogu na splacení — řešení leží mimo přepsání kódu.
• Dluh — vědomá nebo nově pochopená mezera — potřebuje rozhodnutí: splatit, kdy a kolik.

Když všechen nepořádek označíte za „dluh“, propašujete problém kvality do finančního slovníku — a pak ho „řídíte“ položkou v backlogu, na kterou nikdy nedojde. Správné pojmenování vám naopak rovnou řekne, kdo to má v ruce.

04Fowlerův kvadrant: čtyři druhy dluhu

Martin Fowler tohle zostřil do nástroje, který používám skoro na každém auditu — Technical Debt Quadrant. Stojí na dvou otázkách: vznikl dluh vědomě, nebo nevědomě? A bylo to rozhodnutí ukvapené, nebo rozvážné? Zkřížením vznikají čtyři políčka a v každém bydlí úplně jiný typ problému.

Rozvážně a vědomě

„Musíme to dodat teď, důsledky vyřešíme příští kvartál.“ Tým ví, co dělá, zvážil cenu a vědomě si půjčil. To je legitimní — a často i správné — rozhodnutí. Skutečná půjčka s rozumem.

Ukvapeně a vědomě

„Na pořádné vrstvení teď není čas.“ Víte to líp, ale zkratku berete bez toho, abyste cenu zvážili — protože to tak děláte vždycky. Nebezpečné políčko: tohle už není rozhodnutí, je to zvyk.

Rozvážně a nevědomě

„Teď, když je to hotové, vidíme, jak jsme to měli navrhnout.“ Dřív jste to vědět nemohli — dluh vznikl tím, že jste se něco naučili. Tohle je to zdravé jádro Cunninghamovy metafory.

Ukvapeně a nevědomě

„Co je to vrstvení?“ Cunninghamovou optikou by tohle ještě dluh byl — kód neodráží, co tým mohl vědět. Jenže v rozhodovacím slovníku se chová jinak: splátkou není refaktoring, ale učení. Když to políčko hodíte do backlogu jako „dluh na splacení“, schováte tím skutečný úkol — tým se potřebuje něco naučit, jinak vám příští kód napíše stejně.

05Kvadrant jako triage, ne jako nálepka

Kvadrant není tabulka na obdivování. Je to triage. U každého kusu dluhu položte ty dvě otázky, zařaďte ho do políčka — a podle políčka jednejte:

• Rozvážně-vědomě: půjčka s podmínkami. Splaťte ji, až se sázka vyplatí — po termínu, po launchi. Hlavně si ji zapište, ať na ni nezapomenete.
• Rozvážně-nevědomě: splácejte průběžně. Tohle je normální refaktoring, jak se učíte. Je to nejlevnější dluh a nikdy nepřestane vznikat — a to je v pořádku.
• Ukvapeně-vědomě: nedávejte do backlogu. Tohle není inženýrský úkol k vyřešení, je to systémový tlak k pojmenování. Proč tým opakovaně obchází návrh, který umí líp? Termíny stavěné bez rezervy? Odměňování za feature throughput? Review, které se ptá jen na řádky? Část odpovědí je v rukou týmu, část výš a část úplně mimo — a dokud nevíte, kde tlak vzniká, žádný refaktoring vám to neopraví.
• Ukvapeně-nevědomě: není to úkol na refaktoring. Je to úkol na učení, mentoring nebo nábor.

Druhá osa, kterou kvadrant sám nezachytí, je úrok. Stejné políčko se chová úplně jinak podle toho, jestli dluh roste s každou změnou (duplicita v hot path, chybějící testy v modulu, kterým se hýbe denně) nebo leží stranou (ošklivý kód v rohu, do kterého se rok nesáhne). Políčko vám řekne, kdo to řeší a jak. Úrok vám řekne, jestli vůbec a kdy.

06Dluh, který si můžete dovolit

Ještě jedna zkratka stojí za narovnání: „dobrý tým nemá žádný dluh“. Nemá. Tým posedlý nulovým dluhem je jako firma, která zásadně odmítá jakýkoli úvěr — pohybuje se zbytečně pomalu.

Cíl není nulový dluh. Cíl je dluh, který umíte obsluhovat. Berte ho jako portfolio: vědět zhruba, kolik dlužíte, vyhradit splácení pevný díl kapacity — třeba stálé procento každého cyklu nebo opakovaný „fixit“ — a splácet to, čeho úrok reálně roste. Dluh, který je levný, izolovaný a stabilní, může klidně ležet; splácet ho je vyhozený čas.

Dovednost není dluh vymýtit. Dovednost je ho rozpočtovat.

Dluh je ale jen jedna strana mince. Tou druhou je udržitelnost — proč je nízká cena příští změny ekonomická výhoda, ne otázka vkusu — a tu rozebírá článek Udržitelný kód je ekonomická vlastnost.

07Nejdražší dluh stejně neuvidíte v jednom souboru

Jedno upozornění, ať kvadrant nepřeceníte. Třídí položky — metodu, zkratku, chybějící test. Jenže ten úplně nejdražší dluh často žádná položka není. Je strukturální: bydlí ve vztazích mezi moduly, ne v jednom souboru — a nezachytí ho ani políčko kvadrantu, ani code review.

To je samostatné téma; rozebírám ho v článku Technický dluh a architektura. Berte to tak: kvadrantem tříděte to, co vidíte — a počítejte s tím, že na ten nejdražší dluh potřebujete jinou optiku.

08Závěr: dluh je nejdřív otázka klasifikace

Technický dluh je problém inženýrský až druhořadě. Nejdřív je to problém klasifikace. Otázka „máme technický dluh?“ je k ničemu — má ho každý a odpověď vám neřekne vůbec nic.

Užitečné jsou dvě jiné otázky: o jaký druh dluhu jde a jestli jsme si ho vybrali. Dokud na ně u konkrétního kusu kódu neumíte odpovědět, nemůžete rozhodnout, jestli splácet, kdo splácí — ani jestli je to vůbec dluh.

„Technický dluh“ jako mlhavá stížnost je jen šum. Jako roztříděná účetní kniha je to jeden z nejlepších rozhodovacích nástrojů, které tým má.