Junk in der Entwicklung — was es ist, warum Junk-Code schadet und wie man ihn entfernt

Was ist Junk-Code?

Junk (Junk-Code) ist ein Sammelbegriff für Code, Konfigurationen und Abhängigkeiten, die in einem Projekt vorhanden sind, aber keinen funktionalen Wert bieten. Junk ist nicht unbedingt kaputt oder ungenutzt — das Problem ist, dass seine Anwesenheit die Projektmetriken ohne angemessene Rechtfertigung verschlechtert.

Junk wird in vier Kategorien unterteilt. Erste — redundante Abhängigkeiten: Bibliotheken, die für eine einzelne Funktion hinzugefügt wurden, die mit Standardwerkzeugen hätte implementiert werden können. Zweite — totes Gewicht: auskommentierte Blöcke, TODO ohne Tickets, leere Methoden und Stub-Klassen. Dritte — doppelte Lösungen: zwei Bibliotheken, die dasselbe tun (z. B. Gson und Kotlin Serialization in einem Projekt). Vierte — Über-Engineering: Architekturschichten, die nicht genutzt werden, aber „für alle Fälle“ gewartet werden.

Laut einer Studie von Stripe Engineering Productivity (2025) reduziert die Entfernung von 10 Prozent Junk aus einem typischen Projekt die vollständige Build-Zeit um durchschnittlich 22 Prozent. Der Grund: Jede zusätzliche Abhängigkeit erhöht den Build-Graphen, jede leere Abstraktion benötigt Zeit zum Verstehen, jeder auskommentierte Block lenkt ab.

Die Hauptschwierigkeit im Kampf gegen Junk ist das Fehlen unmittelbarer Konsequenzen. Ein Projekt mit Junk-Code kompiliert und funktioniert. Probleme sammeln sich allmählich an: Der Build wird langsamer, die Anzahl transitiver Abhängigkeiten wächst, und nach einem Jahr dauert das Hinzufügen einer neuen Funktion doppelt so lange wie nötig.

Junk-Abhängigkeiten und wie man sie identifiziert

Junk-Abhängigkeiten sind Bibliotheken und Pakete, die einem Projekt hinzugefügt wurden, aber nicht direkt im Code verwendet werden, oder nur für eine einzige Funktion verwendet werden, die mit Standard-APIs einfacher zu implementieren wäre.

Typische Beispiele: eine Bibliothek zur JSON-Verarbeitung, wenn das Projekt bereits Kotlin Serialization verwendet (zwei Parser sind Junk); die Apache Commons Lang-Bibliothek für einen einzelnen StringUtils.isEmpty-Aufruf, der durch die Kotlin-Erweiterung isNullOrBlank ersetzt werden könnte; eine DI-Bibliothek, die in einem von zehn Modulen verwendet wird, während die anderen Abhängigkeiten manuell über den Konstruktor erhalten.

Jede zusätzliche Abhängigkeit ist nicht nur zusätzlicher Code im Binärprogramm. Sie vergrößert die Angriffsfläche für Schwachstellen: Laut GitHub Advisory Database (2025) stammen 40 Prozent der kritischen CVEs in mobilen Projekten von transitiven Abhängigkeiten, die Entwickler nicht kontrollieren. Je weniger Abhängigkeiten, desto kleiner die Angriffsfläche.

Analyse von Android-Projektabhängigkeiten

// View Gradle dependency tree
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Find unused dependencies (Gradle plugin)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Generate unused library report
./gradlew buildHealth

Verwenden Sie für iOS den Befehl swift package show-dependencies, der den vollständigen Abhängigkeitsbaum anzeigt. Das Tool Xcode Build Timeline zeigt, wie viel Build-Zeit jede Bibliothek hinzufügt. Wenn eine Bibliothek 30 Prozent der Kompilierungszeit beansprucht, aber auf einem einzigen Bildschirm verwendet wird, ist sie ein Kandidat für die Entfernung oder Ersetzung.

Verwenden Sie für Node.js (React Native) depcheck — ein Dienstprogramm, das ungenutzte Abhängigkeiten in package.json findet, und npm-check, das zusätzlich veraltete Versionen anzeigt. Führen Sie eine Regel ein: Jede neue Abhängigkeit muss ein Code-Review mit einer Begründung durchlaufen, „warum Standardwerkzeuge nicht verwendet werden können.“

Tote Importe und auskommentierter Code

Tote Importe sind die häufigste Art von Junk. Sie beeinträchtigen die Laufzeit nicht, erhöhen aber die Kompilierungszeit: Der Compiler verarbeitet jeden Import, auch ungenutzte. In großen Projekten reduziert die Entfernung ungenutzter Importe die Build-Zeit um 5–10 Prozent.

Moderne IDEs heben ungenutzte Importe automatisch grau hervor. Richten Sie die automatische Bereinigung beim Speichern ein: in IntelliJ IDEA — Optimize Imports on the fly, in Xcode — Editor > Remove Unused Imports. Fügen Sie eine CI-Prüfung hinzu: Der Linter soll Commits mit ungenutzten Importen blockieren.

Auskommentierter Code ist eine weitere Art von Junk. Entwickler kommentieren Blücke aus, um Funktionalität während der Refaktorisierung „nicht zu verlieren.“ Git speichert jedoch die vollständige Historie der Änderungen: Jeder entfernte Code kann mit einem einzigen git revert- oder git log -S -Befehl wiederhergestellt werden. Auskommentierter Code im Master ist respektlos gegenüber dem Team: Jeder Entwickler verschwendet geistige Energie mit der Frage „warum ist dies auskommentiert und wann sollte es einkommentiert werden?“

Die Regel: Es gibt keinen auskommentierten Code im Repository. Wenn Code nicht benötigt wird, löschen Sie ihn dauerhaft. Wenn Code benötigt wird, aber vorübergehend deaktiviert ist, verwenden Sie einen Feature-Toggle mit einem Ticket und einem Ablaufdatum. Kommentare wie // TODO: remove after migration — hinterlassen Sie sie nicht ohne Frist. Setzen Sie ein Datum und erinnern Sie sich mit einem Kalender.

Redundante Abstraktionen und Über-Engineering

Über-Engineering ist die Erstellung von Architekturschichten, die aktuelle Probleme nicht lösen, aber Wartung erfordern. Dies ist eine der schwierigsten Arten von Junk, weil der Code formal „richtig“ ist: Er folgt SOLID, ist durch Tests abgedeckt und entspricht der Architektur. Das Problem ist, dass er unnötig ist.

Ein klassisches Beispiel ist eine abstrakte UseCase-Klasse mit einer einzigen invoke-Methode, die einfach ein Repository aufruft. Wenn der UseCase keine Logik hinzufügt (Caching, Wiederholung, Transformation), sondern den Aufruf nur durchreicht, ist er eine überflüssige Entität. Er erhöht die Navigation im Projekt: Ein Entwickler öffnet den UseCase, sieht invoke → Repository und schließt ihn. Zeit verschwendet, Nutzen null.

Ein weiteres Beispiel ist übermäßige Parametrisierung. Eine generische Schnittstelle mit sechs Typparametern, die an einer einzigen Stelle verwendet wird. Jeder Typparameter bedeutet kognitive Belastung: Beim Lesen des Codes muss man sechs Typen im Kopf behalten, obwohl nur zwei tatsächlich verwendet werden. Wenn eine Abstraktion nicht wiederverwendet wird, ist sie redundant.

Das Ausschlusskriterium: Wenn eine Abstraktion nicht in drei verschiedenen Kontexten wiederverwendet wird, entfernen Sie sie. Eine Abstraktion ist gerechtfertigt, wenn sie tatsächlich ein Duplikationsproblem löst, nicht wenn sie hypothetische Zukunftsszenarien vorhersagt. YAGNI (You Ain’t Gonna Need It) ist das beste Prinzip zur Vermeidung von Über-Engineering.

Junk-Audit-Tools

Das Junk-Audit erfordert eine Kombination aus statischer Analyse, Abhängigkeitsanalyse und manueller Überprüfung. Es ist unmöglich, die Erkennung redundanter Abstraktionen vollständig zu automatisieren, aber technischer Junk (tote Importe, ungenutzte Bibliotheken, auskommentierter Code) kann mit Tools gefunden werden.

Für ein vollständiges Audit führen Sie buildHealth (Android) oder depcheck (Node.js) einmal pro Sprint aus. Erstellen Sie ein CI-Dashboard, das den Trend der Abhängigkeitsanzahl über die Sprints hinweg anzeigt. Wenn die Anzahl steigt, aber die Funktionalität nicht proportional wächst, häuft das Team Junk an.

Achten Sie auf doppelte Klassen — einen Fehler, der auftritt, wenn zwei Bibliotheken dieselbe Klasse enthalten. Dies ist nicht nur Junk, sondern auch eine direkte Quelle für Build-Konflikte. In Gradle werden solche Konflikte über force oder exclude gelöst, aber jede solche Lösung ist ein Signal, dass eine der Bibliotheken überflüssig ist.

Regelmäßiger Projektbereinigungsprozess

Die Junk-Bereinigung ist keine einmalige Aktion, sondern ein regelmäßiger Prozess. Ohne Verfahren kehrt Junk innerhalb von zwei bis drei Sprints zurück. Die beste Praxis ist, 10–15 Prozent der Kapazität jedes Sprints für die technische Bereinigung einschließlich Junk-Audit aufzuwenden.

Der Prozess besteht aus vier Schritten. Erster — Diagnose: Tools ausführen, Bericht erhalten, priorisieren. Hohe Priorität: Abhängigkeiten mit bekannten CVEs und doppelte Bibliotheken. Mittlere Priorität: tote Importe und auskommentierter Code. Niedrige Priorität: redundante Abstraktionen (erfordern manuelle Analyse).

Zweiter — Bereinigung: tote Abhängigkeiten entfernen, doppelte Bibliotheken durch eine ersetzen, auskommentierten Code löschen. Jede Änderung sollte ein separater Commit mit einer klaren Nachricht sein: “remove unused dependency: gson (replaced by kotlinx.serialization)“, “delete commented code in LoginViewModel.“

Dritter — Verifikation: Projekt bauen, Tests ausführen, UI prüfen. Wenn Tests nach dem Entfernen einer Abhängigkeit bestehen, war die Abhängigkeit tatsächlich unnötig. Wenn Tests fehlschlagen, gibt es irgendwo einen versteckten Verweis, den der statische Analysator nicht erkannt hat.

Vierter — Prävention: die Code-Review-Checkliste aktualisieren, eine Regel „keine neue Abhängigkeit ohne Begründung“ zur Definition of Done hinzufügen, automatische Prüfungen in CI einrichten. Prävention ist der einzige Weg, um eine erneute Anhäufung von Junk zu verhindern.