Džank ve vývoji — co to je, proč je junk-kód škodlivý a jak ho odstraňovat

Co je džank?

Džank (junk code) — souhrnný termín pro kód, konfigurace a závislosti, které v projektu existují, ale nemají funkční hodnotu. Džank není nutně rozbitý nebo nepoužívaný — problém je v tom, že jeho přítomnost zhoršuje metriky projektu bez adekvátního ospravedlnění.

Džank se dělí do čtyř kategorií. První — nadbytečné závislosti: knihovny připojené pro jednu funkci, kterou lze realizovat standardními prostředky. Druhá — mrtvá zátěž: zakomentované bloky, TODO bez ticketů, prázdné metody a stub třídy. Třetí — duplicitní řešení: dvě knihovny dělající totéž (například Gson a Kotlin Serialization v jednom projektu). Čtvrtá — over-engineering: architektonické vrstvy, které se nepoužívají, ale jsou udržovány „pro budoucnost“.

Podle výzkumu Stripe Engineering Productivity (2025) zkracuje odstranění 10 procent džanku z typického projektu dobu plného sestavení v průměru o 22 procent. Důvod: každá nadbytečná závislost zvětšuje graf sestavení, každá prázdná abstrakce vyžaduje čas na pochopení, každý zakomentovaný blok odvádí pozornost.

Hlavní obtíž v boji proti džanku je absence okamžitých následků. Projekt s junk-kódem se kompiluje a funguje. Problémy se hromadí postupně: sestavování zpomaluje, počet tranzitivních závislostí roste a po roce přidání nové funkce trvá dvakrát déle, než by mělo.

Junk-závislosti a jak je identifikovat

Junk-závislosti — jsou knihovny a balíčky, které jsou připojeny k projektu, ale nejsou přímo používány v kódu, nebo jsou používány pouze v jedné funkci, kterou lze snadněji realizovat standardními API.

Typické příklady: knihovna pro práci s JSON, když projekt již používá Kotlin Serialization (dva parsery — to je džank); knihovna Apache Commons Lang pro jednu metodu StringUtils.isEmpty, kterou nahrazuje Kotlin extension isNullOrBlank; knihovna DI používaná v jednom modulu z deseti, zatímco ostatní získávají závislosti ručně přes konstruktor.

Každá nadbytečná závislost není jen kód navíc v binárce. Je to také zvětšení útočné plochy pro zranitelnosti: podle GitHub Advisory Database (2025) pochází 40 procent kritických CVE v mobilních projektech z tranzitivních závislostí, které vývojáři nekontrolují. Čím méně závislostí — tím menší útočná plocha.

Analýza závislostí Android projektu

// Zobrazit strom závislostí Gradle
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Najít nepoužívané závislosti (plugin Gradle)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Vygenerovat zprávu o nepoužívaných knihovnách
./gradlew buildHealth

Pro iOS použijte příkaz swift package show-dependencies, který zobrazuje úplný strom závislostí. Nástroj Xcode Build Timeline ukazuje, kolik času každá knihovna přidává k sestavení. Pokud knihovna zabírá 30 procent času kompilace, ale používá se na jedné obrazovce — je kandidátem na odstranění nebo výměnu.

Pro Node.js (React Native) použijte depcheck — nástroj, který najde nepoužívané závislosti v package.json, a npm-check, který navíc ukazuje zastaralé verze. Zaveďte pravidlo: každá nová závislost prochází code review s odůvodněním „proč nelze standardními prostředky“.

Mrtvé importy a zakomentovaný kód

Mrtvé importy — nejrozšířenější druh džanku. Neovlivňují běh programu, ale zvyšují dobu kompilace: kompilátor zpracovává každý import, i když není použit. Ve velkých projektech zkracuje odstranění nepoužívaných importů dobu sestavení o 5–10 procent.

Moderní IDE automaticky zvýrazňují nepoužívané importy šedě. Nastavte automatické čištění při ukládání souboru: v IntelliJ IDEA — Optimize Imports on the fly, v Xcode — Editor > Remove Unused Imports. V CI přidejte kontrolu: linter by měl blokovat commity s nepoužívanými importy.

Zakomentovaný kód — další druh džanku. Vývojáři komentují bloky, aby při refaktorování neztratili funkcionalitu. Git však uchovává úplnou historii změn: každý smazaný kód lze obnovit jedním příkazem git revert nebo git log -S . Zakomentovaný kód v masteru je neúcta k týmu: každý vývojář vynakládá mentální energii na otázku „proč je to zakomentované a kdy to má být odkomentováno“.

Pravidlo: v repozitáři není žádný zakomentovaný kód. Pokud kód není potřeba — odstraňte ho navždy. Pokud je kód potřeba, ale dočasně vypnutý — použijte feature toggle s ticketem a termínem. Komentáře typu // TODO: remove after migration — nenechávejte bez termínu. Dejte datum a nastavte připomínku v kalendáři.

Nadbytečné abstrakce a over-engineering

Over-engineering — vytváření architektonických vrstev, které neřeší aktuální problémy, ale vyžadují údržbu. To je jeden z nejobtížnějších druhů džanku, protože formálně je kód „správný“: dodržuje SOLID, je pokrytý testy a odpovídá architektuře. Problém je, že není potřeba.

Klasický příklad — abstraktní třída UseCase s jednou metodou invoke, která pouze volá repozitář. Pokud UseCase nepřidává logiku (caching, retry, transformaci), ale pouze předává volání dál — je to nadbytečná entita. Zvyšuje navigaci projektem: vývojář otevře UseCase, uvidí invoke → repository — a zavře. Čas ztracen, užitek žádný.

Další příklad — nadbytečná parametrizace. Generické rozhraní se šesti type parameters, používané na jednom místě. Každý type parameter je kognitivní zátěž: při čtení kódu musíte držet v hlavě šest typů, i když se skutečně používají jen dva. Pokud se abstrakce znovu nepoužívá — je nadbytečná.

Kritérium: pokud se abstrakce znovu nepoužívá ve třech různých kontextech — odstraňte ji. Abstrakce je ospravedlněna, když skutečně řeší problém duplicity, nikoli když předpovídá hypotetické budoucí scénáře. YAGNI (You Ain't Gonna Need It) — nejlepší princip prevence over-engineeringu.

Nástroje auditu džanku

Audit džanku vyžaduje kombinaci statické analýzy, analýzy závislostí a ruční kontroly. Zcela automatizovat vyhledávání nadbytečných abstrakcí nelze, ale technický džank (mrtvé importy, nepoužívané knihovny, zakomentovaný kód) se nástroji najde.

Pro úplný audit spouštějte buildHealth (Android) nebo depcheck (Node.js) jednou za sprint. Vytvořte dashboard v CI, který ukazuje dynamiku počtu závislostí v jednotlivých sprintech. Pokud počet roste, ale funkčnost neroste proporcionálně — tým hromadí džank.

Věnujte pozornost duplicate classes — chybě, kdy dvě knihovny obsahují stejnou třídu. To není jen džank, ale také přímý zdroj konfliktů sestavení. V Gradle se takové konflikty řeší pomocí force nebo exclude, ale každé takové řešení je signál, že jedna z knihoven je nadbytečná.

Proces pravidelného čištění projektu

Čištění džanku není jednorázová akce, ale pravidelný proces. Bez předpisů se džank vrací během dvou až tří sprintů. Nejlepší praxe — vyčlenit 10–15 procent kapacity každého sprintu na technické čištění, včetně auditu džanku.

Proces se skládá ze čtyř kroků. První — diagnostika: spuštění nástrojů, získání zprávy, prioritizace. Vysoká priorita — závislosti se známými CVE a duplicitní knihovny. Střední — mrtvé importy a zakomentovaný kód. Nízká — nadbytečné abstrakce (vyžadují ruční analýzu).

Druhý — čištění: odstranění mrtvých závislostí, nahrazení duplicitních knihoven jednou, odstranění zakomentovaného kódu. Každá změna se provádí samostatným commitem srozumitelnou zprávou: „remove unused dependency: gson (replaced by kotlinx.serialization)”, „delete commented code in LoginViewModel”.

Třetí — verifikace: sestavení projektu, spuštění testů, kontrola UI. Pokud po odstranění závislosti testy projdou — závislost skutečně nebyla potřeba. Pokud testy selžou — znamená to, že někde zůstal skrytý odkaz, který statický analyzátor neodhalil.

Čtvrtý — prevence: aktualizace check-listu code review, přidání pravidla „žádná nová závislost bez odůvodnění“ do Definition of Done, nastavení automatické kontroly v CI. Prevence je jediný způsob, jak zabránit opětovnému hromadění džanku.