Infopulse - Expert Software Engineering, Infrastructure Management Services
Send message Request a call
Send message Please fill in this quick form and we will send you a free quote shortly.
* Required fields
Request a call Please fill in this quick form and we will call you back shortly.
* Required fields
Subscribe to Infopulse Newsletter Please fill in this quick form to be among the first to receive our updates.
* Required fields
Send an email to Volodymyr Korniichuk Please fill in this quick form to contact our expert directly.
* Required fields
Read the rest of the Case Study Don't miss the most interesting part of the story!
Submit this quick form to see the rest and to freely access all case studies on our website.
* Required fields

Code-Review und die Wahrscheinlichkeitstheorie

Nicht alle Entwickler sind mit der Wahrscheinlichkeitstheorie vertraut. Man würde denken, dass es kein Problem wäre. Für jeden Topf gibt es nur einen Deckel – es gibt keine Universalgenies. Die gute Kenntnis der Wahrscheinlichkeitstheorie wird vielleicht in der Spielentwicklung, Kryptographie und möglicherweise bei verschiedenartiger Finanz- und Statistiksoftware benötigt. Doch in der Realität kann der Mangel an Verständnis für gewisse Dinge auch in den Projekten zu schlechten Ergebnissen führen, die die Anwendung solcher Dinge scheinbar gar nicht implizieren. Es ist keine Magie, das menschliche Gehirn kann einfach einige Wahrscheinlichkeiten ausblenden und dadurch falsche Entscheidungen treffen.

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.

Share this blog article:
Subscribe to our Newsletter