Wie entscheidest du, wann ein System refactored statt von Grund auf neu geschrieben werden soll?

Question

Accepted Answer

Standardmäßig **refactoren**. Ein Rewrite ist nur gerechtfertigt, wenn das bestehende System sich nicht mehr zu vertretbaren Kosten weiterentwickeln kann, um die Anforderungen zu erfüllen, und du währenddessen weiter Wert liefern kannst. Die meisten „wir brauchen einen Rewrite"-Instinkte sind in Wirklichkeit ein ungemanagtes Tech-Debt-Problem, das inkrementelles Refactoring mit weit weniger Risiko löst.

## Wie ich darüber nachdenke

- **Ist die Kernarchitektur noch tragfähig?** Wenn das Datenmodell, die Grenzen und die Runtime sich auf die neuen Anforderungen dehnen lassen, refactore. Wenn die grundlegenden Annahmen falsch sind (falsches Storage-Paradigma, keine Möglichkeit zu skalieren, Sprache/Plattform am End-of-Life), wird ein Rewrite zu einem echten Kandidaten.
- **Wie hoch ist die Änderungsfrequenz?** Code, der sich selten ändert, muss nicht schön sein. Konzentriere die Mühe dort, wo das Team täglich arbeitet.
- **Verstehen wir das aktuelle Verhalten?** Ein Rewrite wirft jahrelang kodiertes Edge-Case-Wissen weg. Wenn es keine Tests und keine Spezifikation gibt, führt ein Rewrite alte Bugs wieder ein.

## Ein Entscheidungs-Framework

| Signal | Tendenz Refactor | Tendenz Rewrite |
| --- | --- | --- |
| Architektur passt zu Anforderungen | Ja | Nein |
| Test-/Spec-Abdeckung | Niedrig oder hoch | Hoch genug, um Parität zu verifizieren |
| Kann inkrementell ausgeliefert werden | Ja | Schwer, Big-Bang |
| Team versteht den Code | Ja | Nein, und Originalautoren weg |

## Trade-offs

- **Refactor:** geringeres Risiko, kontinuierliche Auslieferung, aber langsam auf einem wirklich verrotteten Fundament.
- **Rewrite:** sauberer Neuanfang, aber du zahlst eine **Feature-Freeze-Steuer**, trägst **Dual-Maintenance-Kosten** und riskierst die klassische Second-System-Over-Engineering-Falle.
- Bevorzuge den **Strangler-Fig**-Mittelweg: stelle das neue System neben dem alten auf, route den Traffic inkrementell, lösche das alte Stück für Stück. Es bringt Rewrite-Vorteile mit Refactor-Risiko.

## Fallstricke

- Aus **ästhetischen oder Resume-Driven**-Gründen neu schreiben, nicht aus geschäftlichen Kosten.
- Verstecktes Verhalten unterschätzen; charakterisiere das aktuelle Verhalten immer zuerst mit Tests.
- Ein Big-Bang-Rewrite über mehrere Quartale, der nichts ausliefert — Momentum und Vertrauen brechen beide zusammen.

## Warum es wichtig ist

Die Refactor-vs-Rewrite-Entscheidung ist eine der wirkungsvollsten Entscheidungen, die ein Tech Lead trifft. Mach sie falsch Richtung Rewrite, und du kannst die Auslieferung ein Jahr lang einfrieren und trotzdem scheitern; mach sie falsch Richtung Refactor, und du blutest langsam Velocity. Sie als Kosten-und-Risiko-Entscheidung zu rahmen, nicht als Geschmacksentscheidung, ist das, was Senior-Urteilsvermögen von Präferenz unterscheidet.

Signal	Tendenz Refactor	Tendenz Rewrite
Architektur passt zu Anforderungen	Ja	Nein
Test-/Spec-Abdeckung	Niedrig oder hoch	Hoch genug, um Parität zu verifizieren
Kann inkrementell ausgeliefert werden	Ja	Schwer, Big-Bang
Team versteht den Code	Ja	Nein, und Originalautoren weg