Die Größe eines Pull Requests sagt mehr über das Risiko als sein Inhalt
Es gibt eine Kennzahl, die in jedem Werkzeug bereitliegt und fast nirgends ausgewertet wird: die Größe einer Änderung im Verhältnis zur Zeit, die jemand darauf verwendet hat. Sie zeigt den Übergang vom Prüfen zum Durchwinken zuverlässiger als jede Umfrage.
Die Änderungsgröße im Verhältnis zur Reviewdauer zeigt den Übergang vom Prüfen zum Durchwinken zuverlässiger als jede Befragung. Bei wenigen Dutzend Zeilen wird gelesen, bei einigen hundert überflogen, bei über tausend nur noch auf grüne Tests geprüft. Assistenzsysteme verschieben die Verteilung nach oben. Auszuwerten sind drei Zahlen: Verteilung der Änderungsgrößen über die Zeit, Reviewdauer im Verhältnis dazu, und Fehlerrate je Größenklasse — der Knick darin ist die hausgemachte Grenze. Unvermeidbar große, mechanische Änderungen brauchen eine eigene Klasse mit Nachweis statt Lektüre.
Was in der Praxis passiert
Bei wenigen Dutzend geänderten Zeilen liest ein Reviewer den Code. Bei einigen hundert liest er die Beschreibung und überfliegt die Änderungen. Bei mehr als tausend prüft er, ob die Tests grün sind, und gibt frei. Das ist keine Nachlässigkeit, sondern eine vernünftige Reaktion auf eine unlösbare Aufgabe — und sie ist in der Statistik nicht von echtem Prüfen zu unterscheiden.
Warum das Volumen die Verteilung verschiebt
Mit Assistenzsystemen entstehen größere Änderungen, weil die Erzeugung billig ist. Eine Aufgabe, die früher in drei Schritten kam, kommt jetzt in einem. Das verbessert die Durchlaufzeit bis zum Review und verschlechtert die Prüfqualität — und beide Effekte treten gleichzeitig auf, weshalb die Gesamtwirkung ohne Messung nicht erkennbar ist.
Die drei Zahlen, die man auswerten sollte
Erstens die Verteilung der Änderungsgrößen über die Zeit — verschiebt sie sich nach oben? Zweitens die Reviewdauer im Verhältnis dazu: Bleibt sie konstant, während die Größe steigt, ist die Prüfung faktisch aufgegeben. Drittens die Änderungsfehlerrate nach Größenklasse: In fast jeder Organisation zeigt sich hier ein Knick, und der Knick ist die eigene, hausgemachte Grenze.
Was tun, wenn große Änderungen unvermeidlich sind
Manche Änderungen lassen sich nicht schneiden — eine Umbenennung über tausend Dateien, eine Bibliotheksaktualisierung, eine automatische Formatierung. Für die gilt eine eigene Klasse: mechanische Änderungen ohne Verhaltensänderung, maschinell erzeugt, maschinell überprüfbar. Sie werden nicht gelesen, sondern durch einen Nachweis abgesichert, dass sich das Verhalten nicht ändert.
Die unbequeme Konsequenz
Wer die Grenze kennt, muss danach handeln. Entweder Änderungen werden geschnitten, oder sie bekommen eine andere Art der Prüfung. Was nicht geht, ist die Grenze zu kennen und weiterhin so zu tun, als würde bei zwölfhundert Zeilen gelesen.
Häufige Fragen
Gibt es eine allgemeingültige Obergrenze für Pull Requests?
Verbreitet ist die Empfehlung von rund 200 bis 400 geänderten Zeilen, aber die eigene Zahl ist aussagekräftiger. Werten Sie die Fehlerrate nach Größenklasse aus; der Knick in Ihrer Kurve ist Ihre Grenze und lässt sich intern nicht bestreiten.
Wie geht man mit automatischen Formatierungen um?
Als eigene Klasse mechanischer Änderungen: getrennt von fachlichen Änderungen einreichen, maschinell erzeugt, mit einem Nachweis, dass sich das Verhalten nicht ändert. Vermischt mit fachlichen Änderungen machen sie jeden Review unmöglich.
Führen kleinere Pull Requests nicht zu mehr Overhead?
Zu mehr Vorgängen, ja, zu mehr Aufwand pro Zeile eher nicht. Der Engpass ist Aufmerksamkeit, nicht Verwaltung. Wenn die Zahl der Vorgänge zum Problem wird, ist das ein Hinweis darauf, dass zu viel davon menschlich freigegeben werden muss — also auf einen falsch geschnittenen Risikoklassen-Zuschnitt.
Woher bekommt man diese Zahlen?
Aus der Programmierplattform: Änderungsgröße, Zeit zwischen Eröffnung und Freigabe, Zahl der Kommentare je Vorgang. Alle drei sind über die Standardschnittstelle abrufbar; für eine erste Auswertung reichen die letzten sechs Monate.
Rechnen Sie Ihre Review-Lücke aus.
Vierzehn Angaben, fünf Minuten. Ihre Zahlen, kein Login.
Engineering-Check starten →
