Code Reviews in Legacy-Projekten sind heikel. Der Code, über den geredet wird, wurde oft von denselben Menschen geschrieben, die jetzt im Review sitzen. Wer einen Kommentar zu einer Funktion schreibt, die vor acht Jahren entstanden ist, kommentiert damit auch eine Entscheidung – und hinter jeder Entscheidung steckt eine Person. Das sollte man nicht vergessen.

Der Unterschied zwischen Review und Schuldzuweisung

Ein Code Review, das sich anfühlt wie eine Prüfung, macht etwas kaputt, das schwer zu reparieren ist: die Bereitschaft, Code offen zu teilen. Wenn Entwickler Angst haben, auf Fehler aus der Vergangenheit hingewiesen zu werden, schreiben sie keinen offeneren Code – sie schreiben weniger nachvollziehbaren. Das Gegenteil von dem, was man will. Ein Review ist kein Urteil über den Entwickler. Es ist ein Gespräch über Code.

Drei Prinzipien, die ich in Legacy-Reviews anwende

1. Historischen Kontext annehmen

Wenn ich auf Code stoße, der mir seltsam vorkommt, frage ich erst. Nicht kommentiere – frage. "Warum ist das so gelöst?" ist ein besserer Einstieg als "Das sollte man anders machen." In vielen Fällen gibt es einen Grund, den ich nicht kenne: eine damalige technische Einschränkung, eine Kundenanforderung, eine Abhängigkeit, die nicht mehr sichtbar ist. Manchmal gibt es keinen guten Grund – aber dann ergibt sich das aus dem Gespräch, ohne dass jemand das Gesicht verliert.

2. Nur das reviewen, was geändert wurde

Das ist wichtiger als es klingt. In einem Legacy-Projekt sieht jeder Diff wie ein Kompromiss aus, weil er im Kontext von Code steht, den man eigentlich auch anfassen müsste. Wer im Review auf alles zeigt, was nicht zum aktuellen Ticket gehört, überwältigt den Entwickler und lenkt vom eigentlichen Ziel ab. Die Regel: Ich kommentiere nur, was in diesem Pull Request geändert wurde. Alles andere notiere ich als separates Ticket – falls es wirklich wichtig ist.

3. Konkrete und umsetzbare Verbesserungsvorschläge

"Hier könnte man das besser machen" ist kein Feedback, das hilft. Was hilft, ist ein konkreter Vorschlag – gerne direkt als Code-Snippet: 

// Statt:
if ($status == 1 || $status == 2 || $status == 3) { ... }

// Besser:
$aktiveStatus = [1, 2, 3];
if (in_array($status, $aktiveStatus)) { ... }

Wer einen konkreten Vorschlag macht, signalisiert: Ich helfe dir, ich urteile nicht über dich. Das ist der Ton, der Reviews in Legacy-Projekten funktionieren lässt.

Positives Feedback – das Seltenste im Legacy-Review

In Legacy-Projekten gibt es wenig Lob. Das liegt nicht daran, dass es nichts zu loben gibt, sondern daran, dass alle so sehr auf die Probleme fokussiert sind, dass das Gelungene unsichtbar wird. Dabei ist ein ehrliches "Das ist sauber gelöst" oder "Gut, dass du das ausgelagert hast" in einem Umfeld, das vor Verbesserungsbedarf strotzt, besonders wertvoll. Es zeigt, dass das Review kein Fehlersuchspiel ist, sondern ein gemeinsamer Blick auf den Code.

Ein Code Review ist keine Prüfung, sondern ein Gespräch. Wer das vergisst, bekommt irgendwann Entwickler, die ihre Änderungen so klein wie möglich halten – nicht weil sie so arbeiten wollen, sondern weil weniger Code weniger Angriffsfläche bedeutet.

Fazit

Legacy-Projekte brauchen Code Reviews vielleicht mehr als moderne Greenfield-Projekte. Aber sie brauchen sie in einem Ton, der die Menschen mitnimmt, statt sie zu verschrecken. Historischen Kontext respektieren, nur das Geänderte reviewen, konkrete Vorschläge machen – und hin und wieder laut sagen, was gut ist. Das ist keine Weichheit, das ist Pragmatismus.