Technický dluh v mobilním vývoji — podstata, druhy a principy řízení

Co je technický dluh (Technical Debt)

Technický dluh (Technical Debt) — je metafora, kterou poprvé navrhl Ward Cunningham v roce 1992 na OOPSLA. Přirovnal programování k investování: nedbalý kód je půjčka. Úroky z ní jsou spláceny ve formě dodatečného času na údržbu, opravy chyb a přizpůsobení novým požadavkům. Je důležité pochopit, že dluh není vždy špatný; strategický dluh může být oprávněný.

Finanční analogie funguje téměř doslovně. Pokud si tým vezme půjčku (vydá neideální kód, aby dodržel termín), musí platit úroky. Úroky — zpomalení vývoje, chyby při změně kódu, obtížnost onboardingu nových vývojářů. Pokud se úroky stanou vyššími než náklady na refaktorizaci — je čas dluh splatit. Hlavní problém: na rozdíl od bankovní půjčky si vývojáři ne vždy uvědomují, že si vzali dluh.

Důležité upřesnění: technický dluh ≠ špatný kód. Špatný kód — důsledek nekompetentnosti. Technický dluh — vědomý kompromis. Tým chápe, že dělá neideální práci, zaznamenává to v technické dokumentaci a plánuje se vrátit ke zlepšení. Rozdíl mezi dluhem a špatným kódem je ve vědomí rozhodnutí. Proto první krok k řízení dluhu — přiznat jeho existenci.

Druhy technického dluhu

Klasifikace technického dluhu pomáhá pochopit jeho podstatu a zvolit správnou strategii splácení. Martin Fowler navrhl kvadrantový model se dvěma osami: záměrný/nezáměrný a nerozvážný/uvážlivý. Každá kombinace vyžaduje jiný přístup. Podívejme se na hlavní druhy dluhu, se kterými se setkává tým mobilního vývoje.

Záměrný a nezáměrný dluh

Záměrný dluh — tým vědomě rozhodne vydat neoptimální kód, aby dodržel termín. Příklad: spuštění MVP s jedním monolitickým ViewModel, s vědomím, že po validaci hypotézy bude ViewModel rozdělen podle domén. Takový dluh je zaznamenán v backlogu a má plánovaný termín splacení. Bez plánu se záměrný dluh stává chronickým.

Nezáměrný dluh — kód, jehož kvalita je nižší, než se očekávalo, kvůli nedostatku znalostí, chybějícímu code review nebo špatným procesům. Příklad: vývojář neznal best practices práce s Room DB a psal dotazy v UI vlákně, což způsobilo ANR. Takový dluh je nejzákeřnější — tým si ho neuvědomuje, dokud nenarazí na kritické problémy výkonu.

Dluh architektury a kódu

Architektonický dluh — nesprávný výběr vzorů nebo struktury projektu. Příklad: aplikace bez vrstvy abstrakce nad sítí, kde je Retrofit používán přímo z ViewModel. Výměna Retrofit za Ktor bude vyžadovat změnu všech ViewModel. Oprava architektonického dluhu je nejdražší, proto jsou rozhodnutí na úrovni architektury přijímána s maximální opatrností.

Dluh kódu — lokální neoptimálnosti uvnitř jedné třídy nebo metody. Příklad: dlouhá metoda s 200 řádky, kde jsou smíchány UI, business logika a práce s daty. Opraví se Extract Method za 15 minut. Dluh kódu je méně kritický, ale jeho hromadění v měřítku projektu zpomaluje vývoj neméně než architektonický dluh.

Dluh testování a dokumentace

Dluh testování — absence unit testů, UI testů nebo integračních testů. Každé ruční spuštění regrese je úrok z tohoto dluhu. Pokud v projektu nejsou automatické testy, každá změna vyžaduje hodiny ručního testování. Podle Google Testing Blog, projekty s pokrytím testů >70% 2x méně často vypouštějí chyby do produkce.

Dluh dokumentace — absence nebo zastarání architektonické dokumentace, komentářů ke složitým částem kódu, readme pro onboarding. Nový vývojář ztrácí týdny ponořováním bez dokumentace. Řešení: udržovat Architecture Decision Records (ADR) a učinit dokumentaci součástí Definition of Done pro každý úkol.

Proč je technický dluh nebezpečný

Efekt složeného úroku — hlavní nebezpečí technického dluhu. Každá nová vrstva neoptimálního kódu zvyšuje složitost systému ne lineárně, ale exponenciálně. Jednoduchý příklad: pokud modul A závisí na modulu B a oba obsahují dluh, pak změna v A vyžaduje pochopení dluhu v B. Po 10 iteracích tráví vývojář 80% času rozplétáním závislostí a jen 20% — novou funkcionalitou.

Zpomalení time-to-market — přímý důsledek dluhu. Tým tráví stále více času údržbou a stále méně novými funkcemi. Výzkum Stripe (2023) ukázal, že vývojáři tráví v průměru 17 hodin týdně prací s technickým dluhem, místo vytváření hodnoty pro byznys. V mobilním vývoji to zhoršuje nutnost podpory dvou platforem — každé s vlastními platformovými aktualizacemi.

Vyhoření týmu — ne zřejmý, ale destruktivní důsledek. Práce v kódu, kde každá změna rozbije tři další, způsobuje chronický stres. Vývojáři přestávají být hrdí na produkt, klesá motivace, roste fluktuace. Podle Stack Overflow Survey 2024 je práce s legacy kódem druhou nejčastější příčinou nespokojenosti v práci po nízkém platu.

Jak řídit technický dluh

Fowlerův kvadrant — praktický nástroj pro prioritizaci dluhu. Dvě osy: záměrný/nezáměrný a nerozvážný/uvážlivý. Nerozvážný záměrný dluh: „nemáme čas na testy, vydáváme bez nich". Uvážlivý záměrný dluh: „víme, že testy jsou potřeba, ale teď je důležitější spustit funkci — založíme úkol na testy v příštím sprintu". První vyžaduje okamžitý zásah, druhý — kontrolu.

Strategie Boy Scout Rule — „zanech kemp čistší, než jsi ho našel". Jednoduché pravidlo: při změně metody věnuj o 10% více času, aby ses ji trochu vylepšil — přejmenuj proměnnou, rozděl blok 50 řádků na dva. V měřítku týmu tento přístup poskytuje postupné snižování dluhu bez vyčleňování samostatných sprintů na refaktorizaci. Zlepšení by mělo být mikroskopické, ale pravidelné.

Vyčlenění času na řízení dluhu — známka zralosti týmu. Doporučuje se rezervovat 15–20% sprintu na technická vylepšení. To neznamená, že tým 1 den v týdnu nedělá nic jiného než refaktorizaci. Technické úkoly jsou rovnoměrně rozděleny: zlepšení metrik, refaktorizace horkých míst, aktualizace závislostí. Bez vyčleněného času dluh neustále roste.

// Strategie Boy Scout Rule v akci
// Bylo: nečitelná metoda s magickými čísly
fun calc(a: Int): Int = a * 60 * 1000

// Stalo se: čitelná metoda s konstantami
private const val SECONDS_IN_MINUTE = 60
private const val MILLIS_IN_SECOND = 1000

fun minutesToMillis(minutes: Int): Int =
    minutes * SECONDS_IN_MINUTE * MILLIS_IN_SECOND

Automatizace detekce dluhu — třetí pilíř řízení. Nastavte upozornění pro detekci dlouhých metod (>30 řádků), tříd (>500 řádků), nadměrného vnoření (>5 úrovní). Použijte Danger nebo analogy pro automatické komentáře na pull requestech: pokud metoda překročí práh složitosti, bot napíše „Tato metoda má cyklomatickou složitost 12 — prosím zvažte rozdělení". Automatizace snižuje zatížení code review.

Nástroje pro analýzu dluhu

SonarQube — nejoblíbenější platforma pro analýzu technického dluhu. Počítá „počet dní na opravu" — metriku srozumitelnou manažerům. SonarQube podporuje Kotlin, Swift, Java, Python a další jazyky. Integruje se do CI/CD pipeline a nepropustí pull request, pokud dluh překročí práh. Pro mobilní týmy je to de facto standard.

Pro Android týmy se také používají Detekt (statická analýza Kotlin) a Android Lint. Detekt počítá metriky kódu a nachází vzory Code Smell. Gradle plugin SonarQube Android spojuje výsledky do jediné zprávy. Pro iOS týmy — SwiftLint pro statickou analýzu a Periphery pro hledání nepoužívaného kódu. Xcode Organizer ukazuje metriky výkonu, které často korelují s architektonickým dluhem.

CodeClimate a CodeFactor — cloudová řešení, která analyzují GitHub/GitLab repozitáře a ukazují dynamiku dluhu. Hodnotí každý commit, umožňujíce sledovat okamžik, kdy dluh začal růst. Graf Maintainability — srozumitelný nástroj pro komunikaci s vedením: „vidíte vrchol v březnu? Tehdy jsme vynutili vydání a nashromáždili dluh na 3 dny oprav".