Es gibt einen Satz, der in fast jedem Meeting über eine in die Jahre gekommene Laravel-Anwendung fällt: "Am besten bauen wir das komplett neu." Ich verstehe den Reflex. Wenn eine Änderung im Checkout drei Stellen im Code betrifft, die niemand mehr überblickt, fühlt sich der Neustart wie Befreiung an. Nur ist er in der Regel die teuerste und riskanteste Option, die Sie wählen können.
Denn ein System, das seit Jahren Rechnungen schreibt, Bestellungen abwickelt und Kunden bedient, ist kein Müll. Es ist der Beweis, dass die Fachlogik funktioniert. Das Problem ist fast nie die Logik selbst, sondern der Code drumherum: die 800-Zeilen-Controller, die Business-Regeln in Blade-Templates, die direkten Datenbankzugriffe quer durch die App. Genau da setzt gutes Laravel Refactoring an. Sie behalten das erprobte Verhalten und verbessern die Struktur, ohne bei null anzufangen.
Warum Laravel Refactoring fast immer besser ist als ein Rewrite
Ein Rewrite bedeutet, Jahre an implizitem Wissen neu zu erfinden: jeden Sonderfall, jede stille Geschäftsregel, jeden Bugfix, den mal jemand nachts eingebaut hat. Dieses Wissen steht nirgends dokumentiert, es lebt im Code. Beim Neubau geht es verloren, und Sie merken es erst, wenn der erste Kunde anruft, weil sein Rabatt plötzlich nicht mehr greift.
Refactoring dagegen ist definitionsgemäß eine Änderung der internen Struktur, ohne das nach außen sichtbare Verhalten zu verändern. Sie liefern die ganze Zeit ein lauffähiges Produkt aus. Es gibt keinen Big-Bang-Termin, an dem alles gleichzeitig funktionieren muss. Und Sie können jederzeit aufhören, wenn das Ergebnis gut genug ist.
Woran erkenne ich, ob mein Laravel-Projekt refactoring-fähig ist?
Ein Laravel-Projekt ist praktisch immer refactoring-fähig, solange es sich lokal starten und mit einer aktuellen PHP-Version zum Laufen bringen lässt. Der schwierige Fall ist nicht altes Laravel, sondern gar kein Framework.
Prüfen Sie vor dem Start diese Punkte ehrlich:
- Läuft es unter PHP 8.x? Wenn Sie noch auf 7.x festhängen, ist das der erste Schritt, nicht das Refactoring.
- Gibt es überhaupt Tests? Oft lautet die Antwort "fast keine". Das ist kein Ausschlusskriterium, sondern die erste Aufgabe.
- Wie weit ist die Framework-Version weg von der aktuellen LTS? Ein Sprung über mehrere Major-Versionen will geplant sein.
- Läuft die Anwendung in Produktion und verdient Geld? Falls ja, ist das ein starkes Argument gegen den Neubau, nicht dafür.
Wie fange ich mit dem Refactoring an, ohne etwas kaputt zu machen?
Der erste Schritt ist nie Code umschreiben, sondern ein Sicherheitsnetz spannen. Ohne Tests ist jede Änderung ein Blindflug. Und die guten Nachrichten: Sie brauchen keine 90 Prozent Coverage, um sicher anzufangen.
Beginnen Sie mit Characterization Tests auf hoher Ebene. Das sind Tests, die nicht prüfen, was der Code tun sollte, sondern festhalten, was er tatsächlich tut. In Laravel bieten sich HTTP-Feature-Tests an: Sie rufen eine Route auf und schreiben die aktuelle Antwort als Erwartung fest.
Sie testen nicht die Idealwelt, sondern die reale. Wenn ein Bug seit Jahren mitläuft und Kunden sich darauf verlassen haben, ist er Teil des Verhaltens.
Sobald die wichtigsten Geschäftsvorfälle, etwa Bestellung, Login, Rechnung, durch solche Tests abgesichert sind, haben Sie ein Netz. Jetzt können Sie umbauen und sehen sofort, wenn sich Verhalten verschiebt.
Fette Controller und Models: wo Sie zuerst aufräumen sollten
Die typischen Schmerzpunkte in Legacy-Laravel sind fast immer dieselben. Gehen Sie sie in dieser Reihenfolge an, weil jeder Schritt den nächsten leichter macht:
- Business-Logik aus Controllern ziehen. Ein Controller soll eine Anfrage entgegennehmen, delegieren und eine Antwort zurückgeben. Berechnet er Preise oder verschickt E-Mails, gehört das in eine Service- oder Action-Klasse. Das lässt sich Methode für Methode extrahieren, abgesichert durch Ihre Feature-Tests.
- Logik aus den Models holen. Eloquent-Models mit tausend Zeilen und Dutzenden Scopes sind schwer testbar. Fachliche Berechnungen wandern in dedizierte Klassen, das Model bleibt für Persistenz und Beziehungen zuständig.
- Direkte DB-Zugriffe kapseln. Verstreute
DB::table(...)-Aufrufe und roher SQL-String-Bau sind nicht nur schwer wartbar, sondern oft auch ein Einfallstor für SQL-Injection. Führen Sie diese Zugriffe zusammen und nutzen Sie durchgängig parametrisierte Queries oder den Query Builder.
Wichtig ist die Reihenfolge des Vorgehens innerhalb jeder Änderung: erst absichern, dann umbauen, dann committen. Kleine Commits, jeder für sich lauffähig und deploybar.
Versions-Upgrades und Security beim Laravel Refactoring
Ein Framework-Upgrade und strukturelles Refactoring sollten Sie nach Möglichkeit trennen. Wenn Sie gleichzeitig die Laravel-Version anheben und Controller umbauen, wissen Sie bei einem Fehler nicht, welche Änderung schuld war.
Für den Sprung über mehrere Versionen ist Laravel Shift ein etabliertes Werkzeug, das viele mechanische Änderungen automatisiert. Für Code-Qualität lohnen sich statische Analyse mit PHPStan oder Larastan und automatisierte Umbauten mit Rector. Diese Tools ersetzen kein Denken, aber sie erledigen die stumpfe Fleißarbeit zuverlässig und ohne Tippfehler.
Nutzen Sie das Refactoring auch, um zwei Sicherheitsthemen aufzuräumen, die in alten Projekten fast garantiert schlummern: veraltete Abhängigkeiten mit bekannten Lücken (prüfbar über composer audit) und fehlende Autorisierungsprüfungen, bei denen ein eingeloggter Nutzer auf fremde Daten zugreifen kann. Beides fällt beim strukturierten Durchgehen des Codes ohnehin auf.
Der ehrliche Praxis-Tipp zum Schluss
Widerstehen Sie der Versuchung, "bei der Gelegenheit" alles gleichzeitig zu ändern. Die häufigste Art, ein Refactoring gegen die Wand zu fahren, ist der Umbau, der immer größer wird und nie deploybar ist. Definieren Sie stattdessen einen kleinen, geschlossenen Schritt, sichern Sie ihn ab, bauen Sie ihn um, deployen Sie ihn. Dann den nächsten. Ein Legacy-System zu modernisieren ist kein Sprint, sondern eine Reihe kleiner, sicherer Schritte, bei denen das System nie stehenbleibt.
Wenn Sie an genau diesem Punkt stehen und einen erfahrenen Blick von außen auf Ihre Laravel-Anwendung möchten, ist das die Art von Arbeit, bei der ich mit LegacyWerk unterstütze.
