Odpadový kód a nepořádek v mobilních projektech — příznaky a refaktorování

Co je odpadový kód ve vývoji

Odpadový kód (také spaghetti code, nepořádek, big ball of mud) — je metafora pro kódovou základnu, která ztratila strukturu a proměnila se v zamotaný uzel závislostí. V takovém kódu každá změna na jednom místě rozbije jiné místo a přidání nové funkcionality se stává riskantním úkolem.

V mobilním vývoji je odpadový kód obzvláště kritický: aplikace postavená na „nepořádku" začíná zpomalovat, padá na starších zařízeních a těžko prochází code review. iOS projekt bez architektury může kvůli nestabilitě neprojít App Review.

Podle údajů Stripe tráví vývojáři až 42 % pracovní doby čtením a porozuměním existujícího kódu. V projektech s odpadovým kódem tento ukazatel přesahuje 60 %, což činí vývoj extrémně neefektivním.

Původ termínů

Spaghetti code (špagetový kód) — nejstarší termín, objevil se v 70. letech 20. století. Popisuje kód s chaotickými přechody řízení, připomínající zamotané špagety.

Big ball of mud (velká blátivá koule) — termín zavedený Brianem Footem a Josephem Yoderem v roce 1997 k popisu systémů bez jasné architektury, které chaoticky „rostou".

Proč je odpadový kód nebezpečný pro byznys

Odpadový kód zpomaluje uvádění nových funkcí na trh. Tým tráví čas nikoli vytvářením hodnoty, ale snahami pochopit, jak funguje existující kód a nic nerozbít.

Podle údajů McKinsey utrácejí společnosti s nízkou kvalitou kódu o 20–40 % více na údržbu produktu a rychlost uvádění nových funkcí je 2–3krát nižší ve srovnání se společnostmi s vysokou kvalitou kódu.

Příznaky odpadového kódu a jak ho rozpoznat

Rozpoznat odpadový kód lze podle souboru objektivních příznaků, z nichž některé se měří automaticky. Čím více příznaků se shoduje — tím závažnější problém.

V průmyslu se používají metriky kvality kódu jako Halstead Complexity, Maintainability Index a Technical Debt Ratio. Znalost těchto metrik pomáhá objektivně posoudit stav kódové základny.

Copy-paste (zdvojování kódu)

Nejčastější příznak odpadového kódu — opakující se bloky kódu. Místo vyčlenění společné funkce vývojáři kopírují kód z jednoho místa na druhé s minimálními změnami.

Za normální úroveň zdvojování se považuje do 5 %. Pokud zdvojování přesáhne 15 % — to je vážný signál. Nástroje jako Simian a PMD Copy Paste Detector pomáhají detekovat copy-paste automaticky.

Dlouhé metody a třídy

Metoda delší než 100 řádků — zřejmý příznak odpadového kódu. Taková metoda obvykle dělá příliš mnoho věcí a porušuje princip jediné odpovědnosti (Single Responsibility).

Třídy s více než 1000 řádky kódu jsou také problematické. Obsahují nesouvisející funkcionalitu, což ztěžuje testování, pochopení a úpravy kódu.

Vysoká cyklomatická složitost

Cyklomatická složitost podle McCabea (Cyclomatic Complexity) — metrika ukazující počet nezávislých cest v kódu. Hodnota nad 15 je považována za problematickou.

Metody se složitostí nad 30 — „zóna katastrofy". Obsahují příliš mnoho větvení, nelze je testovat ani pochopit bez hluboké analýzy.

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

Odpadový kód nevzniká „sám od sebe" — je vždy výsledkem konkrétních procesů a rozhodnutí v týmu. Pochopení příčin umožňuje zabránit jeho vzniku v budoucnu.

Podle údajů JetBrains Developer Ecosystem 2024 67 % vývojářů přiznává, že píší horší kód, než by mohli, kvůli nedostatku času. To je hlavní příčina hromadění technického dluhu.

Spěch a termíny

Nejčastější příčina — napjaté termíny. Tým píše kód „jak to vyjde", jen aby stihl termín. Refaktorování, testy a code review se odkládají „na později".

Problém je, že „později" nikdy nepřijde — v dalším sprintu se objeví nové termíny a technický dluh se hromadí jako sněhová koule.

Chybějící code review

Bez code review každý vývojář píše ve svém stylu, používá vlastní vzory a zanechává vlastní „nástrahy". Postupem času kódová základna ztrácí jednotnost.

Týmy, které praktikují povinné code review pro každý pull request, mají podle výzkumu SmartBear 2024 o 60 % méně defektů v produkci.

Slabá architektura od začátku

Pokud projekt začíná bez jasné architektury, odpadový kód je nevyhnutelný. První „rychlá řešení" pokládají základ, na kterém je později obtížné postavit něco kvalitního.

V mobilním vývoji by volba architektury (MVC, MVP, MVVM, Clean Architecture) měla být vědomým rozhodnutím učiněným před zahájením psaní kódu, nikoli výsledkem evoluce.

Metody boje s odpadovým kódem

Boj s odpadovým kódem vyžaduje systematický přístup a disciplínu celého týmu. Neexistuje jediný nástroj nebo praxe, které by problém vyřešily — je potřeba soubor opatření.

Hlavní princip — nedopustit odpadový kód ve fázi psaní, místo opravování později. Prevence je vždy levnější než refaktorování existujícího „nepořádku".

Standardy kódování

Jednotný styl kódu — základ prevence odpadového kódu. Standardy kódování (Code Style) by měly být zdokumentovány a automaticky kontrolovány lintery.

Pro iOS se používá SwiftLint, pro Android — Ktlint a Detekt. Nastavení pravidel v konfiguračním souboru umožňuje automaticky zamítat pull requesty porušující standardy.

Pravidelné refaktorování

Refaktorování — není oprava chyb, ale zlepšení struktury kódu bez změny jeho chování. Mělo by být pravidelnou součástí vývojového procesu, ne samostatným projektem.

Doporučuje se vyčlenit 20 % času každého sprintu na refaktorování a splácení technického dluhu. To zabraňuje hromadění „nepořádku" a udržuje rychlost týmu dlouhodobě.

Povinné code review

Každý pull request by měl projít review alespoň jednoho vývojáře. Code review odhaluje nejen chyby, ale také porušení architektury, stylu a potenciální zdroje odpadového kódu.

Dobrá praxe — kontrolní seznam pro code review zahrnující kontrolu copy-paste, délky metod, cyklomatické složitosti a pokrytí testy. Bez kontrolního seznamu recenzenti přehlédnou až 50 % problémů.

Nástroje pro čištění kódové základny

Moderní nástroje analýzy kódu umožňují automaticky detekovat odpadový kód, měřit technický dluh a kontrolovat kvalitu. Integrace těchto nástrojů do CI/CD pipeline zajišťuje nepřetržité monitorování.

Doporučuje se používat alespoň jeden statický analyzátor a jeden nástroj pro měření metrik. Dodatečně lze připojit platformu pro agregaci dat o kvalitě kódu.

Statické analyzátory

• SonarQube — přední platforma analýzy kvality kódu, podporuje 30+ jazyků a poskytuje metriky Technical Debt Ratio
• ESLint — standard pro JavaScript a TypeScript, konfigurovatelný pomocí konfiguračních souborů a integrovaný do IDE
• SwiftLint — povinný nástroj pro iOS projekty, kontroluje shodu se Swift Style Guide

Podle údajů SonarSource týmy používající statickou analýzu snižují počet chyb v produkci o 30 % již v prvním čtvrtletí po zavedení.

Nástroje měření metrik

CodeClimate a Codacy — platformy agregující metriky kvality kódu, sledující dynamiku a ukazující „horká místa" — soubory s největším technickým dluhem.

Pro Android projekty Detekt poskytuje více než 100 vestavěných pravidel analýzy, včetně kontrol cyklomatické složitosti, délky metod a duplikace kódu.