Technische Schulden in der mobilen Entwicklung — Wesen, Arten und Prinzipien der Verwaltung

Was sind technische Schulden

Technische Schulden sind eine Metapher, die erstmals 1992 auf der OOPSLA von Ward Cunningham vorgeschlagen wurde. Er verglich Programmieren mit Investieren: nachlässiger Code ist wie die Aufnahme eines Kredits. Die Zinsen werden in Form von zusätzlicher Zeit für Wartung, Fehlerbehebung und Anpassung an neue Anforderungen gezahlt. Es ist wichtig zu verstehen, dass Schulden nicht immer schlecht sind; strategische Schulden können gerechtfertigt sein.

Die finanzielle Analogie funktioniert fast wörtlich. Wenn ein Team einen Kredit aufnimmt (nicht idealen Code veröffentlicht, um eine Frist einzuhalten), muss es Zinsen zahlen. Zinsen sind die Verlangsamung der Entwicklung, Fehler bei Codeänderungen und die Komplexität der Einarbeitung neuer Entwickler. Wenn die Zinsen höher werden als die Kosten des Refactorings, ist es Zeit, die Schulden zu begleichen. Das Hauptproblem: im Gegensatz zu einem Bankkredit sind sich Entwickler nicht immer bewusst, dass sie Schulden aufgenommen haben.

Eine wichtige Klarstellung: technische Schulden ≠ schlechter Code. Schlechter Code ist eine Folge von Inkompetenz. Technische Schulden sind ein bewusster Kompromiss. Das Team versteht, dass es etwas Unvollkommenes tut, dokumentiert dies in der technischen Dokumentation und plant, zur Verbesserung zurückzukehren. Der Unterschied zwischen Schulden und schlechtem Code liegt im Bewusstsein der Entscheidung. Deshalb ist der erste Schritt zum Schuldenmanagement, ihre Existenz anzuerkennen.

Arten technischer Schulden

Die Klassifizierung technischer Schulden hilft, ihre Natur zu verstehen und die richtige Tilgungsstrategie zu wählen. Martin Fowler schlug ein Quadrantenmodell mit zwei Achsen vor: absichtlich/unabsichtlich und rücksichtslos/besonnen. Jede Kombination erfordert einen anderen Ansatz. Betrachten wir die wichtigsten Arten von Schulden, mit denen ein mobiles Entwicklungsteam konfrontiert ist.

Absichtliche und unabsichtliche Schulden

Absichtliche Schulden — das Team entscheidet bewusst, suboptimalen Code zu veröffentlichen, um eine Frist einzuhalten. Beispiel: Start eines MVP mit einem einzelnen monolithischen ViewModel, in dem Wissen, dass das ViewModel nach der Hypothesenvalidierung in mehrere pro Domäne aufgeteilt wird. Solche Schulden werden im Backlog festgehalten und haben ein geplantes Tilgungsdatum. Ohne Plan werden absichtliche Schulden chronisch.

Unabsichtliche Schulden — Code, dessen Qualität aufgrund von mangelndem Wissen, fehlendem Code-Review oder schlechten Prozessen niedriger als erwartet ist. Beispiel: Ein Entwickler kannte die Best Practices für die Arbeit mit Room DB nicht und schrieb Abfragen im UI-Thread, was zu ANR führte. Diese Art von Schulden ist die heimtückischste — das Team bemerkt sie erst, wenn es auf kritische Leistungsprobleme stößt.

Architektur- und Code-Schulden

Architekturschulden — falsche Wahl von Mustern oder Projektstruktur. Beispiel: Eine App ohne Abstraktionsschicht über dem Netzwerk, bei der Retrofit direkt aus dem ViewModel verwendet wird. Der Austausch von Retrofit durch Ktor würde das Ändern aller ViewModels erfordern. Die Behebung von Architekturschulden ist am teuersten, daher werden Entscheidungen auf Architekturebene mit größter Vorsicht getroffen.

Code-Schulden — lokale Suboptimalitäten innerhalb einer einzelnen Klasse oder Methode. Beispiel: eine lange Methode mit 200 Zeilen, in der UI, Geschäftslogik und Datenverarbeitung vermischt sind. Wird mit Extract Method in 15 Minuten behoben. Code-Schulden sind weniger kritisch, aber ihre Anhäufung im Projektmaßstab verlangsamt die Entwicklung genauso wie Architekturschulden.

Test- und Dokumentationsschulden

Test-Schulden — Fehlen von Unit-Tests, UI-Tests oder Integrationstests. Jeder manuelle Regressionstestlauf ist ein Zins auf diese Schulden. Wenn ein Projekt keine automatisierten Tests hat, erfordert jede Änderung Stunden manueller Tests. Laut Google Testing Blog veröffentlichen Projekte mit einer Testabdeckung von >70% Bugs in der Produktion 2-mal seltener.

Dokumentationsschulden — Fehlen oder Veralten von Architekturdokumentation, Kommentaren zu komplexen Codebereichen, Readme zur Einarbeitung. Ein neuer Entwickler braucht ohne Dokumentation Wochen, um sich einzuarbeiten. Lösung: Architecture Decision Records (ADR) pflegen und Dokumentation zum Teil der Definition of Done für jede Aufgabe machen.

Warum technische Schulden gefährlich sind

Der Zinseszinseffekt ist die Hauptgefahr technischer Schulden. Jede neue Schicht suboptimalen Codes erhöht die Systemkomplexität nicht linear, sondern exponentiell. Ein einfaches Beispiel: wenn Modul A von Modul B abhängt und beide Schulden enthalten, erfordert das Ändern von A das Verständnis der Schulden in B. Nach 10 Iterationen verbringt ein Entwickler 80% der Zeit mit dem Entwirren von Abhängigkeiten und nur 20% mit neuer Funktionalität.

Die Verlangsamung der Time-to-Market ist eine direkte Folge von Schulden. Das Team verbringt immer mehr Zeit mit Wartung und immer weniger mit neuen Funktionen. Eine Studie von Stripe (2023) zeigte, dass Entwickler durchschnittlich 17 Stunden pro Woche mit technischen Schulden verbringen, anstatt Geschäftswert zu schaffen. In der mobilen Entwicklung wird dies durch die Notwendigkeit verschärft, zwei Plattformen zu unterstützen — jede mit ihren eigenen Plattform-Updates.

Team-Burnout ist eine nicht offensichtliche, aber verheerende Folge. Die Arbeit an Code, bei dem jede Änderung drei andere Dinge kaputt macht, verursacht chronischen Stress. Entwickler hören auf, stolz auf das Produkt zu sein, die Motivation sinkt und die Fluktuation steigt. Laut der Stack Overflow Survey 2024 ist die Arbeit mit Legacy-Code nach niedrigem Gehalt der zweithäufigste Grund für Unzufriedenheit am Arbeitsplatz.

Wie man technische Schulden verwaltet

Fowlers Quadrant ist ein praktisches Werkzeug zur Priorisierung von Schulden. Zwei Achsen: absichtlich/unabsichtlich und rücksichtslos/besonnen. Rücksichtslose absichtliche Schulden: „Wir haben keine Zeit für Tests, veröffentlichen ohne sie.” Besonnene absichtliche: „Wir wissen, dass Tests nötig sind, aber jetzt ist es wichtiger, die Funktion zu veröffentlichen — wir erstellen eine Aufgabe für Tests im nächsten Sprint.” Ersteres erfordert sofortiges Eingreifen, Letzteres erfordert Überwachung.

Die Boy-Scout-Rule-Strategie — „Hinterlasse den Campingplatz sauberer, als du ihn vorgefunden hast.” Eine einfache Regel: Wenn du eine Methode änderst, investiere 10% mehr Zeit, um sie etwas besser zu machen — benenne eine Variable um, teile einen 50-zeiligen Block in zwei. Im Teammaßstab führt dieser Ansatz zu einer schrittweisen Reduzierung der Schulden, ohne separate Sprints für Refactoring zu verwenden. Die Verbesserung sollte mikroskopisch, aber regelmäßig sein.

Zeit einplanen für das Schuldenmanagement ist ein Zeichen der Teamreife. Es wird empfohlen, 15–20% des Sprints für technische Verbesserungen zu reservieren. Das bedeutet nicht, dass das Team einen Tag pro Woche nichts außer Refactoring macht. Die technischen Aufgaben werden gleichmäßig verteilt: Verbesserung von Metriken, Refactoring von Hotspots, Aktualisierung von Abhängigkeiten. Ohne dedizierte Zeit wachsen die Schulden kontinuierlich.

// Boy-Scout-Rule-Strategie in Aktion
// Vorher: unlesbare Methode mit magischen Zahlen
fun calc(a: Int): Int = a * 60 * 1000

// Nachher: lesbare Methode mit Konstanten
private const val SECONDS_IN_MINUTE = 60
private const val MILLIS_IN_SECOND = 1000

fun minutesToMillis(minutes: Int): Int =
    minutes * SECONDS_IN_MINUTE * MILLIS_IN_SECOND

Automatisierung der Schuldenerkennung ist die dritte Säule des Managements. Richten Sie Benachrichtigungen für die Erkennung langer Methoden (>30 Zeilen), Klassen (>500 Zeilen), übermäßiger Verschachtelung (>5 Ebenen) ein. Verwenden Sie Danger oder ähnliche Werkzeuge für automatische Kommentare bei Pull-Requests: wenn eine Methode die Komplexitätsschwelle überschreitet, schreibt der Bot „Diese Methode hat eine zyklomatische Komplexität von 12 — bitte erwägen Sie eine Aufteilung.” Die Automatisierung entlastet das Code-Review.

Werkzeuge zur Schuldenanalyse

SonarQube ist die beliebteste Plattform zur Analyse technischer Schulden. Sie berechnet „Tage bis zur Behebung” — eine für Manager verständliche Kennzahl. SonarQube unterstützt Kotlin, Swift, Java, Python und andere Sprachen. Es integriert sich in die CI/CD-Pipeline und lehnt Pull-Requests ab, wenn die Schulden den Schwellenwert überschreiten. Für mobile Teams ist dies der De-facto-Standard.

Für Android-Teams werden auch Detekt (statische Kotlin-Analyse) und Android Lint verwendet. Detekt berechnet Code-Metriken und findet Code-Smell-Muster. Das SonarQube-Android-Gradle-Plugin fasst Ergebnisse in einem einzigen Bericht zusammen. Für iOS-Teams — SwiftLint für statische Analyse und Periphery zum Auffinden ungenutzten Codes. Der Xcode Organizer zeigt Leistungsmetriken, die oft mit Architekturschulden korrelieren.

CodeClimate und CodeFactor sind Cloud-Lösungen, die GitHub/GitLab-Repositories analysieren und die Dynamik der Schulden anzeigen. Sie bewerten jeden Commit und ermöglichen so die Verfolgung, wann die Schulden zu wachsen begannen. Der Maintainability-Chart ist ein verständliches Werkzeug für die Kommunikation mit dem Management: „Sehen Sie den Peak im März? Da haben wir einen Release forciert und Schulden für 3 Tage Fehlerbehebungen angehäuft.”