Halott kód és zombi kód a fejlesztésben: mi ez, okok és keresés

Mi az a halott kód?

Halott kód (dead code) — forráskód, amely be van építve a programba, de egyetlen használati forgatókönyvben sem hajtódik végre. A fordító vagy értelmező feldolgozza, de futás közben a vezérlés soha nem jut el ezekbe a részekbe.

A halott kód klasszikus példái: változók, amelyekhez értéket rendeltek, de soha nem olvassák őket; függvények vagy metódusok, amelyeket sehol sem hívnak meg; feltételelkágak, amelyek soha nem válnak igazzá (if(false)); ciklusok, amelyek magja egyszer sem hajtódik végre.

A SonarQube State of Code Quality (2025) jelentése szerint a kereskedelmi Java-projektekben az összes figyelmeztetés körülbelül 15 százaléka a nem használt privát metódusokhoz és mezőkhöz kapcsolódik. JavaScript-projektekben a nem használt kód aránya elérheti a 30 százalékot a nyelv dinamikus természete és a harmadik féltől származó könyvtárak bősége miatt.

Rendszeresen ellenőrizze a projektet halott kód szempontjából — különösen nagy refaktorálások és funkciók eltávolítása után. Egy elfelejtett import vagy nem használt függvény ma holnapra zombi kóddá válhat, amely félrevezeti az új csapattagokat.

Különbségek a halott kód és a zombi kód között

Zombi kód (zombie code) — a halott kód egy speciális esete, amelyet történelmi kontextus különböztet meg. A zombi kód valaha működött, de a rendszerben végrehajtott változtatások után elérhetetlenné vált, bár nem távolították el, hanem „minden eshetőségre” meghagyták.

A különbség a halott kód és a zombi kód között az eredetben rejlik. A halott kód tévesen íródhatott (soha nem működött), míg a zombi kód egykor élő kód, amely a refaktorálás során vesztette el relevanciáját. Például egy kedvezmény kiszámítására szolgáló függvény régi üzleti logika alapján, amelyet újra cseréltek, de a régi metódust nem távolították el — arra az esetre, ha vissza kellene állítani.

A zombi kód fő veszélye a működő funkcionalitás illúziója. Az új fejlesztő lát egy függvényt, elolvassa a dokumentációját, feltételezi, hogy valahol meghívják — és időt pazarol egy műtermék tanulmányozására. Amikor megpróbálja közvetlenül meghívni, kiderülhet, hogy az eltávolított entitásoktól vagy elavult API-któl függ.

Kövesse nyomon a zombi kódot a git-előzményeken keresztül: ha egy függvény két éve nem változott és nem használják — az zombi. Távolítsa el habozás nélkül, mert a git megőrzi az előzményeket, és szükség esetén a kód mindig visszaállítható.

A halott kód megjelenésének okai

Az első és leggyakoribb ok — iteratív fejlesztés hiányos refaktorálással. A csapat új funkcionalitást ad hozzá, amely felváltja a régit, de nem távolítja el a lecserélt modulokat. A sprintek felhalmozzák az ilyen „farok” részeket, és egy év múlva a projektet halott kód rétege borítja.

A második ok — A/B tesztelés és feature toggle. Az új funkció bekapcsolásának feltételei idővel rögzülhetnek (például mindig true), de az else ág alternatív logikával a kódban marad. A fejlesztők félnek eltávolítani, nehogy véletlenül összetörjék a rendszert, ha a toggle-t visszakapcsolják.

A harmadik ok — automatikus generálás és copy-paste. A kódgenerátorok (IDE, sablonmotorok) olyan metódusokkal ellátott sablonokat hoznak létre, amelyeket a fejlesztő nem tölt ki vagy nem használ. A másik projektből másolt kód gyakran tartalmaz olyan teljes blokkokat, amelyek nem relevánsak az új kontextusban.

A negyedik ok — az eltávolítástól való félelem. Nagy projektekben a fejlesztők félnek eltávolítani a kódot, mert nem biztosak benne, hogy tényleg sehol sem használják. Ezt a félelmet erősíti a gyenge tesztrendszer: ha nincs automatizált ellenőrzés, az eltávolítás olyan hibákhoz vezethet, amelyek csak élesben derülnek ki.

Miért veszélyes a halott kód

Halott kód közvetlenül befolyásolja a projekt minőségének négy aspektusát: a fordítás teljesítményét, a műtermék méretét, a csapat kognitív terhelését és a refaktorálás megbízhatóságát.

A fordítási idő növekedése: a fordító feldolgozza a nem használt fájlokat, elemzi a függőségeket és bájtkódot vagy gépi kódot generál azokhoz a részletekhez, amelyek soha nem futnak le. Nagy projektekben ez percekkel növeli minden egyes fordítást. Értelmezett nyelveknél (JavaScript, Python) nő a modul betöltési ideje és a memóriahasználat.

A hibák kockázata módosításkor: a fejlesztő a kód módosításakor nem sejti, hogy a függvényt csak egy halott ágban használják. A refaktorálás után a halott kód nem fordítható vagy hibákat produkál — a csapat időt pazarol egy olyan probléma diagnosztizálására, amely nem befolyásolja az alkalmazás működését.

Kognitív terhelés — a legdrágább tényező. Minden nem használt függvény figyelmet igényel a kód olvasásakor. A fejlesztő szellemi energiát fordít annak megértésére, hogy ez a kód miért létezik és hol hívják meg. A Developer Productivity Lab (2025) kutatása kimutatta: a halott kód 20 százalékának eltávolítása átlagosan 18 százalékkal csökkenti a belépési időt (onboarding time).

Távolítsa el a halott kódot azonnal észlelés után. Minden késlekedési nap növeli annak valószínűségét, hogy valaki a csapatból órákat tölt egy olyan műtermék tanulmányozásával, amelyet már tegnap el kellett volna távolítani.

Halott kód kereséséhez használt eszközök

A halott kód keresése két fő módszerrel történik: statikus elemzés (a program futtatása nélkül) és dinamikus elemzés (lefedettség profilozása futás közben). Minden megközelítés különböző típusú halott kódok esetén hatékony.

A statikus elemzők támogatják az összes népszerű programozási nyelvet. Java és Kotlin esetén — SonarQube, IntelliJ IDEA Inspections, SpotBugs. JavaScript és TypeScript esetén — ESLint a no-unused-vars és no-unused-modules szabályokkal. Swift esetén — SwiftLint az unused_declaration szabállyal. Python esetén — pylint az unused-import opcióval és a vulture a mélyreható kereséshez.

Példa keresésre Kotlinban ProGuard segítségével

// build.gradle.kts — ProGuard konfiguráció Androidhoz
android {
    buildTypes {
        release {
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

// proguard-rules.pro — csak a szükséges osztályokat tartsa meg
-keep class com.example.app.** { *; }
-assumenosideeffects class Timber {
    static <methods>;
}

A ProGuard nemcsak eltávolítja a nem használt osztályokat és metódusokat, hanem kicsinyíti a neveket a release fordításban. A ProGuard-ot tartalmazó fordítás automatikusan megmutatja, mely osztályok és metódusok számítanak nem használtnak — a usage.txt jelentésben az összes eltávolított kód fel van sorolva.

Dinamikus elemzés tesztlefedettséggel

A kódlefedettségi eszközök (JaCoCo Java-hoz, XCTest coverage Swift-hez, Istanbul JavaScript-hez) megmutatják, mely sorok és ágak hajtódnak végre a tesztek során. A nulla lefedettséggel rendelkező metódusok halott kód jelöltek. A lefedettség hiánya azonban nem garantálja, hogy a kódot nem hívják meg élesben — a teljes bizonyossághoz használja a statikus és dinamikus elemzés kombinációját.

Állítsa be a CI pipeline-t úgy, hogy a fordítás meghiúsuljon a nem használt deklarációk küszöbértékének túllépése esetén. A SonarQube Quality Gate a „Nem használt privát kód aránya legfeljebb 3%” szabállyal megakadályozza a halott kód felhalmozódását a fejlesztési folyamat szintjén.

Hogyan távolítsuk el biztonságosan a halott kódot

A halott kód eltávolításának folyamata négy lépésből áll: keresd meg, ellenőrizd, távolítsd el, ellenőrizd újra. Bármelyik lépés kihagyása növeli a regresszió kockázatát.

Első lépés — jelöltek keresése statikus elemzővel. Szerezzen jelentést a nem használt deklarációkról: függvények, osztályok, változók, importok. Szűrje ki a téves pozitívokat — az elemzők néha tévednek refl exió, dinamikus osztálybetöltés vagy szerializáción keresztüli rejtett hívások esetén.

Második lépés — ellenőrzés git blame és változtatástörténet segítségével. Nézze meg, mikor és miért írták a kódot. Ha a kód egy feature toggle által kikapcsolt funkció része volt, győződjön meg róla, hogy a toggle rögzítve van és nem kapcsolják vissza. Kommentelje ki azt a kódot, amelynek eltávolításában kételkedik, és hagyjon TODO-t egy feladattal az egy hónap múlva esedékes újraellenőrzéshez.

Harmadik lépés — eltávolítás külön ágban a teljes tesztkészlet futtatásával. Ha a tesztek átmennek — a regresszió valószínűsége alacsony. Ha a tesztek meghiúsulnak — ez azt jelenti, hogy a kódot még mindig használják, és meg kell állapítani, milyen forgatókönyvben.

// előtte — halott kód és zombi kód ugyanabban a fájlban
int calculateV1(int price) { // sehol sem hívják meg
    int tax = price * 0.18;
    return price + tax;
}

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

// utána — halott kód eltávolítva, zombi kód kitakarítva
int calculatePrice(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

Negyedik lépés — a változtatások code review-ja. A revizornak meg kell erősítenie, hogy a kód tényleg halott. Ha a revizor nem biztos — hagyjon megjegyzést a kódban és halassza el az eltávolítást a teljes elemzésig. Az ág egyesítése után távolítsa el az ágat, hogy ne szaporítsa a zombi kódot a git tárban.

Vezessen be egy szabályt: egyetlen pull request sem tartalmazhat új halott kódot. Adjon hozzá egy lintert a pre-commit hook-okhoz, amely blokkolja a commit-ot nem használt változók vagy importok esetén. A megelőzés mindig olcsóbb, mint a tisztítás.