Code-Review

Ein Arbeitstag ist die Obergrenze – so hält es Googles öffentlich dokumentierte Review-Leitlinie für die Antwort auf eine eingereichte Änderung. Gemessen wird es auch: In einer Auswertung von rund 9 Millionen geprüften Änderungen bei Google lag die Wartezeit auf die erste Rückmeldung im Median unter einer Stunde für kleine und bei etwa fünf Stunden für sehr große Änderungen. Dieselbe Studie referiert für andere Häuser deutlich längere Werte, bis zu 24 Stunden im Median.

Unter 300 geänderten Zeilen je Stunde findet ein Prüfer am meisten, bis 500 Zeilen je Stunde gilt noch als tragbar – darüber gehen erhebliche Anteile der Fehler durch. Die Zahlen stammen aus einer Auswertung von 2.500 Durchsichten über 3,2 Millionen Zeilen, veröffentlicht 2006. Dieselbe Untersuchung nennt 60 Minuten als Obergrenze je Sitzung, weil die Fundrate ab 90 Minuten einbricht. Wer schneller liest, prüft nicht, sondern quittiert.

Einer genügt in der Regel. Bei Google haben weniger als 25 Prozent der Änderungen mehr als einen Prüfer, über 99 Prozent höchstens fünf, und der Median liegt bei genau einem – gemessen an rund 9 Millionen Durchsichten. Ältere Untersuchungen kamen auf zwei als eingespielte Zahl, die formale Fagan-Inspektion setzt vier Personen an. Die harte Grenze liegt beim Ein-Personen-Betrieb: Dort gibt es keinen Zweiten, und ein Werkzeug tritt nicht an seine Stelle.

Der Prüfer entscheidet, solange es um den Zustand des Codes geht und nicht um seinen Geschmack. Googles öffentliche Leitlinie zur Durchsicht formuliert die Regel so: zustimmen, sobald die Änderung den Zustand des Systems deutlich verbessert, auch wenn sie nicht vollkommen ist. Reine Geschmacksfragen kennzeichnet der Prüfer dort mit einem Vorsatz, und der Autor darf sie übergehen. Bleibt es strittig, geht die Sache an den technisch Verantwortlichen – nicht an den Ausdauerndsten.

Die Fehlerart verschiebt sich. Statt offensichtlicher Schnitzer steht Code da, der plausibel aussieht und an einer Stelle das Falsche tut. Im Stack-Overflow-Entwicklerreport 2025 nennen 66 Prozent der Befragten „fast richtig, aber nicht ganz“ als größte Reibung, 45 Prozent verlieren erhebliche Zeit beim Beheben von Fehlern in solchem Code. Der Prüfer kann sich deshalb nicht am sicheren Ton des Entwurfs orientieren, sondern muss die Anforderung daneben legen. Die Haftung bleibt bei der Person, die zusammenführt.

Ein Pull-Request ist der technische Antrag, einen Zweig in den Hauptzweig zu übernehmen; das Code-Review ist die Durchsicht, die darin stattfinden kann. Das eine gibt es ohne das andere: Durchsichten laufen auch zu zweit am Bildschirm oder nachträglich per Mail – von den vier gängigen Formen läuft nur eine werkzeuggestützt über einen Antrag. Und eine Zweigsperre, die zwei Zustimmungen verlangt, erzwingt Klicks, nicht Lesen.