Müllcode und Chaos in mobilen Projekten — Anzeichen und Refactoring

Was ist Müllcode in der Entwicklung

Müllcode (auch Spaghetti-Code, Chaos, Big Ball of Mud) ist eine Metapher für eine Codebasis, die ihre Struktur verloren hat und zu einem verworrenen Netz von Abhängigkeiten geworden ist. In einem solchen Code zerbricht jede Änderung an einer Stelle eine andere, und das Hinzufügen neuer Funktionalitäten wird zu einem riskanten Unterfangen.

In der Mobilentwicklung ist Müllcode besonders kritisch: Eine App, die auf einem „Chaos“ aufgebaut ist, wird langsam, stürzt auf älteren Geräten ab und hat Schwierigkeiten, Code-Reviews zu bestehen. Ein iOS-Projekt ohne Architektur kann aufgrund von Instabilität die App-Review nicht bestehen.

Laut Stripe verbringen Entwickler bis zu 42% ihrer Arbeitszeit mit dem Lesen und Verstehen vorhandenen Codes. In Projekten mit Müllcode übersteigt dieser Wert 60%, was die Entwicklung extrem ineffizient macht.

Ursprung der Begriffe

Spaghetti-Code ist der älteste Begriff und stammt aus den 1970er Jahren. Er beschreibt Code mit chaotischen Kontrollflüssen, der an verworrene Spaghetti erinnert.

Big Ball of Mud ist ein Begriff, der 1997 von Brian Foote und Joseph Yoder eingeführt wurde, um Systeme ohne klare Architektur zu beschreiben, die chaotisch wachsen.

Warum Müllcode gefährlich fürs Geschäft ist

Müllcode verlangsamt die Markteinführung neuer Funktionen. Das Team verbringt Zeit nicht mit der Wertschöpfung, sondern mit dem Versuch, den vorhandenen Code zu verstehen und nichts zu beschädigen.

Laut McKinsey geben Unternehmen mit niedriger Codequalität 20–40% mehr für die Produktwartung aus, und die Geschwindigkeit der Auslieferung neuer Funktionen ist 2- bis 3-mal niedriger als bei Unternehmen mit hoher Codequalität.

Anzeichen von Müllcode und wie man ihn erkennt

Müllcode kann anhand einer Reihe objektiver Indikatoren erkannt werden, von denen einige automatisch gemessen werden. Je mehr Indikatoren zutreffen, desto schwerwiegender ist das Problem.

In der Branche werden Codequalitätsmetriken wie die Halstead-Komplexität, der Maintainability Index und die Technical Debt Ratio verwendet. Die Kenntnis dieser Metriken hilft, den Zustand einer Codebasis objektiv zu bewerten.

Copy-Paste (Code-Duplizierung)

Das häufigste Anzeichen von Müllcode sind wiederholte Codeblöcke. Anstatt eine gemeinsame Funktion zu extrahieren, kopieren Entwickler Code von einer Stelle zur anderen mit minimalen Änderungen.

Ein Duplizierungsgrad von bis zu 5% gilt als normal. Wenn die Duplizierung 15% übersteigt, ist das ein ernstes Warnsignal. Werkzeuge wie Simian und der PMD Copy Paste Detector helfen, Copy-Paste automatisch zu erkennen.

Lange Methoden und Klassen

Eine Methode mit mehr als 100 Zeilen ist ein klares Anzeichen für Müllcode. Eine solche Methode tut in der Regel zu viel und verletzt das Prinzip der einzigen Verantwortung (Single Responsibility).

Klassen mit mehr als 1000 Zeilen Code sind ebenfalls problematisch. Sie enthalten nicht zusammenhängende Funktionalitäten, was das Testen, Verstehen und Ändern des Codes erschwert.

Hohe zyklomatische Komplexität

Die zyklomatische Komplexität nach McCabe ist eine Metrik, die die Anzahl der unabhängigen Pfade im Code angibt. Ein Wert über 15 gilt als problematisch.

Methoden mit einer Komplexität über 30 befinden sich in der „Katastrophenzone.“ Sie enthalten zu viele Verzweigungen und sind ohne tiefgehende Analyse nicht zu testen oder zu verstehen.

Ursachen von Müllcode

Müllcode entsteht nicht „von selbst“ — er ist immer das Ergebnis bestimmter Prozesse und Entscheidungen im Team. Das Verständnis der Ursachen hilft, ihn in Zukunft zu vermeiden.

Laut JetBrains Developer Ecosystem 2024 geben 67% der Entwickler zu, dass sie aufgrund von Zeitmangel schlechteren Code schreiben, als sie könnten. Dies ist der Hauptgrund für die Anhäufung technischer Schulden.

Hektik und Termine

Die häufigste Ursache sind knappe Termine. Das Team schreibt Code „wie er gerade kommt“, nur um die Frist einzuhalten. Refactoring, Tests und Code-Reviews werden „auf später“ verschoben.

Das Problem ist, dass „später“ nie kommt — im nächsten Sprint tauchen neue Fristen auf, und die technischen Schulden türmen sich wie ein Schneeball auf.

Fehlende Code-Reviews

Ohne Code-Reviews schreibt jeder Entwickler in seinem eigenen Stil, verwendet seine eigenen Muster und hinterlässt seine eigenen „Markierungen.“ Mit der Zeit verliert die Codebasis ihre Einheitlichkeit.

Teams, die obligatorische Code-Reviews für jeden Pull-Request praktizieren, haben laut einer SmartBear-Studie von 2024 60% weniger Fehler in der Produktion.

Schwache Architektur von Anfang an

Wenn ein Projekt ohne klare Architektur startet, ist Müllcode unvermeidlich. Die ersten „Schnelllösungen“ legen ein Fundament, auf dem später nur schwer etwas Qualitativ hochwertiges aufgebaut werden kann.

In der Mobilentwicklung sollte die Wahl der Architektur (MVC, MVP, MVVM, Clean Architecture) eine bewusste Entscheidung sein, die vor dem Schreiben des Codes getroffen wird, nicht das Ergebnis einer Evolution.

Methoden zur Bekämpfung von Müllcode

Die Bekämpfung von Müllcode erfordert einen systematischen Ansatz und Disziplin des gesamten Teams. Es gibt kein einzelnes Werkzeug oder eine einzelne Praxis, die das Problem lösen wird — es braucht eine Reihe von Maßnahmen.

Das wichtigste Prinzip ist, Müllcode bereits in der Schreibphase zu verhindern, nicht ihn später zu beheben. Vorbeugung ist immer günstiger als das Refactoring eines bestehenden „Chaos.“

Codierungsstandards

Ein einheitlicher Codestil ist die Grundlage zur Vermeidung von Müllcode. Codierungsstandards (Code Style) sollten dokumentiert und automatisch von Lintern überprüft werden.

Für iOS wird SwiftLint verwendet, für Android Ktlint und Detekt. Die Konfiguration von Regeln in einer Konfigurationsdatei ermöglicht es, Pull-Requests, die gegen die Standards verstoßen, automatisch abzulehnen.

Regelmäßiges Refactoring

Refactoring ist keine Fehlerbehebung, sondern die Verbesserung der Codestruktur ohne Änderung des Verhaltens. Es sollte ein regelmäßiger Teil des Entwicklungsprozesses sein, kein separates Projekt.

Es wird empfohlen, 20% der Zeit jedes Sprints für Refactoring und den Abbau technischer Schulden einzuplanen. Dies verhindert die Ansammlung von „Chaos“ und erhält die Geschwindigkeit des Teams langfristig.

Obligatorische Code-Reviews

Jeder Pull-Request sollte von mindestens einem Entwickler überprüft werden. Code-Reviews erkennen nicht nur Fehler, sondern auch Architekturverstöße, Stilprobleme und potenzielle Quellen von Müllcode.

Eine gute Praxis ist eine Checkliste fürs Code-Review, die die Überprüfung auf Copy-Paste, Methodenlänge, zyklomatische Komplexität und Testabdeckung umfasst. Ohne Checkliste übersehen Prüfer bis zu 50% der Probleme.

Werkzeuge zur Bereinigung der Codebasis

Moderne Code-Analysewerkzeuge ermöglichen die automatische Erkennung von Müllcode, die Messung technischer Schulden und die Überwachung der Qualität. Die Integration dieser Werkzeuge in die CI/CD-Pipeline ermöglicht eine kontinuierliche Überwachung.

Es wird empfohlen, mindestens einen statischen Analysator und ein Metrikmesswerkzeug zu verwenden. Zusätzlich kann eine Plattform zur Aggregation von Codequalitätsdaten angebunden werden.

Statische Analysatoren

• SonarQube — die führende Plattform zur Codequalitätsanalyse, unterstützt 30+ Sprachen und liefert Metriken zur Technical Debt Ratio
• ESLint — der Standard für JavaScript und TypeScript, über Konfigurationsdateien einstellbar und in IDEs integriert
• SwiftLint — ein unverzichtbares Werkzeug für iOS-Projekte, prüft die Einhaltung des Swift-Style-Guides

Laut SonarSource reduzieren Teams, die statische Analysen verwenden, die Anzahl der Produktionsfehler bereits im ersten Quartal nach der Einführung um 30%.

Metrik-Messwerkzeuge

CodeClimate und Codacy sind Plattformen, die Codequalitätsmetriken aggregieren, Trends verfolgen und „Hot Spots“ anzeigen — Dateien mit den höchsten technischen Schulden.

Für Android-Projekte bietet Detekt über 100 integrierte Analyseregeln, darunter Prüfungen auf zyklomatische Komplexität, Methodenlänge und Codeduplizierung.