Es ist Montagmorgen. Ich öffne eine Codebasis, die ich noch nicht kenne. Keine Dokumentation, kein Onboarding, kein Ansprechpartner mehr im Unternehmen – der Kollege, der das System gebaut hat, ist vor drei Jahren gegangen. Was bleibt, ist der Code selbst: 80.000 Zeilen PHP, verteilt über Ordner mit Namen wie neu2, neu2_final und neu2_final_WIRKLICH_FINAL.

In diesem Moment fühle ich mich nicht wie ein Softwareentwickler. Ich fühle mich wie ein Archäologe.

Die Ausgrabungsstätte öffnen

Ein Archäologe betritt eine Ausgrabungsstätte nicht mit dem Bagger. Er beginnt mit Beobachtung: Was liegt oben? Was ist Ablagerung, was ist Substanz? Welche Schichten gehören zusammen, welche wurden nachträglich hinzugefügt?

In Legacy-Code ist das nicht anders. Die erste Stunde gehört nicht dem Refactoring, sondern dem Lesen. Welche Dateien werden tatsächlich aufgerufen? Welche Funktionen tragen Namen, die lügen? Wo liegt die eigentliche Logik – und wo liegt nur Sediment aus Jahren von Schnellschüssen?

Der Unterschied zum Archäologen: Ich darf den Pinsel auch mal weglegen. Aber der Impuls, sofort zu graben, ist genauso gefährlich.

Artefakte interpretieren

Letzte Woche bin ich auf diesen Kommentar gestoßen:

// NICHT ANFASSEN – Olaf weiß warum

Olaf ist seit 2019 nicht mehr im Unternehmen. Niemand weiß, warum. Und der betreffende Codeblock macht etwas, das auf den ersten Blick wie ein Off-by-One-Error aussieht – aber auf den zweiten Blick womöglich ein absichtlicher Workaround für ein Datenbankproblem ist, das schon längst behoben wurde. Oder auch nicht.

Ein Archäologe kennt dieses Gefühl. Das Artefakt liegt vor ihm, der Kontext ist verloren, und er muss entscheiden: vorsichtig freilegen oder liegen lassen. Beides kann richtig sein. Beides erfordert Urteilsvermögen.

Legacy-Code lügt nie. Er erzählt nur eine Geschichte, für die man den Kontext kennen muss.

Schichten lesen lernen

Erfahrene Archäologen können aus dem Boden lesen, was wann passiert ist. Farbe, Dichte, Einschlüsse – jede Schicht hat ihre eigene Signatur.

In Legacy-Code sind diese Schichten genauso sichtbar, wenn man weiß, wonach man sucht:

  • Die Funktion mit 400 Zeilen, die alle fünf Jahre um einen neuen if-Block erweitert wurde.
  • Der Datenbankzugriff per mysql_query(), der in eine PDO-Schicht eingebettet ist, die wiederum von Doctrine ummantelt wurde – drei Generationen Technologie in einer Datei.
  • Variablennamen auf Englisch, dann auf Deutsch, dann wieder auf Englisch – an der Stelle, wo das Team gewechselt hat.

Diese Schichten zu lesen ist eine Fähigkeit. Sie entsteht nicht durch Lesen von Clean-Code-Büchern, sondern durch Zeit in echten Systemen.

Das Wichtigste: Nichts zerstören, was man noch nicht versteht

Die goldene Regel der Archäologie lautet: Einmal zerstört, für immer verloren. Kein zweiter Versuch, keine Rekonstruktion aus dem Nichts.

In Legacy-Systemen gilt dasselbe – nur dass der Bagger hier ein voreiliges Refactoring heißt. Code, der seltsam aussieht, ist nicht automatisch falsch. Manchmal ist er die einzige Dokumentation eines Randfalls, den sich niemand mehr erinnert. Manchmal ist er der Grund, warum das System seit acht Jahren ohne Produktionsausfall läuft.

Wer zu früh umschreibt, riskiert nicht nur Fehler. Er riskiert, das institutionelle Gedächtnis zu löschen, das im Code steckt.

Fazit

Legacy-Entwicklung ist keine minderwertige Form von Softwareentwicklung. Sie erfordert Geduld, Kontextsensitivität und die Fähigkeit, aus Fragmenten ein Bild zu rekonstruieren – Eigenschaften, die in Greenfield-Projekten selten gebraucht werden und deshalb selten trainiert werden.