Irgendwann klingelt das Telefon. Ein System läuft seit acht Jahren in Produktion, der ursprüngliche Entwickler ist längst weg, und jetzt sollen Sie es übernehmen. Es gibt keine Dokumentation, keine Tests, und der einzige, der sich noch halbwegs auskennt, geht in drei Wochen in Rente. Das ist der Normalfall, nicht die Ausnahme.
Die erste Reaktion vieler Entwickler ist Ablehnung: "Das ist Müll, das schreiben wir neu." Diese Einschätzung ist fast immer falsch. Ein System, das seit Jahren zuverlässig Rechnungen schreibt oder Bestellungen verarbeitet, ist der lebende Beweis, dass die Fachlogik funktioniert. Das Problem ist selten die Logik selbst, sondern der Code, der sich über die Jahre darum herum angesammelt hat. Wer Legacy Code übernehmen will, muss diesen Unterschied verstehen, bevor er die erste Zeile anfasst.
Warum Neuentwicklung fast immer die falsche Antwort ist
Eine Neuentwicklung wirkt sauber und verlockend. In der Praxis ist sie meist die teuerste und riskanteste Option. Der Grund: In einem gewachsenen System steckt Wissen, das nirgends aufgeschrieben ist. Jedes seltsame if ist eine Regel, die irgendein Kunde vor Jahren gefordert hat. Jeder scheinbar überflüssige Sonderfall behandelt einen realen Geschäftsvorfall.
Wenn Sie neu bauen, replizieren Sie nicht nur die schöne Hauptfunktion, sondern auch tausend unsichtbare Randfälle. Die meisten davon entdecken Sie erst, wenn der neue Code live geht und Kunden sich beschweren. Deshalb gilt: Bevor Sie über Neuentwicklung nachdenken, müssen Sie das bestehende System erst verstanden haben. Und wenn Sie es einmal verstanden haben, ist die Neuentwicklung fast immer überflüssig.
Wie Sie Legacy Code übernehmen, ohne im Chaos zu ertrinken
Fassen Sie in den ersten Tagen nichts an. Der stärkste Impuls beim Onboarding ist, sofort etwas "aufzuräumen". Widerstehen Sie ihm. In den ersten Wochen ist Ihr Job Beobachtung, nicht Veränderung. Sie können ein System nicht sicher ändern, das Sie noch nicht kennen.
Verschaffen Sie sich stattdessen strukturiert einen Überblick. Diese Schritte haben sich bewährt, wenn Sie fremden Legacy Code übernehmen:
- Das System zum Laufen bringen. Lokal, in Docker, mit einer Kopie der Daten. Solange Sie es nicht selbst starten und durchklicken können, arbeiten Sie im Blindflug.
- Die Einstiegspunkte finden. Wo kommen Requests rein? Cronjobs, Webhooks, CLI-Kommandos, Message-Queues. Diese Liste ist Ihre Landkarte der Außengrenzen.
- Den Datenfluss nachvollziehen. Der ehrlichste Teil jeder Anwendung ist die Datenbank. Ein
SHOW CREATE TABLEund ein Blick auf die Fremdschlüssel verraten oft mehr über die Fachlogik als 5.000 Zeilen Controller. - Die Deployment-Realität verstehen. Wie kommt Code in Produktion? Per Git, per FTP-Upload, per Hand? Das entscheidet, wie riskant jede spätere Änderung ist.
Warum die Datenbank Ihr bester Zeuge ist
Code lügt, Kommentare veralten, aber die Datenbank trägt die Spuren dessen, was das System wirklich tut. Schauen Sie sich an, welche Tabellen viele Datensätze haben und welche leer sind. Leere Tabellen sind oft verlassene Features. Volle Tabellen mit aktuellen Timestamps zeigen Ihnen den heißen Kern der Anwendung, den Sie zuerst verstehen müssen.
Welche ersten Änderungen sicher sind
Irgendwann müssen Sie eingreifen. Die Frage ist, womit Sie anfangen, ohne etwas kaputtzumachen. Die Antwort: mit Dingen, die das Verhalten des Systems nicht verändern, aber Ihre Sicherheit erhöhen.
- Versionskontrolle sicherstellen. Falls der Code nicht in Git liegt, ist das Ihr allererster Schritt. Ohne Historie ist jede Änderung ein Vabanquespiel.
- Charakterisierungs-Tests schreiben. Das sind keine Tests, die prüfen, ob der Code "richtig" arbeitet. Sie halten fest, was er aktuell tut, inklusive Bugs. Damit merken Sie sofort, wenn eine spätere Änderung ungewolltes Verhalten auslöst.
- Fehlermeldungen sichtbar machen. Oft laufen Legacy-Systeme mit unterdrückten Warnings und einem
@vor jedem riskanten Aufruf. Aktivieren Sie strukturiertes Logging, bevor Sie irgendetwas anderes tun. - Offensichtliche Sicherheitslücken prüfen. SQL-Injection durch String-Konkatenation, Passwörter im Klartext, veraltete PHP-Versionen ohne Sicherheitsupdates. Solche Funde haben Priorität, weil sie ein akutes Risiko sind, kein Schönheitsfehler.
Die goldene Regel: Trennen Sie das Verstehen vom Verändern. Erst wenn Charakterisierungs-Tests ein Verhalten absichern, ist es sicher, dieses Verhalten anzufassen.
Wie Sie mit fehlender Dokumentation umgehen
Sie werden fast nie eine brauchbare Dokumentation vorfinden. Das ist kein Grund zur Panik, sondern eine Chance, von Anfang an eine zu erstellen. Führen Sie ein einfaches Markdown-Dokument, in das Sie jede Erkenntnis eintragen: "Diese Funktion sieht ungenutzt aus, wird aber vom nächtlichen Cronjob X aufgerufen." Nach vier Wochen haben Sie die Dokumentation, die niemand vor Ihnen geschrieben hat.
Reden Sie außerdem mit den Menschen, die das System benutzen. Die Buchhaltung weiß oft besser, was das Programm tun soll, als jeder Kommentar im Code. Fachliches Wissen sitzt bei den Anwendern, nicht in der Codebasis.
Wann ist ein Legacy-System wirklich am Ende?
Es gibt Fälle, in denen Ablösung sinnvoll ist: wenn die PHP-Version keine Sicherheitsupdates mehr bekommt und ein Upgrade unmöglich ist, oder wenn eine zentrale Abhängigkeit endgültig eingestellt wurde. Aber selbst dann ist die richtige Strategie meist eine schrittweise Migration, kein Big-Bang-Rewrite. Sie ersetzen einzelne Teile hinter einer stabilen Fassade, während das alte System weiterläuft. Das Muster dahinter ist der Strangler-Fig-Ansatz, und es hält das Risiko in jeder Phase klein.
Ein ehrlicher Praxis-Tipp zum Schluss
Der größte Fehler beim Übernehmen von Legacy Code ist der Respektverlust vor dem, was da schon funktioniert. Behandeln Sie den alten Code nicht als Feind, sondern als Kollegen, der schlecht dokumentiert ist, aber jahrelang seinen Job gemacht hat. Ihre Aufgabe in den ersten Wochen ist Zuhören, nicht Umbauen. Wer diese Reihenfolge einhält, spart sich später die teuren Überraschungen.
Wenn Sie vor genau so einer Übernahme stehen und einen zweiten, erfahrenen Blick auf ein gewachsenes PHP-System brauchen, unterstützt LegacyWerk bei genau diesen Situationen.
