Technický dluh

Dluh se nejdřív projeví jako číslo, teprve pak jako vztek. Funkce, která loni trvala dva dny, teď zabere čtyři. Po nasazení v pondělí přijde oprava v úterý. Nový vývojář potřebuje tři týdny, než udělá první bezpečnou změnu. Nic z toho není chyba, takže to nikdo nezaloží — a přesto je tým pomalejší a klient se tiše diví, proč.

Zvládnutý dluh vypadá jinak než neprojdoušený. Zvládnutý má v trackeru poznámku, vlastníka a spouštěcí podmínku — „až objednávek za měsíc přeteče 10 000, přesuneme to na pořádnou frontu“. Neprojdoušený je zřetězení stringů, kterého si nikdo nevšiml a které teď týdně stojí jeden support.

Nikdy neříkejte „ten kód je nepořádek“. Řekněte, co to stojí. „Změna ceny v e-shopu teď zabere čtyři dny vývoje místo jednoho, protože logika cen je na pěti místech“ je číslo, o kterém se klient umí rozhodnout. „Checkout má technický dluh“ je číslo, se kterým nic neudělá.

Veďte krátký veřejný registr dluhu — jeden řádek na položku, co stojí, co stojí oprava, co se rozbije, když se odloží. Sledujte tři čísla, kterým rozumí i lidé mimo vývoj: jak dlouho trvá od požadavku k nasazení, kolik dní blokuje release nějaká zkratka a kolik měsíce šlo na opravy místo na novou práci. Když má dluh číslo, řeč přestane být o vkusu a začne být o prioritách.

Měsíc jen splácet, nic nedodat, je taky špatný obchod — produkt stojí a firma platí architecturu. Obvykle dává smysl vyhradit pevný podíl kapacity, kolem 10–20 %, a nechat platit kousek dluhu každého, kdo se dotčeného kódu dotkne. Prioritizujte podle toho, kolikrát vás kód už štípl, ne podle toho, jak ošklivě vypadá.

Některý dluh je v pořádku navždy. Prototyp, který nikdy neměl žít, report, který nikdo nepoužívá, monolit, kterému se pod vaším provozem daří. Napsat „tenhle dluh přijímáme a proto“ je úplná odpověď. Nic neopravit a nic nerozhodnout je to, co se nabaluje.