Junk i utveckling — vad är det, varför junk-kod är skadligt och hur man tar bort det

Vad är junk?

Junk (junk code) — en samlingsterm för kod, konfigurationer och beroenden som finns i projektet men saknar funktionellt värde. Junk är nödvändigtvis inte trasigt eller oanvänt — problemet är att dess närvaro försämrar projektets mätvärden utan adekvat motivering.

Junk delas in i fyra kategorier. Första — överflödiga beroenden: bibliotek kopplade för en funktion som kan implementeras med standardverktyg. Andra — död vikt: kommenterade block, TODO utan biljetter, tomma metoder och stubbklasser. Tredje — duplicerade lösningar: två bibliotek som gör samma sak (till exempel Gson och Kotlin Serialization i samma projekt). Fjärde — over-engineering: arkitekturlager som inte används men underhålls för framtiden.

Enligt forskning från Stripe Engineering Productivity (2025) minskar borttagning av 10 procent junk från ett typiskt projekt den fullständiga byggtiden med i genomsnitt 22 procent. Orsak: varje extra beroende ökar bygggrafen, varje tom abstraktion kräver tid att förstå, varje kommenterat block distraherar.

Den största svårigheten i kampen mot junk är avsaknaden av omedelbara konsekvenser. Ett projekt med junk-kod kompilerar och fungerar. Problem ackumuleras gradvis: bygget saktar ner, antalet transitiva beroenden växer och efter ett år tar det dubbelt så lång tid att lägga till en ny funktion som det borde.

Junk-beroenden och hur man identifierar dem

Junk-beroenden — är bibliotek och paket som är kopplade till projektet men inte används direkt i koden, eller endast används i en funktion som enklare kan implementeras med standard API:er.

Typiska exempel: ett bibliotek för JSON-arbete när projektet redan använder Kotlin Serialization (två parsrar — det är junk); biblioteket Apache Commons Lang för en enda metod StringUtils.isEmpty, som ersätts av Kotlin-tillägget isNullOrBlank; ett DI-bibliotek som används i en av tio moduler medan resten får beroenden manuellt via konstruktorn.

Varje extra beroende är inte bara extra kod i binären. Det är också en ökning av attackytan för sårbarheter: enligt GitHub Advisory Database (2025) kommer 40 procent av kritiska CVE:er i mobilprojekt från transitiva beroenden som utvecklare inte kontrollerar. Ju färre beroenden — desto mindre attackyta.

Analys av beroenden i ett Android-projekt

// Visa Gradle-beroendeträd
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Hitta oanvända beroenden (Gradle-plugin)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Generera rapport om oanvända bibliotek
./gradlew buildHealth

För iOS använd kommandot swift package show-dependencies, som visar det fullständiga beroendeträdet. Verktyget Xcode Build Timeline visar hur mycket tid varje bibliotek lägger till bygget. Om ett bibliotek tar 30 procent av kompileringstiden men används på en enda skärm — är det en kandidat för borttagning eller ersättning.

För Node.js (React Native) använd depcheck — ett verktyg som hittar oanvända beroenden i package.json, och npm-check, som dessutom visar föråldrade versioner. Inför regeln: varje nytt beroende måste gå igenom code review med motivering om varför det inte kan göras med standardverktyg.

Döda importer och kommenterad kod

Döda importer — den vanligaste typen av junk. De påverkar inte körningen men ökar kompileringstiden: kompilatorn bearbetar varje import, även om den inte används. I stora projekt minskar borttagning av oanvända importer byggtiden med 5–10 procent.

Moderna IDE:er markerar automatiskt oanvända importer i grått. Konfigurera automatisk rensning vid filsparning: i IntelliJ IDEA — Optimize Imports on the fly, i Xcode — Editor > Remove Unused Imports. Lägg till en kontroll i CI: linter bör blockera commits med oanvända importer.

Kommenterad kod — en annan typ av junk. Utvecklare kommenterar block för att inte förlora funktionalitet vid omfaktorisering. Men git lagrar hela ändringshistoriken: all borttagen kod kan återställas med ett enda kommando git revert eller git log -S . Kommenterad kod i master är respektlöst mot teamet: varje utvecklare lägger mental energi på frågan varför detta är kommenterat och när det ska avkommenteras.

Regel: i repository finns ingen kommenterad kod. Om kod inte behövs — ta bort den permanent. Om kod behövs men är tillfälligt avaktiverad — använd en feature toggle med biljett och deadline. Kommentarer som // TODO: remove after migration — lämna dem inte utan deadline. Sätt ett datum och ställ in en påminnelse i kalendern.

Överflödiga abstraktioner och over-engineering

Over-engineering — att skapa arkitekturlager som inte löser nuvarande problem men kräver underhåll. Detta är en av de svåraste typerna av junk eftersom koden formellt är korrekt: den följer SOLID, är testtäckt och överensstämmer med arkitekturen. Problemet är att den inte behövs.

Det klassiska exemplet — en abstrakt UseCase-klass med en enda invoke-metod som bara anropar repository. Om UseCase inte lägger till logik (cachning, retry, transformation), utan bara vidarebefordrar anropet — är det en överflödig entitet. Den ökar navigeringen genom projektet: utvecklaren öppnar UseCase, ser invoke → repository — och stänger. Tid förlorad, nytta noll.

Ett annat exempel — överdriven parameterisering. Ett generiskt gränssnitt med sex typparametrar, använt på ett ställe. Varje typparameter är kognitiv belastning: vid läsning av koden måste man hålla sex typer i huvudet, medan bara två faktiskt används. Om abstraktionen inte återanvänds — är den överflödig.

Avgränsningskriteriet: om en abstraktion inte återanvänds i tre olika sammanhang — ta bort den. En abstraktion är motiverad när den faktiskt löser ett dupliceringsproblem, inte när den förutsäger hypotetiska framtidsscenarier. YAGNI (You Ain't Gonna Need It) — den bästa principen för att förebygga over-engineering.

Verktyg för junk-granskning

Granskning av junk kräver en kombination av statisk analys, beroendeanalys och manuell kontroll. Det går inte att helt automatisera sökningen efter överflödiga abstraktioner, men teknisk junk (döda importer, oanvända bibliotek, kommenterad kod) hittas med verktyg.

För en fullständig granskning, kör buildHealth (Android) eller depcheck (Node.js) en gång per sprint. Skapa en dashboard i CI som visar dynamiken i antalet beroenden över sprintar. Om antalet ökar men funktionaliteten inte ökar proportionellt — samlar teamet på sig junk.

Var uppmärksam på duplicate classes — ett fel när två bibliotek innehåller samma klass. Detta är inte bara junk, utan också en direkt källa till byggkonflikter. I Gradle löses sådana konflikter via force eller exclude, men varje sådan lösning är en signal om att ett av biblioteken är överflödigt.

Process för regelbunden projektrensning

Rensning av junk är inte en engångsåtgärd utan en regelbunden process. Utan regler återkommer junk inom två till tre sprintar. Bästa praxis — avsätt 10–15 procent av varje sprints kapacitet till teknisk rensning, inklusive junk-granskning.

Processen består av fyra steg. Första — diagnostik: kör verktyg, få rapport, prioritera. Hög prioritet — beroenden med kända CVE:er och duplicerade bibliotek. Medel — döda importer och kommenterad kod. Låg — överflödiga abstraktioner (kräver manuell analys).

Andra — rensning: ta bort döda beroenden, ersätt duplicerade bibliotek med ett, ta bort kommenterad kod. Varje ändring görs i en separat commit med ett tydligt meddelande: remove unused dependency: gson (replaced by kotlinx.serialization), delete commented code in LoginViewModel.

Tredje — verifiering: bygg projektet, kör tester, kontrollera UI. Om tester går igenom efter borttagning av ett beroende — var beroendet verkligen inte nödvändigt. Om tester misslyckas — betyder det att en dold referens finns kvar som den statiska analysatorn inte upptäckte.

Fjärde — förebyggande: uppdatera code review-checklistan, lägg till regeln inget nytt beroende utan motivering i Definition of Done, konfigurera automatisk kontroll i CI. Förebyggande är det enda sättet att förhindra återackumulering av junk.