Code Reviews einführen, ohne dass sie zum Nadelöhr werden

Die Größe der Änderung ist der stärkste Hebel

Die Untersuchung von Sadowski und Kollegen zu Reviews bei Google liefert dazu ungewöhnlich konkrete Zahlen. Über fünfunddreißig Prozent der betrachteten Änderungen betreffen nur eine einzige Datei, rund neunzig Prozent weniger als zehn Dateien, über zehn Prozent ändern eine einzige Zeile, und der Median liegt bei vierundzwanzig geänderten Zeilen. Zum Vergleich nennt dieselbe Arbeit Werte aus anderen Unternehmen, die deutlich darüber liegen, in einem Fall bei über zweihundertsechzig Zeilen.

Der Zusammenhang mit der Qualität des Reviews ist gut belegt und in der Arbeit ausdrücklich benannt: Je größer die Änderung, desto weniger nützliche Kommentare entstehen und desto länger dauert der Durchlauf. Das ist keine Frage der Disziplin, sondern der Aufmerksamkeitsspanne. Wer vierzig Dateien vor sich hat, kann nicht mehr im Kopf behalten, was in Datei drei stand, als er Datei siebenunddreißig liest.

Für die Einführung folgt daraus die unbequemste Aufgabe: Ihr müsst lernen, Arbeit in kleine, für sich sinnvolle Schritte zu zerlegen. Das ist eine Fähigkeit, die geübt werden muss, und sie hat mit dem Review selbst gar nichts zu tun. Hilfsmittel sind ein Refactoring getrennt von der Verhaltensänderung, ein vorbereitender Umbau als eigener Pull Request und Feature-Flags, mit denen unfertige Arbeit gefahrlos zusammengeführt werden kann.

Geschwindigkeit schlägt Gründlichkeit

Googles öffentlich verfügbare Anleitung für gegenlesende Personen stellt das Prinzip an den Anfang: Optimiert wird die Geschwindigkeit, mit der ein Team gemeinsam ein Produkt herstellt, nicht die Geschwindigkeit einer einzelnen Person. Konkret heißt das, dass ein Arbeitstag die Höchstgrenze für die erste Reaktion ist und dass mehrere Runden im Idealfall an einem Tag stattfinden. Ausdrücklich nicht gemeint ist, dass jede eigene Arbeit sofort unterbrochen wird, denn der Verlust an Konzentration kostet das Team mehr, als die Wartezeit einbringt.

Die Zahlen aus der Untersuchung passen dazu. Die Wartezeit auf eine erste Rückmeldung liegt im Mittel unter einer Stunde bei kleinen Änderungen und bei etwa fünf Stunden bei sehr großen, der gesamte Durchlauf im Mittel unter vier Stunden. Der Aufwand je Person liegt bei durchschnittlich gut drei Stunden pro Woche für das Gegenlesen. Das ist eine ehrliche Zahl für die Kapazitätsplanung und deutlich weniger, als die meisten Teams befürchten, wenn sie über die Einführung diskutieren.

Der praktische Umgang mit diesem Spannungsfeld ist ein fester Zeitpunkt statt ständiger Unterbrechung. Zwei feste Fenster am Tag, an denen offene Pull Requests abgearbeitet werden, halten die Frist ein, ohne die eigene Arbeit zu zerhacken. Wichtig ist nur, dass diese Fenster tatsächlich im Kalender stehen und nicht als guter Vorsatz existieren.

Diese Richtung wird von außen bestätigt. Die Auswertungen von DORA finden keinen Beleg dafür, dass ein förmlicher externer Freigabeprozess, etwa über ein Änderungsgremium, zu weniger fehlgeschlagenen Auslieferungen führt. Was stattdessen wirkt, ist das Gegenlesen durch Kollegen im Entwicklungsablauf selbst, zusammen mit automatisierten Prüfungen. Der Grund ist derselbe wie bei der Größe: Ein langsamer Freigabeweg führt zu größeren Paketen, die seltener ausgeliefert werden, und genau das erhöht das Risiko, statt es zu senken.

Was die Maschine übernimmt und was nicht

Alles, was eine eindeutige richtige Antwort hat, gehört in die Pipeline: Formatierung, Importreihenfolge, ungenutzte Variablen, bekannte Fehlermuster, Typprüfung, Abhängigkeiten mit gemeldeten Schwachstellen und natürlich die Tests. Wenn diese Dinge in Kommentaren auftauchen, verbrauchen sie die Aufmerksamkeit, die für die fachliche Frage gebraucht wird, und sie erzeugen beim Gegenüber verlässlich Ärger, weil sie sich nach Schulmeisterei anfühlen.

KI-gestützte Assistenten haben in diesem Bild einen klaren Platz, nämlich als Vorprüfung vor dem menschlichen Review. Wer die eigene Änderung erklären lässt, sich auf offensichtliche Lücken hinweisen lässt und fehlende Testfälle vorschlagen lässt, kommt mit einem saubereren Stand ins Review. Was ein Assistent nicht ersetzt, ist die Freigabe, denn dafür braucht es eine Person, die für die Änderung im Betrieb geradesteht und die den fachlichen Zusammenhang kennt.

Übrig bleibt für Menschen genau das, wofür sie gebraucht werden: Ist der gewählte Weg der richtige, passt die Änderung zur bestehenden Architektur, ist das fachliche Verhalten in den Randfällen richtig, wird hier eine Entscheidung getroffen, die später schwer zurückzunehmen ist. Diese vier Fragen kann keine Prüfung automatisieren, und ein Review, das sich auf sie beschränkt, ist in zwanzig Minuten fertig.

Ton, Macht und die Gründe, warum Reviews scheitern

Dieselbe Untersuchung benennt für Google trotz jahrelanger Verfeinerung mehrere wiederkehrende Störquellen. Zwei davon sind sozialer Natur. Die erste ist der Ton: Kommentare mit abwertendem Unterton sind messbar weniger nützlich, weil sie beim Gegenüber Verteidigung auslösen statt Nachdenken. Die zweite ist Macht: Das Verfahren lässt sich benutzen, um jemanden zu einer Verhaltensänderung zu zwingen, etwa indem eine Zustimmung hinausgezögert oder zurückgehalten wird.

Genannt wird außerdem die Distanz, sowohl räumlich als auch organisatorisch. Wenn die gegenlesende Person in einem anderen Team oder in einer anderen Zeitzone sitzt, entstehen Verzögerungen und Missverständnisse. Für verteilte Teams heißt das nicht, dass Reviews nicht funktionieren, sondern dass die Verabredung über die Frist umso wichtiger ist und dass Grundsatzfragen früher in ein Gespräch gehören.

Die vierte Störquelle ist der Streit darüber, was überhaupt Gegenstand des Reviews ist. Wenn jemand eine Entwurfsentscheidung erst im Pull Request angreift, obwohl sie zwei Wochen vorher hätte besprochen werden können, ist das für beide Seiten unbefriedigend. Die Abhilfe ist ein Format davor: eine kurze Abstimmung über den Weg, bevor Code entsteht. Was danach im Review noch angesprochen werden darf, ist die Umsetzung, nicht der Weg.

Reviews in einem bestehenden Team einführen

Der schwierigste Fall ist nicht das neue Team, sondern das eingespielte, das bisher ohne Review gearbeitet hat. Dort trifft die Einführung auf die berechtigte Sorge, dass jemand die eigene Arbeit bewertet, und auf die Erfahrung, dass es bisher auch so ging. Ein Erlass von oben erzeugt in dieser Lage formale Zustimmungen ohne Inhalt, also Freigaben nach zwanzig Sekunden.

Was funktioniert, ist ein enger erster Zuschnitt: Reviews zunächst nur für einen klar umrissenen Bereich, etwa für Änderungen an einer sicherheitsrelevanten Komponente oder für alles, was Datenbankmigrationen betrifft. Dort ist der Nutzen unmittelbar einleuchtend, niemand muss überzeugt werden, und das Team sammelt Erfahrung mit dem Verfahren, bevor es breiter gilt.

Der zweite Baustein ist das Vorbild. Wenn die erfahrenste Person im Team ihre eigenen Änderungen als Erste zum Gegenlesen gibt und dabei sichtbar Anmerkungen annimmt, verschiebt das die Bedeutung des Verfahrens von Kontrolle zu gemeinsamer Arbeit. Das ist der wirksamste einzelne Schritt bei der Einführung und kostet nichts außer der Bereitschaft, den eigenen Code offenzulegen.

Der dritte Baustein ist Geduld mit den Zahlen. In den ersten Wochen dauert alles länger, weil sich niemand auskennt und weil die Änderungen noch zu groß sind. Wer nach vier Wochen misst und aufgibt, misst die Anlaufkosten. Drei Monate sind der frühestmögliche ehrliche Zeitpunkt für eine Bewertung.