Code-Review und die Wahrscheinlichkeitstheorie

Stellen wir uns einen Entwickler namens John vor. Er schreibt einen Code, na ja, weil er ein Entwickler ist. Nehmen wir an, dass John ein guter Entwickler ist und 75% des Codes fehlerfrei sind. In der Tat lüge ich, und John ist fast ein Guru, aber lassen Sie uns das trotzdem mal annehmen. Um es einfach zu machen, lassen Sie uns davon ausgehen, dass von den 100 Zeilen seines Code 75 Zeilen keine Korrekturen brauchen und die restlichen 25 Zeilen eine Fehlererkennung und -korrektur durchlaufen müssen. Und wir entscheiden, wie diese gemacht werden muss. Normalerweise gibt es dazu viele Ideen: Der eine predigt umfassende Modultests, der andere argumentiert für die Erweiterung des QA-Teams, weitere plädieren für den Code-Review für jeden Commit; Perfektionisten, die das Budget und die Fristen ignorieren, sind für alle oben genannten Maßnahmen, während selbstbewusste “Profis” und kleinliche Manager gegen alles abstimmen. Wie immer. Aber wir brauchen die Auflösung. Dann kommt die Idee, die Ressourcen zu bewerten und von jeder Aktivität zu profitieren. Jetzt wollen wir, sagen wir mal, die Effizienz des Code-Reviews einschätzen.

Eine ungekünstelte Berechnung kann wie folgt aussehen: John hat 100 Code-Zeilen geschrieben (In der Regel hat er rund 75% richtigen Code und 25% Fehler). Lassen Sie ihn die gleiche Menge an Zeit in den Code -Review investieren und wir kriegen nur die halbe Menge an Bugs (12,5%) raus. Nun, eine doppelte Ressourcenaufwendung soll die Fehler halbieren.

Doch bisher – nichts dergleichen! John ist John. Er hat den Code gestern geschrieben und, wenn er seinen Code-Review heute durchgeführt, findet er nichts.

OK, schauen wir weiter. Wenn Peter (fast gleich qualifiziert) Johns Code überprüft, wird er die Anzahl der Fehler auf die Hälfte (bis zu 12,5%) reduzieren. Ja, weil sie beinahe die gleiche Qualifikation haben, aber nach wie vor unterschiedliche Menschen sind. Also verbraucht dieser Job doppelt so viele Ressourcen; daher haben wir die Hälfte der Bugs übrig. Nun, schauen wir uns an, was wir in der Realität haben.

Die Wahrscheinlichkeitstheorie besagt, dass, wenn ein System aus zwei Geräten mit der Zuverlässigkeit Х und Y besteht, werden beide Geräte für eine Fehlfunktion nicht ausreichen. Die totale Zuverlässigkeit beträgt also 1 — (1-X)*(1-Y), d. h. für die “Geräte” von John und Peter mit der gleichen Zuverlässigkeit von 75% wird die totale Zuverlässigkeit 93,75% ausmachen! Schauen Sie, die Anzahl der Bugs sinkt nicht auf 12,5%, sondern auf 6,25%! Also reduzieren die Ressourcen einer anderen Person (auch von der gleichen Qualifikation) beim Code-Review die Anzahl der Fehler nicht zweimal, sondern viermal! Cool. Außerdem, wenn man bedenkt, dass die besten Entwickler im Team (genauer gesagt, die mit der Zuverlässigkeit über “den durchschnittlichen” 75%) in der Regel den Code reviewen, wobei sie deutlich weniger Zeit als der Autor beim Code-Schreiben verbringen, sind die Ergebnisse noch beeindruckender.

Wozu das Ganze?

Mit dem besseren Verständnis der möglichen Ergebnisse und mit dem Ressourceninvestment in den Code-Review ist es leichter, sich für den einen oder anderen Mechanismus bei der Qualitätsverbesserung des Codes zu entscheiden. Es ist nun möglich, mit Zahlen zu operieren und nicht die üblichen Phrasen “Jeder tut es, also ist es richtig” oder “Zur Hölle damit, es ist ohnehin keine Zeit da!” gegeneinander auszuspielen. Für ein vernünftiges Management wird ein Argument, das sich auf Zahlen stützt, immer mehr als eine einfach nur schöne Formulierung wiegen.

Eine Zusammenfassung für diejenigen, die zu faul sind, um den ganzen Artikel lesen

Die Anwendung von Code-Reviews (falls Sie bisher noch keine genutzt haben) wird mehr Vorteile mit sich bringen, als es am Anfang scheint.