Es gibt drei Wege, eine Codebasis zu erben: Ihr Unternehmen hat zugekauft, Sie haben die technische Leitung übernommen, oder die Agentur, die das System gebaut hat, gibt es nicht mehr. In allen drei Fällen bekommen Sie ein System, eine Reihe von Erwartungen und etwa einen Monat, bevor jemand aus der Führung eine Einschätzung erwartet.
Die Versuchung ist groß, sofort Code zu lesen. Tun Sie es nicht. Code-Qualität gehört zu den am wenigsten aussagekräftigen Dingen, die Sie in der ersten Woche bewerten können, und sie verleitet am schnellsten zu einem unfairen Urteil. In dieser Reihenfolge gehen wir vor.
Eine Regel vorab: Ändern Sie in Woche eins nichts. Keine Abhängigkeit, keinen Konfigurationswert, kein composer update. Sie können noch nicht erkennen, was tragend ist, und ein von Ihnen verursachter Ausfall zerstört Ihre Glaubwürdigkeit, über die Ausfälle zu berichten, die Sie nicht verursacht haben.
Woche 1: Bekommen Sie es überhaupt zum Laufen?
Alles andere ist Spekulation, solange das System nicht auf einer Maschine läuft, die Sie kontrollieren.
- Bringen Sie aus einem sauberen Checkout eine lokale Umgebung zum Laufen und stoppen Sie die Zeit. Diese Zahl ist der beste einzelne Indikator dafür, wie teuer jede künftige Änderung wird. Zwei Stunden sind gesund; zwei Wochen sagen Ihnen bereits das meiste.
- Erfassen Sie die Umgebungen. Produktion, Staging und die zwei Server, die niemand erwähnt hat. Finden Sie sie über DNS und das Cloud-Konto, nicht durch Nachfragen.
- Klären Sie, was wo läuft — Webserver, Worker, Cron, Queues, geplante Reports, Webhook-Empfänger. Der undokumentierte Cron-Job ist die klassische Tretmine.
- Stellen Sie sicher, dass Sie die Zugänge haben. Domain-Registrar, DNS, Hosting, Cloud, Repositories, CI, Error-Tracking, Payment-Gateways, E-Mail-Versand. Fehlender Zugang ist ein kommerzielles Problem, das Sie an Tag zwei eskalieren, nicht in Woche vier.
- Prüfen Sie, ob die Backups existieren und sich einspielen lassen. Ungetestete Backups sind ein Gerücht. Spielen Sie eines in eine Wegwerf-Umgebung ein und sehen Sie es sich an.
- Finden Sie heraus, wer Bescheid weiß. Oft ist es eine einzige Person, manchmal in einem Unternehmen, das sie längst nicht mehr beschäftigt. Das ist Ihr vergänglichstes Gut — buchen Sie sofort Zeit mit ihr.
Woche 2: Risiko, nicht Qualität
Jetzt messen Sie die Gefährdung. Das sind die Befunde, die Entscheidungen verändern und Budgets freigeben.
- PHP-Version, je Umgebung, abgeglichen mit dem offiziellen Support-Zeitplan. Eine Version ohne Support ist der Befund, der alles andere in dieser Liste übertrifft.
- Alter und Schwachstellenstatus der Abhängigkeiten. Lassen Sie ein Audit gegen die Lock-Datei laufen. Zählen Sie, wie viele Major-Versionen das Framework zurückliegt — diese Zahl, nicht der Code-Stil, sagt Ihnen, was ein Upgrade kostet.
- Aufgegebene Abhängigkeiten. Pakete ohne Release seit Jahren oder Forks, die auf ein privates Repository zeigen. Jede davon ist ein Projekt, das Sie geerbt haben, ohne es zu wissen.
- Secrets im Repository. Durchsuchen Sie die gesamte Historie, nicht nur den aktuellen Stand. Nehmen Sie an, dass alles Gefundene kompromittiert ist.
- Wie Daten geschützt sind. Wo personenbezogene Daten liegen, wer sie lesen kann, was verschlüsselt ist und welche Pflichten Sie dafür haben.
- Ob das Deployment wiederholbar ist. Ein System, das ausgeliefert wird, indem jemand Dateien auf dem Server bearbeitet, hat keinen verlässlichen Rollback — und das prägt jede Risikobewertung danach.
Schreiben Sie Befunde als Risiken mit Eintrittswahrscheinlichkeit, Auswirkung und Behebungskosten — nie als Beschwerden über das vorherige Team. Das Publikum dieses Dokuments denkt kaufmännisch, und dieser Code ist schlecht ist nicht handlungsleitend, in 14 Monaten erhalten wir keine Sicherheitsupdates mehr dagegen schon.
Woche 3: Jetzt den Code lesen
Mit diesem Kontext wird die Bewertung des Codes nützlich statt urteilend. Achten Sie auf Struktur und Testbarkeit, nicht auf Stil.
- Führen Sie eine statische Analyse auf niedriger Stufe aus und halten Sie den Ausgangswert fest. Sie reparieren nichts, Sie messen. Entscheidend ist der Trend über das nächste Jahr.
- Prüfen Sie die Testabdeckung dort, wo es zählt — Checkout, Zahlung, Preisfindung, alles, was Geld berührt. Der Gesamtprozentsatz ist eine schwache Kennzahl; die Abdeckung der gefährlichen Pfade ist die echte.
- Finden Sie die Geschäftslogik. In einer gesunden Codebasis liegt sie an erkennbaren Stellen. In einer ungesunden verteilt sie sich über Controller, Templates und eine Stored Procedure, von der niemand wusste.
- Suchen Sie die God Objects — die Klasse, die jedes Feature berührt. Sie zeigt Ihnen, wo Änderungen am teuersten sind und woher der nächste Incident kommen wird.
- Lesen Sie die Git-Historie auf Änderungshäufigkeit. Die am häufigsten geänderten Dateien sind der Ort, an dem das Geschäft tatsächlich stattfindet — und an dem sich Investitionen am schnellsten auszahlen.
- Identifizieren Sie das Unantastbare. Jedes Legacy-System hat ein Modul, das niemand anfassen will. Finden Sie heraus, welches das ist und warum.
Der Bus-Faktor verdient einen eigenen Hinweis. Wenn nur eine Person die Bestellstrecke erklären kann und sonst niemand, ist das ein höheres Risiko als jeder Code Smell, den Sie finden werden. Die Gegenmaßnahme — Pairing, Dokumentation, eine zweite Person, die es wirklich versteht — muss sofort beginnen, nicht erst nach der Bewertung.
Woche 4: Bewerten und empfehlen
Bewerten Sie jede Dimension von 1 (gesund) bis 5 (kritisch) und lassen Sie die Summe die Empfehlung bestimmen, nicht Ihr Bauchgefühl.
- Sicherheit und Versionsaktualität — die einzige Dimension, die für sich allein eine Entscheidung erzwingen kann
- Zustand der Abhängigkeiten — wie weit zurück, wie viel aufgegeben
- Betreibbarkeit — können Sie deployen, ein Rollback machen, beobachten und wiederherstellen?
- Testbarkeit — könnten Sie die Preislogik ändern und wüssten, ob Sie sie kaputt gemacht haben?
- Verständlichkeit — wie lange dauert es, bis ein neuer Entwickler produktiv ist?
- Fachliche Passung — leistet es noch, was das Geschäft braucht, oder arbeitet es gegen die Roadmap?
Dann ordnen Sie ein:
- Überwiegend 1–2: warten und verbessern. Das System ist in Ordnung. Beheben Sie die konkreten Befunde und arbeiten Sie die Roadmap ab.
- Überwiegend 2–3: gezielt investieren. Ein finanziertes Sanierungsprogramm — Versions-Upgrade, Governance für Abhängigkeiten, Tests auf den geldführenden Pfaden — parallel zur normalen Auslieferung.
- Überwiegend 3–4: schrittweise Ablösung. Strangler Fig — das System Route für Route ersetzen, während es weiterläuft. Dieses Muster beschreiben wir ausführlich in Migration eines Legacy-PHP-Monolithen zu Laravel.
- Überwiegend 4–5, oder fachliche Passung bei 5: neu bauen. Selten, und es sollte sich unvermeidlich anfühlen, nicht verlockend. Ein allein mit Code-Qualität begründeter Neubau wird in der Regel bereut.
Misstrauen Sie Ihrem eigenen Drang, neu zu bauen. Fast jeder Entwickler, der eine fremde Codebasis übernimmt, will das. Fast keines der daraus entstehenden Projekte liefert das Versprochene in der versprochenen Zeit. Verlangen Sie, dass die Bewertung es rechtfertigt.
Was Sie übergeben
Das Ergebnis ist ein Dokument, das auch jemand ohne technischen Hintergrund lesen kann. Es enthält:
- Eine einseitige Zusammenfassung mit der Empfehlung und den drei Gründen, die sie tragen
- Ein Risikoregister — jeder Befund mit Eintrittswahrscheinlichkeit, Auswirkung und Behebungskosten, nach Dringlichkeit sortiert
- Den Stand von Versionen und Abhängigkeiten, mit den Daten, an denen der Support endet
- Einen 90-Tage-Plan für das, was nicht warten sollte, mit Kosten hinterlegt
- Die Lücken bei Zugängen und Eigentumsrechten, die meist kommerzieller statt technischer Natur sind
- Eine ehrliche Aussage darüber, was Sie nicht bewerten konnten und was nötig wäre, um es herauszufinden
Der letzte Punkt unterscheidet eine professionelle Bewertung von einer selbstbewussten. Ein Monat reicht nicht, um alles zu wissen, und das zu sagen ist glaubwürdiger, als das Gegenteil vorzugeben.
Wir führen diese Bewertung für Kunden über unsere individuelle PHP-Entwicklung und unser PHP-Entwicklungsteam durch — oft bevor eine Übernahme abgeschlossen ist, gelegentlich nachdem eine Agenturbeziehung schlecht geendet hat. Die verwandte Frage, ob die Sprache selbst das Problem ist, behandeln wir in Ist PHP noch die richtige Wahl für E-Commerce.
Häufige Fragen
Wie lange sollte die Bewertung von Legacy-Code dauern?
Vier Wochen mit Teilzeitaufwand reichen bei den meisten mittelgroßen Systemen für eine belastbare Empfehlung. Unter zwei Wochen entsteht eine Meinung statt einer Bewertung; über sechs Wochen versucht meist jemand zu reparieren, statt zu messen.
Was ist als Erstes zu prüfen?
Ob Sie das System aus einem sauberen Checkout lokal zum Laufen bringen — und wie lange das dauert. Diese eine Zahl sagt die Kosten jeder künftigen Änderung besser voraus als jede Metrik zur Code-Qualität, und sie liegt schon am ersten Tag vor.
Sollten wir ein geerbtes PHP-System neu bauen oder refactoren?
Fast immer refactoren oder schrittweise ersetzen. Neu bauen nur dann, wenn die fachliche Passung tatsächlich gescheitert ist — das System leistet nicht mehr, was das Geschäft braucht — und nicht, weil der Code unangenehm ist. Ein allein mit Code-Qualität begründeter Neubau wird meist bereut.
Was ist das größte Risiko in einer geerbten Codebasis?
Meist nicht der Code. Es ist eine PHP-Version ohne Support, ein fehlender Zugang zu einer Domain oder einem Cloud-Konto, sind ungetestete Backups oder eine einzige Person, die als Einzige ein kritisches Subsystem versteht. Das sind die Befunde, die Entscheidungen verändern.
Wie präsentieren wir die Befunde nicht-technischen Stakeholdern?
Als Risikoregister: jeder Befund mit Eintrittswahrscheinlichkeit, geschäftlicher Auswirkung und Behebungskosten, nach Dringlichkeit sortiert. Nie als Kritik am vorherigen Team — das wirkt wie Positionierung und macht es leichter, das ganze Dokument abzutun.
Holen Sie eine zweite Meinung ein
Wenn Sie etwas geerbt haben und eine unabhängige Einschätzung brauchen, bevor Sie ein Budget dafür freigeben: Wir führen die Bewertung durch und übergeben Ihnen das Dokument. Sprechen Sie mit unserem Team; wir antworten innerhalb eines Werktags.