Technický dluh (také známý jako kódovací dluh ) je metafora pro softwarové inženýrství , která odkazuje na nahromaděné problémy v softwarovém kódu nebo architektuře spojené se zanedbáváním kvality při vývoji softwaru a způsobující dodatečné náklady na pracovní sílu v budoucnu. Technický dluh je obvykle pro koncové uživatele produktu neviditelný, ale je spojen s nedostatky v udržovatelnosti , testovatelnosti, srozumitelnosti, modifikovatelnosti, přenositelnosti . Podobně jako finanční dluh může technický dluh akumulovat „ úroky» - ztížení (nebo dokonce znemožnění) pokračování ve vývoji, další čas, který vývojáři stráví změnou softwarového produktu, opravou chyb, údržbou atd. Přestože nárůst technického dluhu obvykle negativně ovlivňuje budoucnost projektu, může také být vědomé, kompromisní rozhodnutí založené na okolnostech.
Špatný kód sám o sobě není vždy technickým dluhem, protože škoda (“úrok z dluhu”) pochází z potřeby změnit kód v průběhu času [1] .
Termín technický dluh se primárně používá ve vztahu k vývoji softwaru, ale lze jej aplikovat i na jiné oblasti inženýrství.
Někdy je tento termín použit nesprávně a označuje starší kód , který již není podporován , který je nekvalitní a byl napsán někým jiným [1] .
Běžné příčiny technického dluhu (může jich být několik) [2] :
„Úrokové platby“ se objevují jak během místního rozvoje, tak při absenci technické podpory ze strany jiných vývojářů projektu. Pokračující rozvoj projektu může v budoucnu zvýšit náklady na práci na „splácení dluhu“. Technický dluh se splácí pouhým dokončením nedokončené výroby.
Hromadění technického dluhu je hlavní příčinou zpoždění projektů. Je těžké přesně odhadnout, kolik práce je potřeba vykonat ke splacení dluhu. S každou změnou se do projektu přidává neomezené množství rozpracované výroby. Termíny „hoří“, když projekt pochopí, že je stále mnohem více rozpracovaného (dluhu) než času na jeho dokončení. Aby měl vývojový tým předvídatelné plány vydání, musí omezit množství prováděné práce na úroveň, která minimalizuje množství probíhající práce (technický dluh).
Zatímco zákon o rostoucí složitosti Mannyho Lehmana již prokázal, že neustálý vývoj programů zvyšuje jejich složitost a zhoršuje jejich design, zatímco se na nich pracuje, Ward Cunningham poprvé provedl srovnání mezi technickou složitostí a dluhem ve zprávě z roku 1992:
Ve svém článku z roku 2004 „Refaktoring se vzory“ Joshua Kerievsky argumentuje pro srovnání nákladů na řešení nekalých praktik v architektuře, které popisuje jako „strukturální dluh“ [5] .
Mezi akce, které mohou být zpožděny, patří dokumentace, psaní testů, věnování pozornosti komentářům označeným „TODO“, boj s kompilátorem a varování před statickou analýzou kódu . Mezi další případy technického dluhu patří znalostní báze, která není sdílena v rámci organizace, a kód, který je příliš složitý na to, aby jej bylo možné snadno změnit.
U softwaru s otevřeným zdrojovým kódem je zdržení s odesláním místních změn hlavního projektu technickým dluhem. .