Du hast ein neues Projekt übernommen, aber es ist kein strahlend neuer Code, sondern ein Dickicht aus Legacy Code? Keine Panik, das kennen wir alle. Dieser Guide zeigt dir, wie du die Codebase übernehmen kannst, ohne im Chaos zu versinken und die ersten Schritte beim Refactoring erfolgreich meisterst.
Die erste Woche: Orientierung statt Aktionismus
Die Versuchung ist groß, sofort Änderungen vorzunehmen, wenn du auf ein neues Projekt triffst – besonders, wenn der Code nicht deinen Vorstellungen entspricht. Widerstehe diesem Drang! Deine erste Woche ist dem Verständnis gewidmet, nicht dem Verändern. Stell dir vor, du bist ein Archäologe, der eine unbekannte Ruine betritt: Du würdest auch nicht sofort anfangen, Wände einzureißen, sondern erst einmal das Gelände kartieren.
Was du tun solltest:
- Zuhören: Sprich mit den Stakeholdern. Was sind die größten Schmerzpunkte? Wo liegen die kritischsten Funktionen? Gibt es ehemalige Entwickler, die dir Einblicke geben können? Oft offenbaren diese Gespräche, welche Bereiche stabil sind und welche tickende Zeitbomben. Bei uns im SaaS-Bereich haben wir gelernt, dass die Kunden oft genau wissen, wo der Schuh drückt, auch wenn sie den Code nicht kennen.
- Dokumentation suchen: Gibt es Readmes, Architektur-Diagramme, Wikis? Selbst veraltete Doku kann Anhaltspunkte liefern. Wenn nichts existiert, ist das deine erste Erkenntnis: Du musst selbst eine mentale Karte erstellen.
- Code lesen, aber nicht bewerten: Lies den Code abschnittsweise. Nutze deine IDE, um Call-Graphen zu verstehen, Definitionen zu finden und Implementierungen nachzuvollziehen. Gehe durch die Git-Historie – wer hat wann was geändert? Das gibt dir oft Hinweise auf Problembereiche oder Hotspots. Bei Agenturprojekten zeigt die Git-Historie oft, wie schnell sich Anforderungen geändert haben und welche Bereiche daher am chaotischsten sind.
- Das System lokal zum Laufen bringen: Das mag trivial klingen, ist es aber oft nicht. Eine funktionierende lokale Entwicklungsumgebung ist Gold wert, um den Code interaktiv zu erkunden und später Charakterisierungs-Tests zu schreiben.
Dein Ziel ist es, ein Gefühl für die Architektur zu bekommen, die Hauptdatenflüsse zu identifizieren und die wichtigsten Geschäftsregeln zu verstehen. Ohne diese Basis wird jede Änderung zum Blindflug.
Charakterisierungs-Tests: Dein Sicherheitsnetz
Du kannst keinen Refactoring-Schritt machen, ohne zu wissen, dass du nichts kaputt machst. Gerade bei Legacy Code, der oft keine oder nur lückenhafte Tests hat, ist das eine riesige Herausforderung. Hier kommen Charakterisierungs-Tests ins Spiel.
Was sind Charakterisierungs-Tests?
Im Gegensatz zu klassischen Unit-Tests, die das erwünschte Verhalten eines Codes prüfen, beschreiben Charakterisierungs-Tests das aktuelle Verhalten. Du schreibst sie, um zu dokumentieren, was der Code gerade tut, selbst wenn das Verhalten fehlerhaft oder unerwartet ist. Sie geben dir ein Sicherheitsnetz: Solange deine Charakterisierungs-Tests grün bleiben, hast du das Verhalten des Systems nicht unbeabsichtigt geändert.
Wie gehst du vor?
- Identifiziere kritische Pfade: Wo liegt die Kernlogik? Welche Bereiche sind besonders fehleranfällig oder wichtig für das Geschäft? Oft sind das die Stellen, die du früher oder später anfassen musst.
- Schreibe Tests von außen nach innen: Beginne mit Integrationstests oder sogar End-to-End-Tests, die das gesamte System oder große Teile davon abdecken. Das ist oft einfacher, als einzelne, tief verschachtelte Funktionen zu testen. Für eine alte E-Commerce-Plattform könnte ein Charakterisierungs-Test zum Beispiel einen Warenkorb-Checkout simulieren und prüfen, ob der finale Preis korrekt ist und die Bestellung angelegt wird.
- Fokus auf Input und Output: Gib dem System bestimmte Inputs und prüfe, welche Outputs es liefert. Es geht nicht darum, den Code zu mocken oder zu stubben, sondern sein Verhalten unter realen Bedingungen zu erfassen.
- Kleine Schritte: Du musst nicht die gesamte
Codebaseauf einmal testen. Konzentriere dich auf die Bereiche, die du in nächster Zeit ändern wirst oder die als besonders riskant gelten. Jede Abdeckung hilft dir, Vertrauen in den Code aufzubauen.
Diese Tests geben dir die nötige Sicherheit, um später kleine Refactoring-Schritte zu wagen, ohne Angst haben zu müssen, unbeabsichtigt etwas zu zerstören. Sie sind dein wichtigster Verbündeter im Kampf gegen den Legacy Code.
Wo NICHT anfassen: Die gefährlichen Zonen
Es gibt Bereiche in jeder Legacy Codebase, die du am Anfang meiden solltest wie der Teufel das Weihwasser. Diese Zonen sind oft undurchsichtig, schlecht getestet und bergen ein hohes Risiko für unerwartete Nebenwirkungen. Wenn du nicht absolut sicher bist, was du tust, halte dich fern.
Typische No-Go-Areas:
- Bereiche ohne jegliche Tests: Das ist der offensichtlichste Punkt. Wenn es keine Charakterisierungs-Tests gibt, die das Verhalten absichern, ist jede Änderung ein Schuss ins Blaue. Das kann ein altes, komplexes Reporting-Modul sein, das nur einmal im Monat läuft und dessen Logik niemand mehr vollständig versteht.
- **Der