Code Review – Best practices

Code-Reviews gelten als bewährtes Mittel zur Steigerung der Qualität einer Software und werden daher besonders in agilen Entwicklungsprozessen eingesetzt.

  • Durch das angewandte 4-Augen-Prinzip werden Bugs im Code möglichst früh beseitigt. Allgemein gilt: Je früher ein Bug gefunden und beseitigt werden kann, desto besser.
  • Die Entwickler eines Teams können Tipps und Tricks austauschen und verbessern somit gegenseitig ihren Programmierstil.
  • Es wird eine bessere Zusammenarbeit zwischen den Entwicklern gefördert.
  • Das Code-Wissen innerhalb eines Projektteams wird besser verteilt. Dies macht sich vor allem in späteren Wartungsphasen bezahlt.
  • Der Codeautor weiß, dass sein geschriebener Code anschließend von einer zweiten Person begutachtet wird. Dies führt automatisch zu mehr Selbstkontrolle und somit zur Steigerung der Qualität.

Für eine effektive Durchführung von Code-Reviews sollte man allerdings einige Regeln beachten, da die Steigerung der Qualität ansonsten unter Umständen sehr teuer werden kann. Im Folgenden sind verschiedene “Best Practices” aufgeführt, die sich in der Praxis bewährt haben:

1. Weniger ist mehr

Muss ein Reviewer zu lange oder zu viele Code nach Fehlern durchsuchen, sinkt die Fehlererkennungsrate signifikant. Als maximale Grenze sollten die folgenden Werte gelten:

  • Weniger als 200-400 Codezeilen pro Review
  • Weniger als 300-500 Codezeilen pro Stunde
  • Insgesamt nicht länger als 60-90 Minuten

2. Anmerkungen des Autors

Der Codeautor erstellt Anmerkungen, die dem Reviewer beispielsweise die Reihenfolge der Reviews vorgeben. So bekommt der Reviewer einen schnelleren Zugang zum betrachteten Code und kann das Review somit effizienter durchführen. Außerdem ist der Autor gezwungen sich die grobe Struktur seines Codes nochmals vor Augen zu führen.

3. Messbare Ziele festlegen und deren Erreichung überprüfen

Auch effizient durchgeführte Reviews kosten die Beteiligten wertvolle Zeit. Daher ist es wichtig, sich über die Ziele des Review-Prozesses Gedanken zu machen. Nur so kann einen kontinuierliche Verbesserung des Prozesses angestrebt und die Softwarequalität somit mit einem bestmöglichen Kosten-Nutzen-Verhältnis verbessert werden. Beispiel für eine solche Metrik: “Anzahl der vom Endbenutzer gemeldeten kritischen Bugs innerhalb eines bestimmten Zeitraumes.”

4. Checklisten

Beim Review Fehler im analysierten Code zu finden ist nicht einfach. Noch schwieriger ist es allerdings Fehler zu finden, die durch Codestellen entstehen, die fälschlicherweise nicht angepasst wurden. Bei der Suche solcher Fehler helfen Checklisten, die während des Reviews abgearbeitet werden, da damit eine nahezu vollständige Prüfung der Änderungen erreicht werden kann. Auch für den Codeautor sind solche Listen hilfreich, da er damit häufig gemachte Fehler bereits vor dem Review ausschließen und den Review-Prozess damit für alle Beteiligten angenehmer gestalten kann.

5. Bug fixen!

Eigentlich trivial, aber dennoch wird dieser “Best Practice” häufig genug missachtet. Bugs werden während des Reviews gefunden und anschließend in diversen Listen oder E-Mails verwaltet anstatt sie umgehend zu beheben. Es ist daher wichtig, die frühzeitige Behebung der Fehler zu kontrollieren, da die Code-Reviews ansonsten sinnlos sind.

6. Soziale Aspekte beachten

Code-Reviews sollen die Qualität des Codes und somit der Software verbessern. Sehr schnell kann dies allerdings zu einer ungeliebten Aufgabe für alle Beteiligten werden.

Die Reviewer müssen zusätzliche Aufgaben übernehmen und andere Arbeiten bleiben in dieser Zeit liegen. Die Autoren des Codes wiederum fühlen sich durch die “Kritik” an ihrem Code persönlich angegriffen und empfinden den Review-Prozess unter Umständen als unnötige Kontrolle ihrer Arbeit. Die folgenden Tipps können beim Erhalt einer positiven Einstellung gegenüber Code-Reviews behilflich sein:

  • Auf die möglichst effektive Durchführung des Reviews achten, damit unnötige Aufwände vermieden werden und der Nutzen der Reviews somit deutlich wird.
  • Fragen stellen anstatt Aussagen zu machen: Die Frage “Was war der Grund für dein hier gewähltes Vorgehen?” kommt in aller Regel viel besser beim Autor an als die Aussage “Du hältst dich an dieser Stelle nicht an die Vorgaben”.
  • Loben, loben, loben: Die Codeautoren wollen hören, dass ihr Code gut ist und nicht ausschließlich auf die gefundenen Fehler hingewiesen werden. Die Arbeit zu loben ist daher von entscheidender Bedeutung für die Moral im Team.
  • Kritik immer auf den Code und nicht auf den Codeautor beziehen.
  • Alle Beteiligten sollten sich immer vor Augen halten, dass es mehr als eine richtige Lösung für ein Problem gibt.
  • Bei schriftlichen Code-Reviews sollte es eine Absprache geben, dass Fragen nicht beantwortet werden müssen. Die richtigen Fragen zu stellen, regt beim Autor einen Denkprozess an, der zumindest bei zukünftigen Entwicklungen einen positiven Einfluss haben kann. Ansonsten kommt es allzu schnell zu ewigen Diskussionen über Richtig oder Falsch und somit zu Konflikten innerhalb des Teams.

<

p>Quellen:

11 Best Practices for Peer Code Review

Effective Code Reviews Without the Pain

Short URL for this post: http://wp.me/p4nxik-AF
This entry was posted in Java and Quality and tagged , , . Bookmark the permalink.

Leave a Reply