Mrtvý kód a zombie kód ve vývoji: co to je, příčiny a hledání

Co je mrtvý kód?

Mrtvý kód (dead code) — zdrojový kód, který je zahrnut do programu, ale není nikdy vykonán v žádném scénáři použití. Kompilátor nebo interpret jej zpracovává, ale během běhu se řízení nikdy nedostane do těchto částí.

Klasické příklady mrtvého kódu: proměnné, kterým byla přiřazena hodnota, ale nikdy se nečtou; funkce nebo metody, které nejsou nikde volány; větve podmínek, které se nikdy nestanou pravdivými (if(false)); smyčky, jejichž tělo se nevykoná ani jednou.

Podle zprávy SonarQube State of Code Quality (2025) souvisí přibližně 15 procent všech varování v komerčních projektech Java s nepoužívanými soukromými metodami a poli. V projektech JavaScript může podíl nepoužívaného kódu dosahovat 30 procent kvůli dynamické povaze jazyka a množství knihoven třetích stran.

Pravidelně kontrolujte projekt na přítomnost mrtvého kódu — zejména po velkých refaktoracích a odstraněních funkcí. Jeden zapomenutý import nebo nepoužívaná funkce dnes se zítra může proměnit v zombie kód, který mate nové členy týmu.

Rozdíly mezi mrtvým kódem a zombie kódem

Zombie kód (zombie code) — zvláštní případ mrtvého kódu, který se vyznačuje historickým kontextem. Zombie kód kdysi fungoval, ale po změnách v systému se stal nedosažitelným, přestože nebyl odstraněn, ale ponechán „pro každý případ".

Rozdíl mezi mrtvým kódem a zombie kódem spočívá v původu. Mrtvý kód mohl být napsán chybně (nikdy nefungoval), zatímco zombie kód je dříve živý kód, který ztratil aktuálnost během refaktorace. Například funkce výpočtu slevy podle staré obchodní logiky, která byla nahrazena novou, ale stará metoda nebyla odstraněna — pro případ, že by bylo potřeba ji vrátit.

Hlavní nebezpečí zombie kódu je iluze fungující funkcionality. Nový vývojář vidí funkci, čte její dokumentaci, předpokládá, že je někde volána — a ztrácí čas studiem artefaktu. Při pokusu o přímé volání se může ukázat, že závisí na odstraněných entitách nebo zastaralých API.

Sledujte zombie kód pomocí historie git: pokud se funkce nezměnila dva roky a není používána — je to zombie. Odstraňte jej bez váhání, protože git uchovává historii a v případě potřeby lze kód vždy obnovit.

Příčiny vzniku mrtvého kódu

První a nejčastější příčina — iterativní vývoj s neúplnou refaktorací. Tým přidává novou funkcionalitu nahrazující starou, ale neodstraňuje nahrazené moduly. Sprinty hromadí takové „ocasy" a po roce projekt obroste vrstvou mrtvého kódu.

Druhá příčina — A/B testování a feature toggle. Podmínky zapnutí nové funkce se mohou časem zafixovat (například vždy true), ale větev else s alternativní logikou zůstává v kódu. Vývojáři se bojí ji odstranit, aby náhodou nerozbili systém, pokud se toggle přepne zpět.

Třetí příčina — automatické generování a copy-paste. Generátory kódu (IDE, šablonovací nástroje) vytvářejí šablony s metodami, které vývojář nevyplňuje nebo nepoužívá. Zkopírovaný kód z jiného projektu často obsahuje celé bloky, které nejsou relevantní pro nový kontext.

Čtvrtá příčina — strach z odstranění. Ve velkých projektech se vývojáři bojí odstranit kód, protože nejsou přesvědčeni, že skutečně není nikde používán. Tento strach je umocněn slabým testovacím systémem: pokud není automatická kontrola, odstranění může vést k chybám, které se odhalí až v produkci.

Proč je mrtvý kód nebezpečný

Mrtvý kód přímo ovlivňuje čtyři aspekty kvality projektu: výkon kompilace, velikost artefaktu, kognitivní zátěž týmu a spolehlivost refaktorace.

Zvýšení doby kompilace: kompilátor zpracovává nepoužívané soubory, analyzuje závislosti a generuje bytekód nebo strojový kód pro fragmenty, které nikdy nebudou spuštěny. U velkých projektů to přidává minuty ke každé kompilaci. U interpretovaných jazyků (JavaScript, Python) roste doba načítání modulu a spotřeba paměti.

Riziko chyb při úpravě: vývojář při změně kódu netuší, že funkce je používána pouze v mrtvé větvi. Po refaktoraci přestane mrtvý kód kompilovat nebo generuje chyby — tým ztrácí čas diagnostikováním problému, který neovlivňuje chod aplikace.

Kognitivní zátěž — nejdražší faktor. Každá nepoužívaná funkce vyžaduje pozornost při čtení kódu. Vývojář vynakládá mentální energii na pochopení, proč tento kód existuje a kde je volán. Výzkum Developer Productivity Lab (2025) ukázal: odstranění 20 procent mrtvého kódu zkracuje dobu zapracování (onboarding time) v průměru o 18 procent.

Odstraňte mrtvý kód ihned po zjištění. Každý den prodlení zvyšuje pravděpodobnost, že někdo z týmu stráví hodiny studiem artefaktu, který měl být odstraněn včera.

Nástroje pro hledání mrtvého kódu

Hledání mrtvého kódu se provádí dvěma hlavními metodami: statická analýza (bez spuštění programu) a dynamická analýza (profilování pokrytí za běhu). Každý přístup je účinný pro různé typy mrtvého kódu.

Statické analyzátory podporují všechny populární programovací jazyky. Pro Java a Kotlin — SonarQube, IntelliJ IDEA Inspections, SpotBugs. Pro JavaScript a TypeScript — ESLint s pravidly no-unused-vars a no-unused-modules. Pro Swift — SwiftLint s pravidlem unused_declaration. Pro Python — pylint s volbou unused-import a vulture pro hloubkové vyhledávání.

Příklad hledání v Kotlin přes ProGuard

// build.gradle.kts — konfigurace ProGuard pro Android
android {
    buildTypes {
        release {
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

// proguard-rules.pro — ponechat pouze požadované třídy
-keep class com.example.app.** { *; }
-assumenosideeffects class Timber {
    static <methods>;
}

ProGuard nejen odstraňuje nepoužívané třídy a metody, ale také minimalizuje názvy v release sestavení. Sestavení s povoleným ProGuardem automaticky ukazuje, které třídy a metody jsou považovány za nepoužívané — ve zprávě usage.txt je uveden veškerý odstraněný kód.

Dynamická analýza pomocí pokrytí testy

Nástroje pro pokrytí kódu (JaCoCo pro Java, XCTest coverage pro Swift, Istanbul pro JavaScript) ukazují, které řádky a větve jsou během testů prováděny. Metody s nulovým pokrytím jsou kandidáty na mrtvý kód. Absence pokrytí však nezaručuje, že kód není volán v produkci — pro úplnou jistotu použijte kombinaci statické a dynamické analýzy.

Nakonfigurujte CI pipeline tak, aby sestavení selhalo při překročení prahu nepoužívaných deklarací. SonarQube Quality Gate s pravidlem „Podíl nepoužívaného soukromého kódu nejvýše 3%" zabraňuje hromadění mrtvého kódu na úrovni vývojového procesu.

Jak bezpečně odstranit mrtvý kód

Proces odstraňování mrtvého kódu se skládá ze čtyř kroků: najděte, zkontrolujte, odstraňte, znovu zkontrolujte. Přeskočení kteréhokoli kroku zvyšuje riziko regrese.

První krok — vyhledání kandidátů pomocí statického analyzátoru. Získejte zprávu o nepoužívaných deklaracích: funkcích, třídách, proměnných, importech. Filtrujte falešně pozitivní výsledky — analyzátory se někdy mýlí při reflexi, dynamickém načítání tříd nebo skrytých voláních prostřednictvím serializace.

Druhý krok — kontrola přes git blame a historii změn. Podívejte se, kdy a proč byl kód napsán. Pokud byl kód součástí funkce deaktivované pomocí feature toggle, ujistěte se, že je toggle zafixován a nebude znovu zapnut. Zakomentujte kód, který váháte odstranit, a ponechte TODO s úkolem na opětovnou kontrolu za měsíc.

Třetí krok — odstranění v samostatné větvi se spuštěním kompletní sady testů. Pokud testy projdou — pravděpodobnost regrese je nízká. Pokud testy selžou — znamená to, že kód je stále používán a je třeba zjistit, v jakém scénáři.

// před — mrtvý kód a zombie kód ve stejném souboru
int calculateV1(int price) { // nikde není voláno
    int tax = price * 0.18;
    return price + tax;
}

int calculateV2(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

// po — mrtvý kód odstraněn, zombie kód vyčištěn
int calculatePrice(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

Čtvrtý krok — code review změn. Recenzent musí potvrdit, že kód je skutečně mrtvý. Pokud si recenzent není jistý — ponechte komentář v kódu a odložte odstranění do úplné analýzy. Po sloučení větve větev odstraňte, abyste nemnožili zombie kód v git repozitáři.

Zaveďte pravidlo: žádný pull request nesmí obsahovat nový mrtvý kód. Přidejte linter do pre-commit hooků, který blokuje commit při výskytu nepoužívaných proměnných nebo importů. Prevence je vždy levnější než čištění.