Wann Refactoring reicht und wann nicht mehr
„Können wir das noch retten oder müssen wir neu bauen?"
Diese Frage steht in fast jedem Erstgespräch im Raum, meistens schon in den ersten zehn Minuten. Sie klingt vernünftig. Sie ist trotzdem die falsche Frage, weil sie sich auf den Zustand des Systems richtet. Retten kannst du fast jedes System. Die Frage ist, ob es sich noch lohnt.
Der Zustand allein sagt darüber nichts. Ein Shopsystem, das seit zehn Jahren läuft, sieht innen immer schlimm aus. Das ist kein Befund, das ist Alter. Was zählt, ist die Richtung: Wird eine durchschnittliche Änderung von Quartal zu Quartal teurer oder billiger? Wenn du das nicht beantworten kannst, ist das schon der erste Hinweis darauf, wie gut die Entscheidung vorbereitet ist.
Refactoring und Ablösung lösen verschiedene Probleme
Refactoring verbessert die Struktur innerhalb einer Grenze. Es macht Code lesbar und entkoppelt, was zusammengewachsen ist. Was es nicht kann: die Grenze selbst verschieben. Wenn die Fachlichkeit anders geschnitten ist als die Software, bekommst du durch Aufräumen einen gut sortierten falschen Schnitt.
Ablösung verschiebt Grenzen. Sie ist teurer, langsamer und riskanter, und du brauchst sie nur, wenn der Schnitt das Problem ist.
Der teuerste Fall in der Praxis ist nicht, dass Teams das Falsche wählen. Es ist, dass sie beides halb machen: ein bisschen aufräumen, nebenbei schon mal einen neuen Service anfangen, und den Rest sehen wir dann. Diese Variante ist mit Abstand die beliebteste. Sie ist auch die einzige, die zuverlässig beides nicht fertig bekommt.
Fünf Prüfungen ersetzen das Bauchgefühl
In zwölf Jahren E-Commerce-Architektur habe ich beide Wege gesehen, und in beiden Richtungen auch die teure Variante. Im Review gehe ich deshalb dieselben fünf Fragen durch. Keine davon entscheidet allein.
Erstens: Sitzt der Schmerz im Code oder im Schnitt? Dafür gibt es einen billigen Test. Nimm die letzten zehn bis fünfzehn Änderungswünsche und zähl nach, wie viele Module jeder davon angefasst hat. Wenn eine fachlich kleine Änderung regelmäßig durch fünf Stellen wandert, ist die Grenze falsch, nicht der Code. Wenn dieselben Änderungen jeweils an einer Stelle bleiben und nur mühsam sind, hast du ein Handwerksproblem. Das ist Refactoring-Territorium.
Zweitens: Kommst du überhaupt an den Code heran? Refactoring ohne Sicherheitsnetz ist kein Refactoring, sondern Umbau am offenen Herzen. Die ehrliche Prüfung ist nicht die Coverage-Zahl, sondern die Frage: Kannst du eine fachliche Regel ändern und weißt innerhalb einer Stunde, ob du etwas kaputt gemacht hast? Falls nicht, ist der erste Schritt in beiden Wegen derselbe, nämlich Tests an den Rändern. Diese Arbeit ist nie verloren. Sie ist auch die Voraussetzung dafür, später überhaupt etwas herauslösen zu können.
Drittens: Ist die Plattform noch unter dir? Bei Standardsoftware wie einem Shopsystem ist das der Punkt, an dem die Entscheidung oft schon gefallen ist, ohne dass jemand sie getroffen hat. Prüf, wie viele Erweiterungen den Kern nicht ergänzen, sondern überschreiben. Jede davon ist eine Wette gegen den Hersteller, und die verlierst du beim nächsten großen Versionssprung. Wenn das Upgrade seit drei Jahren im Backlog steht, steht es dort nicht wegen fehlender Kapazität. Es steht dort, weil niemand weiß, was beim Ziehen passiert.
Viertens: Wem gehören die Daten? Das Schema ist das Gravitationszentrum. Solange zwei Teile auf dieselben Tabellen schreiben, sind sie ein Teil, egal wie der Code aussieht. Für die Entscheidung zählt: Gibt es zu jedem fachlichen Kernbegriff genau eine Stelle, die schreibt? Falls nein, wird jede Ablösung länger dauern als geplant, und zwar deutlich. Das ist kein Argument gegen die Ablösung, aber es gehört in die Schätzung, bevor sie jemand zusagt.
Fünftens: Hat das Team die Ablösung frei? Eine Ablösung ist eine Betriebsart über ein bis zwei Jahre und braucht in dieser Zeit durchgehend Kapazität, die nicht in Features fließt. Wenn diese Zusage nicht existiert, ist die technisch richtige Entscheidung trotzdem die falsche. Dann ist zielgerichtetes Refactoring an den drei schmerzhaftesten Stellen das ehrlichere Programm.
Zwei bis drei Treffer sprechen für die Ablösung. Wichtiger als die Zählung ist aber, dass du die Antworten aufschreibst. Eine Entscheidung, die niemand begründet hat, wird in achtzehn Monaten neu diskutiert. Mit denselben Argumenten und weniger Geduld.
Der Weg dazwischen ist der übliche
In der Praxis ist es fast nie ein Entweder-oder, und zwar aus einem unspektakulären Grund: Um ein Stück herauszulösen, brauchst du eine saubere Schnittkante. Die gibt es in einem gewachsenen System nicht geschenkt, du musst sie erst herstellen. Genau das ist Refactoring.
Deshalb ist ein Jahr Aufräumen vor einer Ablösung kein verlorenes Jahr. Es ist die Vorbereitung, ohne die der erste Umzug im Chaos endet. Wie es danach weitergeht, steht in Strangler Fig: ablösen statt ersetzen.
Umgekehrt gilt das auch. Wer sich für Refactoring entscheidet, sollte festhalten, woran er merken würde, dass es nicht mehr reicht. Ein Satz genügt: Wenn eine durchschnittliche Änderung in zwei Quartalen nicht spürbar billiger geworden ist, reden wir wieder über die Grenze. Ohne dieses Kriterium wird Refactoring zum Dauerzustand, den irgendwann niemand mehr rechtfertigen kann und den trotzdem alle bezahlen.
Was die Entscheidung wirklich blockiert
Sie fällt selten aus technischen Gründen nicht. Sie fällt nicht, weil beide Antworten unangenehm sind. Ablösung heißt: teuer, lange, ohne sichtbares neues Feature. Refactoring heißt: Wir geben zu, dass wir das Problem kennen und trotzdem damit weiterleben.
Nicht zu entscheiden fühlt sich daneben günstig an. Ist es nicht. Es ist eine Entscheidung für den Zustand von heute, nur ohne Termin und ohne Budget.
Der brauchbare Ausweg ist unspektakulär: die fünf Fragen beantworten, die Antworten auf eine Seite schreiben, ein Datum daruntersetzen, an dem nachgeschaut wird. Danach kann man streiten. Vorher streitet man nur über Bauchgefühle, und dabei gewinnt immer der Lauteste.
Klingt nach deinem Thema? Schreib mir. Im Erstgespräch klären wir unverbindlich, ob und wie ich helfen kann.