Wann umschreiben vs. wann refactoren — Ein Entscheidungs-Framework für CTOs

Jeder CTO, VP Engineering oder technische Gründer steht irgendwann vor der gleichen Frage: Sollen wir dieses System von Grund auf neu schreiben oder das Vorhandene refactoren?

Es ist eine der folgenreichsten Entscheidungen in der Softwareentwicklung — und eine der am häufigsten aus dem Bauch heraus und nicht aufgrund von Analysen getroffenen Entscheidungen. Die Entwickler wollen einen Rewrite, weil die Arbeit am alten Code schmerzhaft ist. Das Management will ein Refactoring, weil es schneller und günstiger klingt. Beide liegen oft falsch.

Hier ist ein strukturierter Weg, um die Entscheidung zu treffen.

Die Versuchung des Rewrites

Rewrites sind verführerisch, weil sie einen sauberen Neustart versprechen. Keine Legacy-Einschränkungen. Ein moderner Tech-Stack. Vollständige Testabdeckung. Alles vom ersten Tag an "richtig" gemacht.

Die Realität ist weniger reizvoll. Die meisten Rewrites:

• Dauern 2–3-mal länger als geschätzt. Das alte System beinhaltet jahrelange Geschäftsregeln, Sonderfälle und regulatorische Anforderungen, die nie dokumentiert wurden. Sie entdecken sie erst, wenn sie im neuen System fehlen.
• Kosten 2–5-mal mehr als geschätzt. Längere Zeitpläne bedeuten mehr Entwicklermonate, mehr Projektmanagement-Overhead und mehr Opportunitätskosten durch Features, die nicht entwickelt werden.
• Werden häufig abgebrochen. Das Geschäft läuft auf dem alten System, während Sie das neue bauen. Wenn der Rewrite zu lange dauert, verliert die Führung das Vertrauen, die Finanzierung wird gestrichen, und Sie müssen am Ende zwei halb funktionierende Systeme warten.

Joel Spolsky nannte Rewrites den "schlimmsten strategischen Fehler", den ein Softwareunternehmen machen kann. Das war im Jahr 2000. Die Beweise seitdem haben seinen Standpunkt nur bestätigt.

Die Refactoring-Realität

Refactoring — die inkrementelle Verbesserung der bestehenden Codebase ohne Änderung des externen Verhaltens — ist die konservative Wahl. Es ist oft auch die richtige.

Aber Refactoring hat seine eigenen Fehlermodi:

• Refactoring ohne klare Ziele wird zur Beschäftigungstherapie. "Lass uns den Code aufräumen" ist keine Strategie. Refactoring sollte auf spezifische, messbare Ergebnisse abzielen: Reduzierung der Deployment-Zeit von 2 Stunden auf 10 Minuten, Eliminierung der Fehlerklasse, die durch gemeinsamen mutierbaren Zustand (shared mutable state) verursacht wird, Testbarkeit des Bestellabwicklungsmoduls.
• Einige Systeme widersetzen sich inkrementellen Verbesserungen. Wenn die fundamentale Architektur falsch ist — ein Monolith ohne Modulgrenzen, ein Datenbankschema, das nicht zusammenhängende Belange vermischt, eine Laufzeitumgebung, die End-of-Life ist —, wird ein Refactoring innerhalb dieser Architektur das zugrunde liegende Problem möglicherweise nicht lösen.
• Refactoring erfordert Disziplin. Es erfordert das Schreiben von Tests für Code, den Sie nicht geschrieben haben, das Verstehen von Geschäftslogik, die niemand dokumentiert hat, und das Vornehmen von Änderungen, die für Stakeholder unsichtbar sind. Es ist nicht glamourös, und es ist schwer, den Schwung (Momentum) beizubehalten.

Das Entscheidungs-Framework

Anstatt die Frage "Rewrite oder Refactoring?" als binäre Wahl zu stellen, bewerten Sie Ihr System anhand von fünf Dimensionen:

1. Ist die Kernarchitektur grundlegend falsch?

Wenn die Struktur des Systems es unmöglich macht, Ihre Ziele zu erreichen — unabhängig von der Code-Qualität —, wird ein Refactoring nicht helfen. Beispiele:

• Die Anwendung ist ein Single-Thread-Monolith und Sie müssen 100-mal mehr gleichzeitige Nutzer bewältigen.
• Das Datenbankschema mischt Buchhaltung, Nutzerverwaltung und Produktbestand in einer einzigen Tabelle.
• Die Laufzeitumgebung ist End-of-Life ohne Migrationspfad (z. B. Python 2, PHP 5.x mit mysql_* Funktionen überall).

Wenn ja: Ein Rewrite ist wahrscheinlich notwendig — ziehen Sie jedoch einen Strangler Fig-Ansatz anstelle eines Big-Bang-Rewrites in Betracht.

Wenn nein: Refactoren Sie. Die Architektur ist solide; nur der Code muss verbessert werden.

2. Wie viel institutionelles Wissen ist vorhanden?

Versteht Ihr Team das System? Kann es erklären, warum Entscheidungen getroffen wurden? Gibt es Dokumentationen?

• Hohes Wissen, wenig Dokumentation: Refactoren Sie. Das Team kann die Verbesserung steuern.
• Wenig Wissen, wenig Dokumentation: Gefährliches Terrain in beide Richtungen. Beginnen Sie mit einem System-Audit, bevor Sie eine Entscheidung treffen.
• Überhaupt kein Wissen (z. B. erworbenes System, ursprüngliches Team weg): Ein Rewrite kann praktischer sein, als zu versuchen, ein System zu verstehen und zu verbessern, das niemand erklären kann.

3. Was sind die Kosten für einen Feature Freeze?

Während eines Rewrites läuft das alte System weiter, erhält aber in der Regel keine neuen Features mehr. Kann das Unternehmen das tolerieren?

• Wenn das System sofort neue Features benötigt: Refactoren Sie. Sie können das System verbessern und gleichzeitig geschäftlichen Mehrwert liefern.
• Wenn das Unternehmen 6–12 Monate warten kann: Ein Rewrite wird praktikabler — aber schätzen Sie sorgfältig.

4. Wie hoch ist die Risikotoleranz?

Ein Rewrite hat einen bimodalen Ausgang: Er gelingt entweder spektakulär oder scheitert teuer. Ein Refactoring hat einen vorhersehbareren Ausgang: allmähliche, messbare Verbesserung.

• Niedrige Risikotoleranz (regulierte Branche, produktionskritisches System): Refactoren Sie. Sie können sich keine fehlgeschlagene Umstellung (Cutover) leisten.
• Hohe Risikotoleranz (Early-Stage-Startup, internes Tool): Ein Rewrite ist akzeptabler, wenn der Zeitrahmen kurz genug ist.

5. Was sagen die Daten?

Messen Sie, bevor Sie entscheiden. Sie benötigen:

Wenn die Deployment-Häufigkeit hoch ist, die MTTR niedrig ist und das System größtenteils funktioniert — refactoren Sie. Die Probleme des Systems liegen auf der Code-Ebene, nicht auf der Architekturebene.

Wenn die Deployment-Häufigkeit nahe null liegt, die MTTR in Tagen gemessen wird und jede Änderung etwas kaputt macht — ist die Architektur das Problem, und Refactoring innerhalb dieser Architektur wird nicht helfen.

Die Hybridoption: Strangler Fig

Die beste Antwort ist oft weder ein reiner Rewrite noch ein reines Refactoring, sondern eine kontrollierte Extraktion. Mit dem Strangler Fig Pattern (Würgefeigen-Muster) können Sie:

1. Den schlechtesten Teil des Systems identifizieren.
2. Einen Ersatz für diesen Teil auf einem modernen Tech-Stack bauen.
3. Den Traffic schrittweise zur neuen Implementierung leiten.
4. Den alten Code löschen, sobald sich der Ersatz bewährt hat.
5. Den Vorgang für den nächstschlechtesten Teil wiederholen.

Dies kombiniert die Vorteile eines Rewrites (sauberer neuer Code) mit der Sicherheit eines Refactorings (kein Big-Bang-Cutover). Es dauert theoretisch länger als ein Rewrite, liefert aber schrittweise einen Mehrwert und birgt ein drastisch geringeres Risiko.

Die Entscheidung treffen

Wenn Sie vor dieser Entscheidung stehen und eine zweite Meinung einholen möchten, die auf Daten statt auf Instinkt basiert — ein System-Audit kartiert die Architektur, quantifiziert die Schulden und liefert Ihnen die Beweise, um die Entscheidung mit Zuversicht zu treffen. Es ist ein Engagement von zwei bis drei Wochen, keine mehrmonatige Verpflichtung.