Technický dluh: příklady a jak ho vysvětlit vedení
Technický dluh je práce, kterou platíte v budoucnu za ústupky z minulosti. Ukážeme příklady, jak ho evidovat a jak ho vysvětlit vedení.
Shrnutí a kontext
Každé dočasné řešení má svoji dobu trvání a je to přesně „1 furt“. Technický dluh je práce navíc, kterou bude tým muset udělat později, protože zvolil rychlejší nebo jednodušší řešení. Stejně jako finanční dluh má bohužel také úroky: každá změna v dotčené části kódu trvá déle, je složitější nebo riskantnější. V článku najdete typy technického dluhu s příklady, šablonu pro evidenci a postup, jak dluh komunikovat směrem k managementu.
1. Co je technický dluh
Technický dluh je rozdíl mezi tím, jak kód nebo infrastruktura vypadají, a tím, jak by měly vypadat. Pojem zavedl Ward Cunningham v roce 1992, když vedení finanční firmy vysvětloval, proč je potřeba vracet se k hotovému kódu. Podrobněji ho rozebírá Martin Fowler.
Ovšem ne každá chyba je dluh. Chyba je místo, kde aplikace nedělá, co má. U dluhu aplikace funguje, jen každá další změna stojí víc času a nese větší riziko. Úrokem je právě ten čas navíc, splátkou refactoring, aktualizace nebo přepsání.
Je důležité říct, že ne každý dluh vzniká úmyslně. Dluh může vzniknout z nedostatku znalostí, změnou požadavků, technologií nebo prostředí.
2. Typy technického dluhu a příklady
Technický dluh nevzniká jen v kódu. Pro plánování se vyplatí rozdělit ho podle místa vzniku, protože každý typ se splácí jinak.
Martin Fowler dělí dluh na vědomý a nevědomý a na rozumný a lehkomyslný (kvadrant technického dluhu). Pokud máte plán a termín splacení dluhu, jedná se o rozumný vědomý dluh. Kód, který vznikl bez znalosti lepšího řešení, je dluh nevědomý a zjistí se až později.
| Typ | Příklad | Co stojí (úrok) |
|---|---|---|
| Kód | Stejná validace zkopírovaná na pěti místech | Oprava se musí udělat pětkrát a jedno místo se snadno vynechá |
| Architektura | Objednávky i faktury sdílejí jednu databázovou tabulku | Změna ve fakturaci rozbíjí objednávky |
| Závislosti | Framework ve verzi, které skončila podpora | Bez bezpečnostních záplat a aktualizace je čím dál větší riziko provozu |
| Testy | Platební modul bez automatických testů | Každé vydání vyžaduje ruční přetestování plateb |
| Dokumentace | Postup nasazení zná jen jeden vývojář | Bez něj se nasazovat nedá |
| Infrastruktura a build | Ruční nasazení kopírováním souborů na server | Každé nasazení trvá dlouho a dá se v něm udělat chyba |
3. Jak poznat, že vás technický dluh zpomaluje
Technický dluh se projevuje v číslech, která tým často již sleduje. Změny v jednom modulu opakovaně trvají déle než odhad, chyby se vracejí do stejné části kódu a aktualizaci se nikdo nechce ujmout, protože je nekonzistentní se zbytkem aplikace.
Signálem je i znalost, která existuje jen v hlavách. Když o dočasném řešení ví jen jeho autor nebo je zapsané v komentáři `TODO` v kódu, podpora u nahlášené chyby nezjistí, jestli jde o známý problém. Nový vývojář na něj pak narazí sám.
4. Dokumentace technického dluhu: co u každé položky zapsat
Dokumentace neboli registr technického dluhu je seznam problémů a jejich ocenění složitostní, cenové nebo časové. Nejlépe funguje jako štítek `tech-debt` v nástroji na sledování úkolů (GitHub Issues, GitLab, Jira), kde ho tým vidí vedle běžné práce. Samostatný dokument mimo backlog se obvykle přestane aktualizovat.
Název: Platební modul používá starou verzi SDK platební brány
Štítky: tech-debt, platby
Úrok: nová platební metoda trvá 4 dny místo 1; SDK nedostává bezpečnostní opravy
Riziko: brána ukončí podporu staré verze API 30. 6. 2027
Odhad: 3 dny (výměna SDK a testy plateb)
Kdy: před přidáním Apple Pay, plánovaným na 1. čtvrtletí
Zapsal: vývojář backendu, zkontrolováno 28. 10. 20265. Jak se technický dluh odstraní
Technický dluh se odstraní tak, že se dotčená část aplikace upraví do stavu, ve kterém se v ní dá zase rychle a bezpečně pracovat. Základním nástrojem je refactoring, tedy úprava vnitřní struktury kódu, která nemění jeho chování navenek. Podle typu dluhu k němu patří i aktualizace závislostí, modernizace architektury nebo doplnění testů.
Před refactoringem doplňte testy, které hlídají současné chování, jinak nepoznáte, jestli úprava něco nerozbila. Velký dluh splácejte po menších krocích, které jde nasadit samostatně. Přepsání celé části je až poslední možnost: trvá dlouho a během něj udržujete starou i novou verzi.
| Typ dluhu | Jak ho splatit |
|---|---|
| Kód | Refactoring: sloučit zkopírovaný kód do jedné funkce, rozdělit příliš dlouhé třídy, přejmenovat nejasné názvy |
| Architektura | Postupná modernizace: novou část postavit vedle staré a přesouvat na ni funkce po jedné (vzor strangler fig) |
| Závislosti | Aktualizace závislostí a frameworku po menších verzích; nové verze hlídají nástroje jako Dependabot nebo Renovate |
| Testy | Doplnit automatické testy nejdřív tam, kde se kód mění nejčastěji |
| Dokumentace | Sepsat postup a připojit ho k aplikaci; opakovaný ruční postup raději automatizovat |
| Infrastruktura a build | Automatizovat build a nasazení v CI/CD |
6. Jak vysvětlit technický dluh vedení
Vedení nerozhoduje o kvalitě kódu, ale o čase, nákladech a riziku. Technický dluh proto vysvětlete v těchto pojmech a s čísly z registru, ne slovy jako refactoring nebo provázanost modulů.
- 1
Začněte úrokem
Řekněte, kolik dluh stojí dnes: „Přidání platební metody nám trvá 4 dny místo 1“ nebo „Kvůli staré knihovně jsme měli 2 incidenty za čtvrtletí“.
- 2
Pojmenujte riziko s datem
Konec podpory frameworku nebo verze API platební brány je termín, kterému vedení rozumí bez technického výkladu.
- 3
Navrhněte malou konkrétní splátku
Místo „potřebujeme měsíc na přepsání“ nabídněte: „Před Apple Pay vyměníme SDK za 3 dny a další metody pak budou trvat den.“ Splátka navázaná na plánovanou funkci se schvaluje snáz.
- 4
Domluvte pravidelnou kapacitu
Pevná část každého sprintu nebo jeden den v měsíci vyhrazený na dluh je předvídatelnější než vyjednávání o každé položce zvlášť.
- 5
Ukažte, co splátka přinesla
Po splacení porovnejte čas nebo počet incidentů před a po. Při další žádosti o kapacitu máte čísla z vlastního projektu.
7. Technický dluh v agilním vývoji
Ve Scrumu i Kanbanu patří technický dluh do stejného backlogu jako nové funkce, jinak se nedostane na řadu. Product owner pak vidí, co splátka stojí a co přinese, a může ji zařadit do sprintu jako jinou práci.
Vznik nového dluhu brzdí definice hotové práce (Definition of Done), která vyžaduje testy a aktualizovanou dokumentaci. Drobný dluh se dá splácet průběžně: kdo mění soubor kvůli nové funkci, uklidí v něm i to, co s funkcí souvisí.
8. Kde má být registr technického dluhu po předání aplikace
Technický dluh patří do předávacího protokolu i do plánu údržby softwaru. Seznam opsaný do protokolu ale přestane platit s první splátkou nebo novým dluhem, proto do protokolu patří odkaz na živý registr.
V AboutTheApp připojíte k aplikaci odkaz na registr, například filtr na štítek `tech-debt` v GitHub Issues nebo v Jiře, v kategorii Sledování úkolů. Pokud registr nemá vidět klient, označte odkaz jako privátní: zobrazí se jen přihlášeným členům týmu nebo s odemykacím kódem. AboutTheApp samotný dluh neeviduje, drží odkaz na místo, kde ho tým vede, vedle repozitáře, prostředí a verzí aplikace.
Časté otázky
Co je technický dluh?
Technický dluh je práce, kterou tým odložil, když zvolil rychlejší řešení. Aplikace funguje, ale každá změna v dotčené části trvá déle, dokud se dluh nesplatí refactoringem, aktualizací nebo přepsáním.
Jaké jsou příklady technického dluhu?
Kód zkopírovaný na více místech, framework ve verzi bez podpory, modul bez automatických testů, ruční nasazení nebo postup nasazení, který zná jen jeden vývojář.
Jak vysvětlit technický dluh netechnickým lidem?
Mluvte o čase, nákladech a riziku. Řekněte, kolik dluh stojí dnes (o kolik déle trvají změny, kolik bylo incidentů), jaký termín s sebou nese a jakou malou splátku navrhujete.
Kolik času věnovat splácení technického dluhu?
Pevné číslo neexistuje. Osvědčuje se vyhradit stálou část kapacity, třeba část každého sprintu, a pořadí určovat podle úroku: nejdřív dluh v kódu, který se často mění, a dluh s termínem.
Kde vést seznam technického dluhu?
V nástroji na sledování úkolů, kde tým plánuje práci, například jako štítek v GitHub Issues nebo v Jiře. V AboutTheApp k aplikaci připojíte odkaz na tento seznam, takže ho po předání najde i nový vývojář nebo správce.
Ve zkratce
Technický dluh je v pořádku, pokud o něm víte a víte, co stojí. Registr s úroky a odkazem u aplikace z něj dělá rozhodnutí, o kterém se dá mluvit s vedením.
Chcete mít registr dluhu u aplikace?
Založte si zdarma aplikaci v AboutTheApp a připojte k ní odkaz na registr technického dluhu, repozitář a prostředí.