Krücken in der Programmierung — was sie sind, Ursachen und wann sie gerechtfertigt sind

Was ist eine „Krücke“ in der Programmierung

Eine Krücke (crutch) ist eine Softwarelösung, die funktioniert, aber „auf die Schnelle“ gemacht ist: Sie behebt ein spezifisches Problem, beseitigt aber nicht dessen Ursache, folgt nicht der Architektur des Projekts und kann bei kleinsten Änderungen in der Umgebung kaputtgehen. Die Metapher ist treffend — wie eine echte Krücke hilft dieser Code beim „-Gehen“, heilt aber nicht das „Bein.“

Entwickler „stützen mit Krücken ab“: Bugs, Versionsinkompatibilitäten, Plattformbesonderheiten und dringende Kundenanforderungen. Eine typische Krücke ist eine bedingte Krücke: Wenn iOS 15, füge einen Abstand hinzu; wenn Huawei, verstecke den Button. Solche Prüfungen vermehren sich und verwandeln den Code in einen „Schichtkuchen“ aus Plattform- und Versionsverzweigungen.

Krücken gibt es in verschiedenen Größenordnungen: von einer einzelnen Zeile mit einer Krückenbedingung bis hin zu einem ganzen Wrapper-Modul, das das Verhalten einer Bibliothek „korrigiert“. Es ist wichtig zu verstehen, dass eine Krücke nicht immer schlecht ist: In den richtigen Händen ist sie ein Werkzeug, das es ermöglicht, ein Produkt rechtzeitig auszuliefern. Das Problem beginnt, wenn die Krücke für immer im Code bleibt.

Warum Krücken auftreten: Ursachen und Kontext

Der Hauptgrund für das Auftreten von Krücken ist der Konflikt zwischen der idealen Lösung und den realen Einschränkungen des Projekts. Der Entwickler weiß, wie es richtig geht, aber Zeit, Geld oder technische Einschränkungen verhindern es. Als Ergebnis entsteht eine Kompromisslösung, die „einfach funktioniert.“

Betrachten wir vier Hauptgründe, warum Entwickler bewusst zu Krücken greifen. Das Verständnis dieser Gründe hilft, Krücken nicht als Fehler, sondern als pragmatisches Werkzeug zu betrachten, das verwaltet werden muss.

Deadlines

Der häufigste Grund. Der Release ist morgen, der Bug tritt nur auf einem bestimmten Modell auf, und die architektonische Behebung würde zwei Wochen dauern. Eine bedingte Krücke dauert eine Stunde und schließt das Problem. Nach dem Release verspricht das Team, zurückzukommen und es richtig neu zu schreiben. „Nichts ist beständiger als ein Provisorium“ — das gilt genau für solche Krücken.

Versionsinkompatibilität

Bibliothek A erfordert Android 12, aber Ihre App unterstützt Android 10. Die Lösung ist, einen Wrapper zu schreiben, der die OS-Version prüft und den Ausführungspfad wählt. Dies ist eine Krücke, denn bei der Aktualisierung der Bibliothek muss der Wrapper neu geschrieben werden. Aber die Alternative — die Bibliothek oder die Unterstützung alter Geräte aufzugeben — könnte schlimmer sein.

// Krücke für API-29-Kompatibilität
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

Drittanbieter-Abhängigkeiten mit Bugs

Eine Bibliothek, von der das Projekt abhängt, hat einen Bug, aber deren Aktualisierung könnte Wochen dauern (PR, Code-Review, Veröffentlichung). Statt zu warten, schreibt das Team einen Wrapper, der das Verhalten der Bibliothek im laufenden Betrieb patcht. Wenn die korrigierte Version der Bibliothek veröffentlicht wird, wird der Wrapper entfernt. Wird er nicht entfernt, ist das bereits ein Architekturproblem.

Unvollständiges Systemverständnis

Ein neuer Entwickler in einem Legacy-Projekt versteht nicht, warum der Code so funktioniert, wie er tut. Anstatt es herauszufinden, fügt er eine neue Bedingung zu den bestehenden hinzu. Dies ist die gefährlichste Art von Krücke, weil der Autor nicht erkennt, dass es eine Krücke ist. Das einzige Heilmittel sind Code-Reviews und Pair Programming für neue Teammitglieder.

Wann eine Krücke gerechtfertigt ist: pragmatischer Ansatz

Nicht jede Krücke ist schlecht. In der realen Entwicklung ist absolute Code-Reinheit unerreichbar und oft unpraktisch. Ein pragmatischer Ansatz erkennt an, dass temporäre Lösungen Teil des Prozesses sind, verlangt aber Bewusstsein, Dokumentation und einen Beseitigungsplan. Eine Krücke ist gerechtfertigt, wenn sie ein Geschäftsproblem schneller löst als eine saubere Architekturlösung.

Die Kriterien für eine gerechtfertigte Krücke: Sie behebt ein spezifisches Problem, hat einen Verantwortlichen (jemand, der für ihre Entfernung zuständig ist), und es existiert ein Refactoring-Plan. Fehlt mindestens eine dieser drei Bedingungen, verwandelt sich die Krücke in technische Schulden. Werkzeuge wie TODO-Kommentare mit einem Ticket im Tracker sind die minimale Dokumentationsmethode.

Beispiel einer gerechtfertigten Krücke

Ein kritischer Bug im Release-Branch, der vor dem morgigen Deployment behoben werden muss. Die saubere Lösung erfordert ein Architektur-Refactoring und würde zwei Wochen dauern. Die Krücke: eine Nil-Prüfung hinzufügen und den Fix als Hotfix senden. Bedingungen der Rechtfertigung: Ein Refactoring-Ticket wurde im Tracker erstellt, ein Verantwortlicher wurde zugewiesen und die Krücke ist mit einem Kommentar markiert. Zwei Wochen später kehrt das Team zur Aufgabe zurück.

// TODO: IT-1234 — diese Krücke nach AuthService-Refactoring entfernen
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

Wie man eine temporäre Krücke von einem Architekturproblem unterscheidet

Die Grenze zwischen einer bewussten Krücke und einem Architekturproblem (technische Schulden) verläuft entlang zweier Parameter: Bewusstsein der Entscheidung und Existenz eines Plans zu deren Beseitigung. Eine Krücke ist immer eine temporäre Lösung mit bekannter Lebensdauer. Technische Schulden sind die Folge vieler unbeaufsichtigter Krücken.

Wann eine Krücke zum Problem wird

Die Situation verschlechtert sich, wenn die Anzahl der Krücken eine kritische Masse überschreitet. Jede neue Krücke erhöht die „-Zerbrechlichkeit“ des Systems: Eine Änderung an einer Stelle bricht eine andere. Schließlich verlangsamt sich die Entwicklung, Bugs vermehren sich und ein neuer Entwickler kann den Code ohne Hilfe des Autors nicht verstehen. An diesem Punkt hören Krücken auf, temporäre Lösungen zu sein, und werden zu einem Architekturproblem.

Anzeichen einer Krückenkrise

Wenn der Code fünf verschachtelte Prüfungen auf OS-Version, Gerätehersteller und Vorhandensein einer bestimmten Bibliothek enthält — ist das keine Krücke, sondern ein Architekturproblem. Wenn das Hinzufügen einer Korrektur drei Regressionen in verwandten Modulen verursacht — sind Krücken nicht mehr lokal. Wenn Code-Reviews regelmäßig wegen „-noch einer Krücke“ abgelehnt werden — ist es Zeit, ein Refactoring zu planen.

• Dieselbe Krücke wiederholt sich an drei oder mehr Stellen — Zeit für eine einheitliche Lösung
• Eine Krücke lebt länger als drei Sprints ohne Beseitigungsplan — das sind bereits technische Schulden
• Ein neuer Entwickler versteht nicht, warum der Code so funktioniert — die Krücke ist nicht dokumentiert
• Das Entfernen der Krücke verursacht eine Kettenreaktion von Fehlern — die Abhängigkeit von der Krücke ist architektonisch geworden

Refactoring von Krücken: Strategie und Praxis

Refactoring von Krücken ist der Prozess, temporäre Lösungen durch architektonisch korrekte zu ersetzen. Dies erfordert Zeit, daher ist eine Priorisierungsstrategie notwendig: Nicht alle Krücken müssen sofort beseitigt werden. Eine gute Strategie ist, jede Krücke nach zwei Parametern zu bewerten: Änderungshäufigkeit in diesem Codebereich und Auswirkung auf die Benutzer.

Priorisierungsstrategie

Hohe Priorität — Krücken in häufig geänderten Modulen (Geschäftslogik, Allzweck-UI), die die Entwicklung verlangsamen und Regressionen verursachen. Mittlere Priorität — Krücken in selten geänderten Modulen, aber mit potenzieller Auswirkung auf Benutzer (Zahlungsabwicklung, Autorisierung). Niedrige Priorität — Krücken in Legacy-Code, der stabil läuft und nicht zur Änderung vorgesehen ist.

Schrittweiser Beseitigungsprozess

Schritt 1: Inventur — finden Sie alle TODOs und FIXMEs im Zusammenhang mit Krücken. Schritt 2: Bewertung — bestimmen Sie, welche noch relevant sind. Schritt 3: Planung — planen Sie das Krücken-Refactoring in einem Sprint, beginnend mit hoher Priorität. Schritt 4: Ersetzung — implementieren Sie die saubere Lösung, entfernen Sie die Krücke und ihren TODO-Kommentar. Schritt 5: Verifikation — stellen Sie sicher, dass Tests bestanden werden und keine Regressionen auftreten.

# Alle TODO-Krücken im Projekt finden
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

Verhinderung neuer Krücken

Der beste Weg, Krücken zu bekämpfen, ist, sie nicht unnötig zu schaffen. Bevor Sie eine Krücke schreiben, stellen Sie sich drei Fragen: Kann ich in angemessener Zeit eine saubere Lösung implementieren? Gibt es eine Alternative, die keine Krücke ist? Wird das Team Zeit haben, zurückzukommen und dies neu zu schreiben? Wenn die Antwort auf mindestens eine Frage „-Nein“ lautet — denken Sie noch einmal nach, bevor Sie den Code „-abstützen.“