Refactoring oder neu schreiben? So entscheiden Sie

Refactoring ist eine Änderung am Code, die seine Struktur verbessert, ohne zu ändern, was die Software tut. Refactoring oder Neuschreiben ist eine Entscheidung darüber, wie viele Monate Roadmap Sie anhalten wollen. Meist gewinnt Refactoring in kleinen Schritten, denn das Produkt verdient währenddessen weiter Geld.

Neu schreiben lohnt sich in drei Fällen: Der Code tut das Falsche, er gehört Ihnen nicht, oder er läuft auf einer Technologie ohne Support. Unten finden Sie eine Entscheidungstabelle und ein Vorgehen, ohne die Roadmap zu stoppen.

KI schreibt heute unseren gesamten Code, für das Ergebnis haftet ein Senior. Filip hat davor jahrelang ein SaaS entwickelt, das täglich 60.000+ Menschen nutzten. Es wurde nie von Grund auf neu geschrieben. Es änderte sich in kleinen, reviewten Schritten, direkt im laufenden Produkt.

Warum ist ein großes Neuschreiben fast immer teurer, als es aussieht?

Neuschreiben wirkt sauber, weil neuer Code noch keine Geschichte hat. Genau diese Geschichte brauchen Sie aber. Hinter jeder seltsamen Bedingung im alten Code steckt meist eine Kundenbeschwerde.

Die häufigsten Gründe, warum Neuschreiben teuer wird:

Wann Refactoring, wann neu schreiben: eine Entscheidungstabelle

Achten Sie auf die letzte Zeile. „Das versteht keiner“ ist das häufigste Argument fürs Neuschreiben. Und das schlechteste. Ein neues Team, das den alten Code nicht versteht, schreibt ihn ohne die Korrekturen neu, die darin stecken.

Neu schreiben ist auch der einfachste Upsell. Beim Audit des Produkts eines Gründers lag ein Monorepo und ein Backend-Rewrite in TypeScript nahe. Wir haben das Gegenteil geschrieben: Die Repositories sind in Ordnung, TypeScript Modul für Modul einführen und mit Login und Berechtigungen beginnen.

Wie refaktoriert man, ohne die Roadmap zu stoppen?

KI übernimmt hier das Langsame und Langweilige. Tests für bestehendes Verhalten, Code verschieben, umbenennen. Ein Senior entscheidet, was sich ändert und in welcher Reihenfolge. Welche Regeln wir der KI dafür geben, beschreiben wir in Regeln für KI-Code im Team.

Ohne Tests und Review lässt KI Ihre technischen Schulden nur schneller wachsen. Deshalb sagen wir, ein Agent ist Modell plus Rahmen. Der Rahmen ist das, was eine schlechte Änderung stoppt.

Wann ist Neuschreiben die richtige Wahl?

Wenn Ihnen der Code nicht gehört. Gehört das alte System nicht Ihnen, gibt es nichts zu refaktorieren: Ein neues wird gebaut und die Daten ziehen um.

Auch beim Neuschreiben gilt dieselbe Reihenfolge. Zuerst die Daten und ein Verständnis dafür, was das System wirklich tut. Dann Bildschirm für Bildschirm, nicht alles an einem Tag.

Gehen Sie vor der Entscheidung sechs Punkte durch. Haken Sie ab, was für Ihr System gilt:

Am schwersten wiegt der vierte Punkt. Tut der Code das Richtige, nur schlecht, refaktorieren Sie.

Wann wir es nicht empfehlen

• Sie haben einen Senior, der das System kennt und Zeit dafür hat. Refaktorieren Sie selbst. Die Tabelle oben reicht.
• Das System wird in ein paar Monaten abgeschaltet. Investieren Sie nicht in Code, der endet. Investieren Sie in den Datenumzug.

Wollen Sie mit jemandem entscheiden, der das täglich macht?

Ein Senior steigt ab dem ersten Tag in Ihr Repository und Ihre Pull Requests ein. Erst Tests, dann Änderungen in kleinen Schritten, und die Roadmap läuft weiter. So arbeiten wir als externer Entwickler für Produktteams.

Schreiben Sie uns, welcher Teil des Codes Sie bremst. Wir melden uns innerhalb von zwei Arbeitstagen und wählen gemeinsam, was wir zuerst lösen.

Wenn Sie lieber zuerst sprechen möchten, buchen Sie ein 15-Minuten-Meeting mit Filip.

Welchen Teil Ihres Codes würden Sie am liebsten wegwerfen, und warum?

Häufige Fragen

Wann Refactoring und wann Code neu schreiben?

Refactoring, wenn der Code das Richtige tut, sich aber schwer ändern lässt. Neu schreiben, wenn er das Falsche tut, der Code Ihnen nicht gehört oder die Technologie keinen Support mehr hat. Auch dann in Teilen, nicht auf einmal.

Kann man ohne Tests refaktorieren?

Man kann, aber es ist ein Glücksspiel. Schreiben Sie zuerst Tests für das heutige Verhalten, Fehler eingeschlossen. Erst dann ändern Sie den Code. Ohne Tests erfahren Sie vom Fehler durch einen Kunden.

Wie lange dauert ein Refactoring?

Es hat kein festes Ende, und das ist in Ordnung. Es passiert laufend in normalen Pull Requests, dort, wo Sie ohnehin arbeiten. Ein eigenes Refactoring-Projekt über Monate wird meist nie fertig.

Hilft KI beim Refactoring?

Ja, beim Schreiben von Tests, beim Verschieben von Code und beim Umbenennen. Was sich ändert und in welcher Reihenfolge, entscheidet ein Senior. Ohne Tests und Review macht KI Fehler nur schneller.