Workaround in der Programmierung: Was es ist, welche Arten es gibt und wie es funktioniert

Was ist ein Workaround in der Programmierung?

Workaround ist ein umgangssprachlicher Begriff für eine Softwarelösung, die funktional korrekt, aber technisch suboptimal ist. Solcher Code funktioniert, besteht Tests und gelangt sogar in die Produktion, aber beim Lesen möchte man alles von Grund auf neu schreiben. Im englischsprachigen Raum werden die Begriffe Workaround, Kludge (Kluge), Hack oder Quick-and-Dirty-Fix verwendet.

Der Begriff stammt aus einer haushaltsüblichen Metapher: Wenn ein Stuhlbein bricht, kann man es mit Klebeband fixieren — der Stuhl funktioniert wieder, aber die Lösung ist temporär und unschön. In der Programmierung gilt dasselbe: Ein Bug wird mit Hardcode, einem Timeout-Workaround oder einer Umgehung über eine undokumentierte API behoben. Der Code kompiliert, die Anwendung stürzt nicht ab, aber die Lösung kann nicht als qualitativ hochwertig bezeichnet werden.

Ein wichtiger Unterschied: Ein Bug liegt vor, wenn der Code nicht wie erwartet funktioniert. Ein Workaround liegt vor, wenn der Code funktioniert, aber schlecht entworfen ist. Ein Workaround ist immer eine bewusste Entscheidung des Entwicklers: „Ich weiß, dass das hässlich ist, aber im Moment löst es das Problem.“

Laut Stripe (2024) verbringen Entwickler durchschnittlich 17 Stunden pro Woche mit technischen Schulden und Workarounds — fast die Hälfte ihrer Arbeitszeit. Dies ist ein direkter Produktivitätsverlust des Teams.

Wann und warum entstehen Workarounds

Der erste und Hauptgrund sind Deadlines. Wenn bis zur Veröffentlichung noch ein Tag bleibt und ein kritischer Bug noch nicht behoben ist, wählt das Team eine schnelle Lösung statt der richtigen. Das Hardcodieren eines Werts, das Deaktivieren einer Prüfung, das Hinzufügen von sleep() — klassische Beispiele für Deadline-Workarounds. Ein erfahrener Entwickler markiert solche Stellen immer mit TODO oder FIXME.

Der zweite Grund ist die API-Inkompatibilität. Eine Drittanbieter-Bibliothek oder ein Framework verhält sich anders als dokumentiert. Das Framework exportiert die erforderliche Klasse nicht, eine Methode ist als veraltet markiert und es gibt keine Alternative. Der Entwickler ist gezwungen, Reflection, interne APIs oder einen Umgehungsweg zu nutzen. In Java kann dies der Zugriff über setAccessible(true) sein, in Swift — @objc und performSelector.

Der dritte Grund ist Legacy-Code. Ein Entwickler erbt ein Projekt, das vor 5-10 Jahren mit einer veralteten Framework-Version geschrieben wurde. Es gibt weder Zeit noch Budget, das gesamte Modul neu zu schreiben, daher wird die neue Funktionalität durch Workarounds an den alten Code „angeklebt“. Nach und nach sammeln sich so viele Schichten an, dass das Modul zu einem „großen Schlamassel“ (Big Ball of Mud) wird.

Der vierte Grund ist der Mangel an Tests. Refactoring ohne Tests ist gefährlich: Eine Änderung der Architektur kann funktionierende Funktionalität zerstören. Wenn keine Tests vorhanden sind, zieht es der Entwickler vor, einen Workaround auf den funktionierenden Code zu setzen, anstatt die Stabilität zu riskieren. Laut Google Testing Blog (2024) verwenden Teams ohne Tests dreimal häufiger Workaround-Lösungen.

Arten von Workarounds

Die Klassifizierung von Workarounds hilft dem Team zu verstehen, mit welcher Art von technischen Schulden es zu tun hat, und die richtige Beseitigungsstrategie zu wählen. Sehen wir uns die wichtigsten Arten an.

Hardcode — der häufigste Typ. Anstelle von Konfiguration, Ressource oder Parameter wird ein fester Wert im Code verwendet. Beispiel: eine hartcodierte Server-URL, ein 5-Sekunden-Timeout, eine Schriftgröße von 16pt. Hardcode macht Code nicht skalierbar und erfordert bei jeder Änderung eine Neukompilierung.

Copy-Paste — das Duplizieren von Codeabschnitten mit minimalen Änderungen, anstatt die gemeinsame Logik zu extrahieren. Klassisches Symptom: Es gibt 3 ähnliche Methoden im Projekt, die sich in einer Zeile unterscheiden. Copy-Paste beschleunigt das Schreiben von Code zum Zeitpunkt der Aufgabe, verlangsamt aber die zukünftige Wartung um das Zehnfache — die Korrektur muss an 3 Stellen statt an einer vorgenommen werden.

Leerer Try-Catch — ein Catch-Block, der nichts tut oder den Fehler nur protokolliert, ohne ihn zu behandeln. Ein solcher Workaround „unterdrückt“ die Ausnahme, behebt aber nicht ihre Ursache. Die Anwendung läuft weiter, aber Daten können beschädigt werden und der Benutzer erhält möglicherweise keine Rückmeldung.

Sleep im Code — Thread.sleep(500) oder DispatchQueue.main.asyncAfter zum Warten, wenn ein Ereignis oder Callback erfolgen sollte. Solcher Code ist unzuverlässig: Auf einem langsamen Gerät reichen 500 ms möglicherweise nicht aus, auf einem schnellen ist die Pause unnötig. Verwenden Sie CountDownLatch, Semaphore oder async/await mit korrekter Zeitsteuerung.

Kompatibilitäts-Flags — If-Else-Kaskaden, die die OS-Version, das Gerätemodell oder die Verfügbarkeit einer Funktion prüfen. Bei mehr als 3-4 Flags wird der Code zu Spaghetti. Die Lösung ist das Strategy-Pattern oder Feature Flags über Konfiguration.

Workaround vs technische Schulden

Viele Entwickler verwechseln Workaround und technische Schulden. Der Unterschied liegt im Umfang und Bewusstsein. Ein Workaround ist eine lokale, spezifische Lösung (eine Methode, eine Klasse). Technische Schulden sind ein systemisches Problem, das die Architektur eines Moduls oder der gesamten Anwendung betrifft.

Die Metapher von Ward Cunningham (Schöpfer des Begriffs Technische Schulden): Technische Schulden sind wie ein Bankkredit. Sie nehmen jetzt Geld, um das Haus schneller zu bauen, zahlen aber später Zinsen. Ein Workaround ist wie das Einschlagen eines Nagels mit einem Hammer statt einer Nagelpistole: Die Arbeit wird erledigt, aber weniger effizient.

Ein Workaround schafft keine technischen Schulden. Aber 50 Workarounds in einem Modul = architektonische Schulden. Daher gilt die Teamregel: Jeder Workaround wird im Code-Review oder im Task-Tracker festgehalten, und das Team überprüft regelmäßig (einmal pro Sprint) die angesammelten Workaround-Lösungen.

Laut Spotify Engineering (2023) reduzieren Teams, die Workarounds im Code verfolgen (über ein spezielles TODO-Label oder eine benutzerdefinierte Annotation), die Refactoring-Zeit um 30% — weil sie keine Stunden mit der Suche nach Problemstellen verbringen.

Wie man Workarounds beseitigt

Der erste Schritt ist die Bestandsaufnahme. Durchsuchen Sie die Codebasis nach Schlüsselwörtern: TODO, FIXME, HACK, WORKAROUND, KLUDGE. Moderne IDEs heben diese in einer separaten Farbe hervor. GitHub zeigt TODO auch in der Pull-Request-Oberfläche an. Erstellen Sie eine Liste aller Workarounds mit Priorität.

Der zweite Schritt ist die Priorisierung. Nicht alle Workarounds müssen sofort behoben werden. Priorität = Änderungshäufigkeit der Datei × Kritikalität. Wenn eine Datei 2 Mal im Jahr geändert wird, kann der Workaround warten. Wenn ein Modul in jedem Sprint bearbeitet wird — sollte der Workaround zuerst behoben werden.

Der dritte Schritt ist das Refactoring mit Tests. Führen Sie niemals ein Refactoring eines Workarounds ohne Tests durch. Schreiben Sie zuerst einen Test, der das aktuelle Verhalten (mit dem Workaround) überprüft, dann refactoren Sie, dann stellen Sie sicher, dass der Test bestanden wird. Ohne dies kann das Refactoring eines Workarounds die Funktionalität zerstören, für die er geschrieben wurde.

// Before: Hartcodierter URL-Workaround
fun getApiUrl(): String {
    return "https://api.example.com/v2"
}

// After: Konfiguration über BuildConfig
fun getApiUrl(): String {
    return BuildConfig.API_BASE_URL
}

Der vierte Schritt ist die Automatisierung. Richten Sie einen Linter ein, der bestimmte Workaround-Muster verbietet. Beispielsweise kann Detekt für Kotlin das Fehlen von Thread.sleep() im Produktionscode überprüfen, ESLint kann console.log im Projekt verbieten. Dies verhindert das Auftreten neuer Workarounds desselben Typs.

Wann ein Workaround gerechtfertigt ist

Trotz der negativen Konnotation des Begriffs kann ein Workaround eine gerechtfertigte Lösung sein. Die Hauptbedingung: Der Workaround ist temporär, explizit markiert und hat einen Ersatzplan. Im Produktionscode jedes großen Projekts gibt es Hunderte von gerechtfertigten Workarounds.

Situation 1: Hotfix in der Produktion. Ein kritischer Bug betrifft alle Benutzer. Das Team benötigt eine Korrektur innerhalb einer Stunde. Der richtige Ansatz: Beheben Sie den Bug auf jede mögliche Weise, deployen Sie den Hotfix. Dann, am nächsten Tag, schreiben Sie die richtige Lösung und schließen das Ticket. Ein Hotfix ist ein gerechtfertigter Workaround, wenn er nicht länger als 48 Stunden lebt.

Situation 2: Warten auf eine neue Bibliotheksversion. Ein Framework enthält einen Bug, der im Master behoben wurde, aber die Veröffentlichung erfolgt in 2 Wochen. Anstatt komplexen Umgehungscode zu schreiben, fügt das Team einen Workaround mit dem Hinweis „REMOVE after library 3.2“ hinzu. Wenn Version 3.2 erscheint, wird der Workaround entfernt.

Situation 3: Abschluss eines Startups oder MVP. In der MVP-Phase ist Geschwindigkeit wichtiger als Architektur. Workarounds am Anfang sind normal. Das Problem entsteht, wenn sich das Startup nicht in ein Produkt verwandelt, aber die Workarounds bleiben. Empfehlung: Widmen Sie nach einer Finanzierungsrunde einen Sprint der Tilgung kritischer technischer Schulden.

Das Hauptprinzip: „Legacy-Code ist Code ohne Tests“ (Michael Feathers). Wenn ein Workaround durch einen Test abgedeckt und explizit dokumentiert ist — ist er beherrschbar. Wenn er seit 2 Jahren ohne Kommentare in einem vergessenen Modul hängt — ist das kein Workaround mehr, sondern ein architektonisches Problem.