Död kod och zombiekod i utveckling: vad det är, orsaker och sökning

Vad är död kod?

Död kod (dead code) — källkod som ingår i programmet men aldrig körs i något användningsscenario. Kompilatorn eller interpretatorn bearbetar den, men under körning når kontrollen aldrig dessa delar.

Klassiska exempel på död kod: variabler som har tilldelats ett värde men aldrig läses; funktioner eller metoder som inte anropas någonstans; villkorsgrenar som aldrig blir sanna (if(false)); loopar vars kropp inte utförs en enda gång.

Enligt rapporten SonarQube State of Code Quality (2025) handlar cirka 15 procent av alla varningar i kommersiella Java-projekt om oanvända privata metoder och fält. I JavaScript-projekt kan andelen oanvänd kod nå 30 procent på grund av språkets dynamiska natur och mängden tredjepartsbibliotek.

Kontrollera projektet regelbundet förekomst av död kod — särskilt efter stora omfaktoriseringar och borttagningar av funktioner. Ett glömt import eller en oanvänd funktion idag kan imorgon förvandlas till zombiekod som vilseleder nya teammedlemmar.

Skillnader mellan död kod och zombiekod

Zombiekod (zombie code) — ett speciellt fall av död kod som utmärker sig genom historisk kontext. Zombiekod fungerade en gång i tiden, men efter förändringar i systemet blev den oåtkomlig, även om den inte togs bort utan lämnades kvar "för säkerhets skull".

Skillnaden mellan död kod och zombiekod ligger i ursprunget. Död kod kan ha skrivits av misstag (fungerade aldrig), medan zombiekod är tidigare levande kod som förlorade sin relevans under omfaktorisering. Till exempel en funktion för att beräkna rabatt baserat på gammal affärslogik som ersattes med ny, men den gamla metoden togs inte bort — ifall den skulle behövas återställas.

Den största faran med zombiekod är illusionen av fungerande funktionalitet. En ny utvecklare ser en funktion, läser dess dokumentation, antar att den anropas någonstans — och slösar tid på att studera en artefakt. När man försöker anropa den direkt kan det visa sig att den är beroende av borttagna entiteter eller föråldrade API:er.

Följ zombiekod genom git-historiken: om en funktion inte har ändrats på två år och inte används — är den zombie. Ta bort den utan tvekan, eftersom git sparar historiken och vid behov kan koden alltid återställas.

Orsaker till uppkomst av död kod

Den första och vanligaste orsaken — iterativ utveckling med ofullständig omfaktorisering. Teamet lägger till ny funktionalitet som ersätter den gamla, men tar inte bort de ersatta modulerna. Sprintar samlar sådana "svansar" och efter ett år täcks projektet av ett lager död kod.

Andra orsaken — A/B-testning och feature toggle. Villkoren för att aktivera en ny funktion kan med tiden fixeras (till exempel alltid true), men else-grenen med alternativ logik finns kvar i koden. Utvecklare är rädda att ta bort den för att inte av misstag bryta systemet om toggeln slås tillbaka.

Tredje orsaken — autogenerering och copy-paste. Kodgeneratorer (IDE, mallmotor) skapar mallar med metoder som utvecklaren inte fyller i eller använder. Kod som kopierats från ett annat projekt innehåller ofta hela block som inte är relevanta för det nya sammanhanget.

Fjärde orsaken — rädsla för borttagning. I stora projekt är utvecklare rädda att ta bort kod eftersom de inte är säkra på att den verkligen inte används någonstans. Denna rädsla förvärras av ett svagt testsystem: om det inte finns någon automatisk kontroll kan borttagning leda till buggar som upptäcks först i produktion.

Varför död kod är farligt

Död kod påverkar direkt fyra aspekter av projektkvalitet: kompilationsprestanda, artefaktstorlek, teamets kognitiva belastning och omfaktoriseringens tillförlitlighet.

Ökad kompileringstid: kompilatorn bearbetar oanvända filer, analyserar beroenden och genererar bytekod eller maskinkod för fragment som aldrig kommer att köras. I stora projekt tillför detta minuter till varje bygge. För tolkade språk (JavaScript, Python) ökar modulens laddningstid och minnesförbrukning.

Risk för buggar vid ändring: utvecklaren som ändrar kod anar inte att funktionen bara används i en död gren. Efter omfaktorisering slutar den döda koden att kompilera eller ger fel — teamet slösar tid på att diagnostisera ett problem som inte påverkar applikationens funktion.

Kognitiv belastning — den dyraste faktorn. Varje oanvänd funktion kräver uppmärksamhet vid läsning av kod. Utvecklaren lägger mental energi på att förstå varför denna kod finns och var den anropas. Forskning från Developer Productivity Lab (2025) visade: borttagning av 20 procent död kod minskar introduktionstiden (onboarding time) med i genomsnitt 18 procent.

Ta bort död kod omedelbart efter upptäckt. Varje dags fördröjning ökar sannolikheten att någon i teamet lägger timmar på att studera en artefakt som borde ha tagits bort igår.

Verktyg för att hitta död kod

Sökning efter död kod görs med två huvudmetoder: statisk analys (utan att köra programmet) och dynamisk analys (täckningsprofilering under körning). Varje metod är effektiv för olika typer av död kod.

Statiska analyzatorer stöder alla populära programmeringsspråk. För Java och Kotlin — SonarQube, IntelliJ IDEA Inspections, SpotBugs. För JavaScript och TypeScript — ESLint med reglerna no-unused-vars och no-unused-modules. För Swift — SwiftLint med regeln unused_declaration. För Python — pylint med alternativet unused-import och vulture för djupgående sökning.

Exempel på sökning i Kotlin via ProGuard

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

// proguard-rules.pro — behåll endast nödvändiga klasser
-keep class com.example.app.** { *; }
-assumenosideeffects class Timber {
    static <methods>;
}

ProGuard tar inte bara bort oanvända klasser och metoder, utan minskar även namn i release-bygget. Ett bygge med ProGuard aktiverat visar automatiskt vilka klasser och metoder som anses oanvända — i rapporten usage.txt listas all borttagen kod.

Dynamisk analys genom testtäckning

Kodtäckningsverktyg (JaCoCo för Java, XCTest coverage för Swift, Istanbul för JavaScript) visar vilka rader och grenar som utförs under testerna. Metoder med noll täckning är kandidater för död kod. Avsaknad av täckning garanterar dock inte att koden inte anropas i produktion — för full säkerhet, använd en kombination av statisk och dynamisk analys.

Konfigurera CI-pipelinen så att bygget misslyckas när gränsen för oanvända deklarationer överskrids. SonarQube Quality Gate med regeln "Andel oanvänd privat kod högst 3%" förhindrar ackumulering av död kod på utvecklingsprocessnivå.

Hur man säkert tar bort död kod

Processen för borttagning av död kod består av fyra steg: hitta, kontrollera, ta bort, kontrollera igen. Att hoppa över något steg ökar risken för regression.

Första steget — sök efter kandidater via en statisk analyzator. Få en rapport om oanvända deklarationer: funktioner, klasser, variabler, importer. Filtrera falska positiva — analyzatorer misstar sig ibland vid reflexion, dynamisk laddning av klasser eller dolda anrop genom serialisering.

Andra steget — kontrollera via git blame och ändringshistorik. Se när och varför koden skrevs. Om koden var en del av en funktion som inaktiverats via feature toggle, se till att toggeln är fixerad och inte kommer att aktiveras igen. Kommentera koden du tvekar att ta bort och lämna en TODO med en uppgift för omkontroll om en månad.

Tredje steget — ta bort i en separat gren med körning av hela testpaketet. Om testerna passerar — är sannolikheten för regression låg. Om testerna misslyckas — betyder det att koden fortfarande används och man måste fastställa i vilket scenario.

// före — död kod och zombiekod i samma fil
int calculateV1(int price) { // anropas inte någonstans
    int tax = price * 0.18;
    return price + tax;
}

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

// efter — död kod borttagen, zombiekod rensad
int calculatePrice(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

Fjärde steget — code review av ändringarna. Granskaren måste bekräfta att koden verkligen är död. Om granskaren inte är säker — lämna en kommentar i koden och skjut upp borttagningen till fullständig analys. Efter sammanslagning av grenen, ta bort grenen för att inte fööka zombiekod i git-förvarat.

Inför en regel: ingen pull request får innehålla ny död kod. Lägg till en linter i pre-commit hooks som blockerar commit vid oanvända variabler eller importer. Förebyggande är alltid billigare än rensning.