Rewrite oder Refactoring: Die Frage ist falsch gestellt

Die Frage kommt meistens als Entweder-Oder: Bauen wir neu oder räumen wir auf? Und sie ist in dieser Form kaum zu beantworten, weil sie über den Code gestellt wird, während sie über etwas anderes entschieden wird.

Eine Codebasis ist nicht der Text eines Programms. Sie ist materialisiertes Wissen über eine Domäne: tausende kleiner Entscheidungen, warum es hier so und nicht anders läuft, getroffen über Jahre. Ein Rewrite vernichtet nicht den schlechten Code. Er vernichtet dieses Wissen.

Warum Altcode aussieht, wie er aussieht

Legacy-Code ist selten hässlich, weil Anfänger ihn geschrieben haben. Er ist hässlich, weil er den Kontakt mit der Wirklichkeit überlebt hat. Jede merkwürdige Verzweigung, jeder Sonderfall, jeder Kommentar mit einer Jahreszahl darin ist die Narbe eines Vorfalls, den jemand einmal ausgebadet hat.

Neuer Code hatte diesen Kontakt noch nicht. Er ist deshalb schöner, und er weiß weniger. Ein Team, das neu baut, läuft dieselben Fehler noch einmal ab, nur diesmal unter Termindruck und mit einer laufenden Altanwendung als Vergleichsmaßstab, den es zu Beginn nicht erreicht.

Das ist der Grund, warum die Frage nach der Codequalität in die Irre führt. Schlechter Code ist ein Symptom, keine Diagnose, und er sagt nichts darüber, wie teuer sein Ersatz wird.

Die drei Signale, die tatsächlich entscheiden

Was die Entscheidung trägt, sind nicht Eigenschaften des Codes, sondern drei Fragen an den Zustand des Projekts.

Testbarkeit als Schwelle. Nicht: gibt es Tests. Sondern: lassen sich welche einziehen, ohne vorher umzubauen. Wo Abhängigkeiten nicht ersetzbar sind, wo Singletons den Zustand überall hin verteilen, wo eine Klasse fünftausend Zeilen trägt, gibt es keine Naht, an der man ansetzen könnte. Refactoring wird dort zu einem Rewrite in Teilen, der sich nur nicht so nennt. Das ehrlich zu benennen ist besser, als es über Monate zu entdecken.

Lebt das Wissen noch. Gibt es Menschen, die erklären können, warum der Code so ist. Solange es sie gibt, ist ein Rewrite Verschwendung: Man wirft weg, was man noch fragen kann. Bei einer Codebasis ohne einen einzigen Träger dieses Wissens und ohne Dokumentation kehrt sich die Rechnung um, weil Archäologie teurer wird als Neubau.

Fundament oder Ausbau. Ist die Architektur veraltet oder nur ihre Oberfläche. Objective-C mit sauberen Modulgrenzen lässt sich schichtweise modernisieren. Eine zwei Jahre alte SwiftUI-App, in der die Geschäftslogik über die Views verteilt liegt, kann den härteren Eingriff verlangen als ein zehn Jahre altes UIKit-Projekt. Das Alter des Codes ist das schlechteste der gängigen Kriterien.

Der dritte Weg, den die Frage ausblendet

In der Praxis ist die Antwort meistens keine der beiden. Das Neue wächst im Alten, Modul für Modul, mit stabilen Grenzen zwischen den Welten. Ein Bereich wird herausgetrennt, neu gebaut, angeschlossen; der Rest läuft weiter und wird weiter ausgeliefert.

Der Vorteil ist nicht technischer Natur, sondern ein Risikoprofil. Jeder Schritt ist einzeln zu verantworten und einzeln zurückzunehmen. Es gibt keinen Zeitpunkt, an dem alles gleichzeitig neu ist und niemand mehr weiß, welche der hundert Änderungen den Fehler verursacht hat.

Was dabei fast immer unterschlagen wird, ist der Preis, und er ist erheblich.

Der Preis des dritten Weges

Zwei Paradigmen gleichzeitig, über lange Zeit. Das Team muss beide Welten im Kopf halten und bei jeder Aufgabe entscheiden, in welcher sie stattfindet. Neue Leute müssen beide lernen, nicht eine.

Die Brücken zwischen den Welten werden selbst zu Altlast. Adapter, die nur existieren, damit zwei Modelle miteinander sprechen, sind Code, den niemand haben wollte und den am Ende jemand pflegen muss.

Und der Fehlermodus ist kein technischer. Diese Strategie scheitert organisatorisch: Nach einem halben Jahr ist der Reiz verbraucht, die Migration steht bei vierzig Prozent, und dort bleibt sie. Eine halb migrierte Codebasis ist schlechter als beide sauberen Zustände, weil sie die Nachteile von beiden trägt und die Vorteile von keinem. Wer diesen Weg wählt, muss ihn zu Ende gehen können, und das ist eine Frage an die Organisation, nicht an die Architektur.

Warum der Rewrite trotzdem so beliebt ist

Die Ausfallquote von Neubauten ist bekannt, und sie hindert niemanden. Der Grund liegt nicht in der Technik.

Fremden Code zu lesen ist mühsam und langweilig. Neuen zu schreiben ist leicht und macht Freude. Das Ingenieurshirn rationalisiert dieses Vergnügen zuverlässig als technische Notwendigkeit. "Das schreibt man schneller neu" heißt in den meisten Fällen "ich habe keine Lust, mich einzuarbeiten", und wer es sagt, merkt den Unterschied selbst nicht.

Ich nehme mich davon nicht aus. Der Satz ist mir schon selbst zu leicht über die Lippen gegangen, und er klang jedes Mal nach einem Argument.

Wo der Rewrite gewinnt

Drei Fälle, in denen er ehrlich die bessere Wahl ist.

Ein Wechsel des Plattform-Paradigmas, der sich nicht schichtweise durchführen lässt, weil die neue Struktur die alte nicht aufnehmen kann. Dort erzeugt der schrittweise Weg nur Brücken, die später alle wieder verschwinden.

Eine Codebasis, die ein oder zwei Jahre alt ist. Dort ist noch wenig Wissen eingelagert, das verloren gehen könnte, und die Narben fehlen noch.

Und der Prototyp, der entgegen aller Absprachen in Produktion gelandet ist, den aber so wenige benutzen, dass eine Migration sich nicht rechnet. Neubau ist dort nicht die mutige, sondern die billige Entscheidung.

Drei Fragen statt einer Bewertung

Wer vor dieser Entscheidung steht, sollte aufhören, den Code zu bewerten, und anfangen, drei Fragen zu beantworten: Bekomme ich Tests hinein, ohne vorher umzubauen. Gibt es noch jemanden, der die Gründe kennt. Ist die Architektur veraltet oder nur ihre Oberfläche.

Aus diesen drei Antworten ergibt sich der Weg fast von selbst, und in den meisten Fällen ist es keiner der beiden, nach denen gefragt wurde. Wenn die Antworten unklar sind, ist das kein Grund zur Entscheidung, sondern der Anlass, sie sich vorher zu verschaffen. Wie man an sie herankommt, ohne eine fremde Codebasis von vorne bis hinten zu lesen, habe ich hier beschrieben: Fremden Code schnell lesen.