Technický dluh (technical debt)

Příklady z praxe

1. 01

   Duplicitní výpočet DPH v e-shopu

   E-shop před kampaní rychle přidá výpočet DPH přímo do dvou různých částí aplikace. Funkce se dostane do produkce včas, ale při změně sazby musí vývojář najít a upravit více míst. Jedno místo zůstane zapomenuté, takže faktura a košík ukazují rozdílnou cenu.

   function priceWithVat(price) {
     return price * 1.21;
   }
   
   function invoiceTotal(items) {
     return items.reduce((sum, item) => sum + item.price * 1.21, 0);
   }

2. 02

   Odložené testy v administraci

   Tým spustí novou administraci bez automatických end-to-end testů, protože zákazník potřebuje demo na veletrh. První vydání proběhne rychle, ale každá další úprava vyžaduje dlouhé ruční proklikání formulářů. Po několika měsících už přidání malého pole stojí víc času než původně ušetřené testy.

Časté omyly

MýtusTechnický dluh znamená špatně napsaný kód.

Ve skutečnostiTechnický dluh může vzniknout i u kvalitního týmu jako vědomý kompromis mezi rychlostí dodání a budoucí údržbou. Problém nastává hlavně tehdy, když kompromis není pojmenovaný, sledovaný ani plánovaně splácený.

MýtusTechnický dluh vyřeší přepsání aplikace od nuly.

Ve skutečnostiPřepis může odstranit část starých problémů, ale často vytvoří nové riziko, zpoždění a ztrátu znalostí ukrytých ve stávajícím systému. Bez změny procesů se podobný dluh vrátí i do nového kódu.

Časté dotazy

Jak poznám technický dluh v projektu?

Technický dluh poznáte podle opakovaných signálů, ne podle jednoho ošklivého souboru. Typické projevy jsou pomalé změny jednoduchých funkcí, časté regrese, ruční kroky při nasazení, strach upravit starší modul a dlouhé vysvětlování pravidel, která nejsou zachycená v kódu ani testech. Dobrý indikátor je otázka, zda stejná obchodní změna stojí v čase stále víc úsilí.

Má se technický dluh řešit hned, nebo až později?

Technický dluh se obvykle nemá řešit odděleně od produktu bez jasné priority. Rozumný postup je vyčíslit dopad na rychlost vývoje, stabilitu nebo provozní riziko a splácet dluh tam, kde blokuje aktuální plán. Samostatný refaktoring dává smysl, když existuje vysoké riziko incidentu, bezpečnostní problém nebo modul, který se bude brzy výrazně rozšiřovat.

Dá se technický dluh nějak měřit?

Technický dluh lze měřit nepřímo, protože samotná kvalita návrhu nemá jednu univerzální metriku. Užitečné jsou ukazatele jako čas potřebný na běžnou změnu, počet regresních chyb, míra pokrytí kritických testů, stáří závislostí, počet ručních kroků při release nebo množství duplicit v kódu. Měření má největší hodnotu, když je propojené s konkrétním dopadem na produkt.

Jak zapisovat technický dluh do backlogu?

Technický dluh by měl být v backlogu popsaný jazykem dopadu. Položka má říkat, kde dluh vzniká, jak brzdí práci nebo zvyšuje riziko a co znamená jeho splacení. Vhodný záznam není jen „refaktorovat objednávky“, ale například „sjednotit výpočet slev, aby změna pravidel nevyžadovala úpravu ve třech službách“.

Zdroje

1. Technical debt(otevře se v novém okně)Wikipedia
2. The WyCash portfolio management system(otevře se v novém okně)ACM, 1992
3. Managing Technical Debt(otevře se v novém okně)IEEE, 2012
4. A systematic mapping study on technical debt and its management(otevře se v novém okně)Elsevier, 2016

Související pojmy

• CI/CDCI/CD je sada postupů a automatizací, které průběžně integrují změny kódu, ověřují je testy a připravují nebo provádějí nasazení aplikace. Cílem je zkrátit cestu od commitu k bezpečnému vydání, snížit ruční práci a rychle odhalit chyby v build procesu, konfiguraci nebo samotném kódu.
• Code reviewCode review je systematická kontrola změn ve zdrojovém kódu jiným vývojářem nebo týmem před jejich začleněním do hlavní větve. Pomáhá najít chyby, bezpečnostní rizika, nejasný návrh i odchylky od týmových pravidel, ale zároveň slouží ke sdílení znalostí a sjednocování stylu práce.
• RefactoringRefactoring je cílená úprava vnitřní struktury existujícího kódu bez změny jeho pozorovatelného chování. Vývojář při něm zjednodušuje návrh, pojmenování, duplicity nebo rozdělení odpovědností tak, aby se kód snáz četl, testoval a měnil, aniž by uživatel aplikace poznal rozdíl ve funkcích.
• PrototypPrototyp je záměrně neúplná, rychle vytvořená podoba produktu, funkce nebo rozhraní, která slouží k ověření nápadu před plnou implementací. V softwaru a UX pomáhá odhalit nejasné požadavky, rizikové technické části i chyby v použitelnosti dřív, než tým investuje do finálního řešení.
• Statická analýza kóduStatická analýza kódu je zkoumání zdrojového kódu nástrojem bez jeho spuštění, které hledá chyby, bezpečnostní zranitelnosti, porušení konvencí a podezřelé konstrukce. Nástroj čte kód jako strukturu (syntaktický strom, graf toku řízení a dat) a hlásí místa, která mohou selhat. Běží typicky v editoru, při commitu a v CI pipeline.
• Životní cyklus aplikaceŽivotní cyklus aplikace je posloupnost fází, kterými software prochází od prvotního záměru přes návrh, vývoj, testování a nasazení až po provoz, údržbu a konečné vyřazení. Termín se používá ve dvou rovinách: manažerské, kde popisuje řízení produktu v čase, a technické, kde označuje stavy běžící aplikace na daném zařízení nebo platformě.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.