Jank a fejlesztésben — mi ez, miért káros a junk-kód és hogyan távolítsuk el

Mi az a jank?

Jank (junk code) — gyűjtőfogalom a kódra, konfigurációkra és függőségekre, amelyek léteznek a projektben, de nincs funkcionális értékük. A jank nem feltétlenül hibás vagy nem használt — a probléma az, hogy jelenléte rontja a projekt metrikáit megfelelő indoklás nélkül.

A jank négy kategóriába osztható. Az első — felesleges függőségek: olyan könyvtárak, amelyeket egyetlen funkcióért csatlakoztattak, amely szabványos eszközökkel is megvalósítható. A második — holt teher: kommentált blokkok, ticket nélküli TODO-k, üres metódusok és stub osztályok. A harmadik — duplikált megoldások: két könyvtár, amelyek ugyanazt csinálják (például Gson és Kotlin Serialization egy projektben). A negyedik — over-engineering: architekturális rétegek, amelyeket nem használnak, de „a jövőre” tartanak fenn.

A Stripe Engineering Productivity (2025) kutatása szerint egy tipikus projektből 10 százalék jank eltávolítása átlagosan 22 százalékkal csökkenti a teljes építési időt. Ok: minden plusz függőség növeli az építési gráfot, minden üres absztrakció időt igényel a megértéshez, minden kommentált blokk elvonja a figyelmet.

A jank elleni küzdelem fő nehézsége az azonnali következmények hiánya. A junk-kóddal rendelkező projekt lefordul és működik. A problémák fokozatosan halmozódnak fel: az építés lelassul, a tranzitív függőségek száma nő, és egy év múlva egy új funkció hozzáadása kétszer annyi ideig tart, mint kellene.

Junk-függőségek és hogyan azonosíthatók

Junk-függőségek — olyan könyvtárak és csomagok, amelyek a projekthez vannak kapcsolva, de nem közvetlenül használatosak a kódban, vagy csak egyetlen funkcióban használják őket, amely egyszerűbben megvalósítható szabványos API-kkal.

Tipikus példák: egy könyvtár a JSON-hez, amikor a projekt már használ Kotlin Serialization-t (két parser — ez jank); az Apache Commons Lang könyvtár egyetlen StringUtils.isEmpty metódushoz, amelyet a Kotlin isNullOrBlank kiterjesztése helyettesít; egy DI könyvtár, amelyet tíz modulból csak egy használ, a többiek kézzel kapják a függőségeket a konstruktoron keresztül.

Minden plusz függőség nem csak plusz kód a binárisban. Ez a támadási felület növelése is a sebezhetőségek számára: a GitHub Advisory Database (2025) szerint a mobil projektekben a kritikus CVE-k 40 százaléka olyan tranzitív függőségekre jut, amelyeket a fejlesztők nem ellenőriznek. Minél kevesebb a függőség — annál kisebb a támadási felület.

Egy Android projekt függőségeinek elemzése

// Gradle függőségi fa megtekintése
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Nem használt függőségek keresése (Gradle plugin)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Nem használt könyvtárak jelentésének generálása
./gradlew buildHealth

iOS-hez használja a swift package show-dependencies parancsot, amely a teljes függőségi fát jeleníti meg. Az Xcode Build Timeline eszköz megmutatja, mennyi időt ad hozzá az építéshez az egyes könyvtárak. Ha egy könyvtár a fordítási idő 30 százalékát foglalja el, de csak egy képernyőn használják — ez a jelölt az eltávolításra vagy cserére.

A Node.js (React Native) esetében használja a depcheck eszközt, amely megtalálja a nem használt függőségeket a package.json-ban, és az npm-check eszközt, amely emellett az elavult verziókat is jelzi. Vezesse be a szabályt: minden új függőségnek át kell mennie a code review-n annak indoklásával, hogy miért nem lehet szabványos eszközökkel.

Holt importok és kommentált kód

Holt importok — a jank leggyakoribb típusa. Nem befolyásolják a futásidejű viselkedést, de növelik a fordítási időt: a fordító minden importot feldolgoz, még ha nem is használja. Nagy projektekben a nem használt importok eltávolítása 5–10 százalékkal csökkenti az építési időt.

A modern IDE-k automatikusan szürkével jelölik a nem használt importokat. Állítsa be az automatikus tisztítást a fájl mentésekor: IntelliJ IDEA-ban — Optimize Imports on the fly, Xcode-ban — Editor > Remove Unused Imports. A CI-ben adjon hozzá egy ellenőrzést: a linkelőnek blokkolnia kell a nem használt importokat tartalmazó commit-okat.

Kommentált kód — a jank egy másik típusa. A fejlesztők blokkokat kommentálnak, hogy ne veszítsék el a funkcionalitást a refaktorálás során. Azonban a git tárolja a változtatások teljes történetét: bármely eltávolított kód visszaállítható egyetlen git revert vagy git log -S paranccsal. A kommentált kód a master-ben a csapat tiszteletlensége: minden fejlesztő mentális energiát fordít arra a kérdésre, hogy „miért van ez kommentálva és mikor kell visszakommentálni”.

Szabály: a repository-ban nincs kommentált kód. Ha a kód nem szükséges — távolítsa el végleg. Ha a kód szükséges, de ideiglenesen ki van kapcsolva — használjon feature toggle-t ticket-tel és határidővel. A // TODO: remove after migration típusú megjegyzéseket ne hagyja határidő nélkül. Tegyen dátumot és állítson be emlékeztetőt a naptárban.

Felesleges absztrakciók és over-engineering

Over-engineering — olyan architekturális rétegek létrehozása, amelyek nem oldják meg a jelenlegi problémákat, de karbantartást igényelnek. Ez a jank egyik legnehezebb típusa, mert formálisan a kód „helyes”: megfelel a SOLID-nak, tesztlefedettséggel rendelkezik és illeszkedik az architektúrába. A probléma az, hogy nincs rá szükség.

A klasszikus példa — egy absztrakt UseCase osztály egyetlen invoke metódussal, amely csak a repository-t hívja. Ha a UseCase nem ad hozzá logikát (cache-elés, retry, transzformáció), csak továbbítja a hívást — ez egy felesleges entitás. Növeli a navigációt a projekten keresztül: a fejlesztő megnyitja a UseCase-t, meglátja invoke → repository — és bezárja. Idő elveszve, haszon nulla.

Egy másik példa — túlzott paraméterezés. Egy generikus interfész hat típusparaméterrel, amelyet egy helyen használnak. Minden típusparaméter kognitív terhelés: a kód olvasásakor hat típust kell fejben tartani, holott valójában csak kettőt használnak. Ha az absztrakció nem használható újra — felesleges.

A levágási kritérium: ha az absztrakció nem használható újra három különböző kontextusban — távolítsa el. Az absztrakció akkor indokolt, ha ténylegesen megold egy duplikációs problémát, nem pedig hipotetikus jövőbeli forgatókönyveket jósol. A YAGNI (You Ain't Gonna Need It) — a legjobb elv az over-engineering megelőzésére.

Jank audit eszközök

A jank auditálása a statikus elemzés, a függőségelemzés és a kézi ellenőrzés kombinációját igényli. A felesleges absztrakciók keresése nem automatizálható teljesen, de a technikai jank (holt importok, nem használt könyvtárak, kommentált kód) eszközökkel megtalálható.

A teljes audithoz futtassa a buildHealth (Android) vagy a depcheck (Node.js) eszközt sprintenként egyszer. Készítsen egy dashboard-ot a CI-ben, amely mutatja a függőségek számának dinamikáját sprintenként. Ha a szám nő, de a funkcionalitás nem nő arányosan — a csapat jank-ot halmoz fel.

Figyeljen a duplicate classes hibára — amikor két könyvtár ugyanazt az osztályt tartalmazza. Ez nem csak jank, hanem közvetlen forrása az építési konfliktusoknak. A Gradle-ben az ilyen konfliktusok force vagy exclude segítségével oldhatók fel, de minden ilyen feloldás jelzi, hogy az egyik könyvtár felesleges.

A projekt rendszeres tisztításának folyamata

A jank tisztítása nem egyszeri akció, hanem rendszeres folyamat. Szabályzat nélkül a jank két-három sprint alatt visszatér. A legjobb gyakorlat — minden sprint kapacitásának 10–15 százalékát technikai tisztításra fordítani, beleértve a jank auditot is.

A folyamat négy lépésből áll. Az első — diagnosztika: az eszközök futtatása, jelentés beszerzése, priorizálás. Magas prioritás — ismert CVE-vel rendelkező függőségek és duplikált könyvtárak. Közepes — holt importok és kommentált kód. Alacsony — felesleges absztrakciók (kézi elemzést igényelnek).

A második — tisztítás: holt függőségek eltávolítása, duplikált könyvtárak cseréje egyre, kommentált kód eltávolítása. Minden változtatás külön commit-ban történik érthető üzenettel: „remove unused dependency: gson (replaced by kotlinx.serialization)”, „delete commented code in LoginViewModel”.

A harmadik — verifikáció: a projekt építése, tesztek futtatása, UI ellenőrzése. Ha a függőség eltávolítása után a tesztek átmennek — a függőség valóban nem volt szükséges. Ha a tesztek elbuknak — valahol maradt egy rejtett hivatkozás, amelyet a statikus elemző nem észlelt.

A negyedik — prevenció: a code review ellenőrzőlista frissítése, az „indokolatlan új függőség tilalma” szabály hozzáadása a Definition of Done-hoz, automatikus ellenőrzés beállítása a CI-ben. A prevenció az egyetlen módja a jank ismételt felhalmozódásának megakadályozására.