Wie lassen sich richtig gute Ad-Hoc-Reviews durchführen?

Das Geheimnis einer guten Code Review: Best Practice für alle!
Keine Kommentare

Jeder Entwickler kennt Code Reviews: Toolbasiert, im Team oder spontan durch einen einzelnen Kollegen wird Code begutachtet, diskutiert und dadurch (hoffentlich) verbessert. Was macht aber eine gute Review aus, wie gehen Entwickler dabei am liebsten vor und wie lässt sich die Review verbessern?

Code Reviews sind aus dem Alltag der meisten Entwickler kaum wegzudenken: Egal, ob der Code informell mit einem Kollegen besprochen oder mit Tools ganz strukturiert begutachtet wird – das Verfahren der Code Reviews eignet sich nicht nur dazu, die Produktqualität zu steigern. Es hilft auch dabei, den Wissenstransfer innerhalb des Teams zu verbessern. Das Pair Programming integriert den Review-Prozess sogar unmittelbar in das Schreiben des Codes. Während ein Entwickler tippt, führt ein anderer eine Art von Review in Echtzeit durch. Das ist der große Vorteil der Methode und soll zu einer signifikanten Reduktion der Bugzahl im Code führen. Und gerade in Open-Source-Projekten spielen Code Reviews eine große Rolle und stellen für viele Entwickler einen Anreiz zur ehrenamtlichen Mitarbeit dar.

Code Reviews beliebter als Unit Tests

Darum hat der State of Code Quality 2016 Survey diesen wichtigen Bestandteil des Entwickleralltags einmal genauer unter die Lupe genommen: Wie zufrieden sind Entwickler mit ihrem Code; welche Verfahren werden zur Qualitätssteigerung eingesetzt? Diese und viele weitere Fragen stellte das Unternehmen SmartBear im Dezember 2015 600 IT-Profis aus mehr als 30 verschiedenen Branchen. Die größte Gruppe unter den Befragten stellen mit einem Anteil von 48 Prozent die Entwickler dar, gefolgt von Testern (17 Prozent).

Insgesamt zeigt der Survey, dass die meisten Entwickler zufrieden mit der Codequalität des Produkts sind, an dem sie arbeiten – das traf auf etwa Zweidrittel der Befragten zu. Etwa gleich hoch liegt die Quote derjenigen, die ihren Code regelmäßig innerhalb der Deadline ausliefern können. Allerdings müssen für die pünktliche Auslieferung durchaus Abstriche gemacht werden: So ist die Code Review zwar die beliebteste Methode zur Qualitätssteigerung, mit der 62,7 Prozent der Befragten arbeiten. Damit liegt die Methode in Führung vor Unit Tests, die ebenfalls häufig zur Verbesserung des Codes angewendet werden. 65,6 Prozent der Teilnehmer gaben allerdings auch an, dass ihre Arbeitsbelastung sie davon abhält, intensivere Code Reviews durchzuführen. Codequalität und Deadlines stehen also durchaus in Konkurrenz zueinander.

Beliebteste Review-Arten

Die häufigste Form der Code Review ist laut dem vorgenannten Survey die Ad-Hoc-Review, bei der Code spontan mit einzelnen Kollegen besprochen wird. 71,9 Prozent der Befragten des State of Code Quality 2016 Survey nutzen diese Form der Review, die am häufigsten wöchentlich durchgeführt wird. Nur etwas mehr als die Hälfte der Teilnehmer nimmt an Code Reviews in Meetings teil, die zumeist wöchentlich oder monatlich stattfinden.

Toolbasierte Code Reviews, beispielsweise mit Gerrit, sind beliebter als Review-Meetings. 63 Prozent der Befragten nutzen diese Art der Code Review, die damit den zweiten Platz in der Rangliste der Review-Methoden belegt. In Führung liegt die toolbasierte Review allerdings bei den täglichen Reviews: Nur vier Prozent der Befragten nehmen täglich an Review-Meetings teil; bei den Ad-Hoc-Reviews liegt die Quote der täglichen Anwender bei 14 Prozent. Für die toolbasierte Variante gaben 24 Prozent der Befragten an, sie täglich einzusetzen. Die größten Hindernisse für den Einsatz von Tools zur Review stellen erneut die Arbeitsbelastung der Befragten und Budgetbegrenzungen dar, die der Anschaffung von Software für den Review-Prozess im Weg stehen.

Code Reviews bei Mozilla

Neben der Art der durchgeführten Review muss allerdings auch die Review-Qualität stimmen. Zeitdruck, die Persönlichkeit des Reviewers, organisatorische Hürden und viele andere Faktoren beeinflussen das Ergebnis einer Review. Die Präferenz für Ad-Hoc-Verfahrensweisen kann dazu führen, dass diese stärker ins Gewicht fallen, weil der formale Rahmen zum Ausgleich personenbezogener Faktoren wie der Erfahrung des Reviewers fehlt.

Kanadische Forscher haben im Rahmen einer in diesem Jahr veröffentlichten Studie untersucht, woran Entwickler die Qualität von Code Reviews beurteilen. Dazu wurden 88 Entwickler befragt, die in den vorherigen zwölf Monaten mindestens 15 Patches im Mozilla-Projekt eingereicht oder beurteilt haben, über eine ausreichend große Erfahrung in der Programmierung verfügen und bereits länger am Projekt beteiligt sind.

Kriterien für gute Code Reviews

Einen besonders großen Einfluss auf die Qualität der durchgeführten Review hat nach Meinung der befragten Entwickler die Erfahrung des Reviewers. Auch die Patch-Größe, gemessen in Codezeilen, stellt einen wichtigen Faktor dar, der mit der verfügbaren Zeit zusammenhängt. Je mehr Code in kurzer Zeit beurteilt werden soll, desto stärker leidet die Review-Qualität. Auch die Erfahrung des Patch-Entwicklers spielt aber eine Rolle für die Qualität der Review. Je weniger Erfahrung ein Entwickler hat, desto aufwändiger wird eine Review zumeist ausfallen.

Ein ausschlaggebender Faktor für eine gute Review ist die fachliche Kompetenz des Reviewers. Gutes Feedback sollte sich nicht nur auf den Coding-Stil beziehen und von einem Reviewer gegeben werden, der ein ausreichend großes Wissen auf dem jeweiligen Fachgebiet und bezüglich der Code-Basis besitzt, so die Studie. Dies wird allerdings auch als besondere Herausforderung im Review-Prozess wahrgenommen: Die Einarbeitung in fremden Code kann viel Zeit kosten, nur dann ist eine Review aber hilfreich.

Der Kommunikationsstil eines Reviewers spielt ebenfalls eine große Rolle für die Beurteilung einer Review durch die befragten Mitglieder der Mozilla Developer Community. So wünschen sie sich, dass ein Reviewer grundsätzlich freundlich, zugewandt und unterstützend auftritt. Er muss dabei jedoch auch dazu in der Lage sein, Probleme deutlich zu kommunizieren und sich durchzusetzen. Der Tonfall ist dabei besonders wichtig: Kommentare sollten konstruktiver Natur sein und so vermittelt werden, dass der Autor des Codes sie nicht persönlich nimmt. Das ultimative Kriterium für eine gute Code-Review ist für die Mozilla-Developer aber natürlich die Code-Qualität. Sie soll durch die Review in einem Maße steigen, das der Entwickler des Codes alleine nicht erreichen könnte.

Auch Clean-Code-Prinzipien, also Prinzipien und Praktiken für Entwickler für das Schreiben von sauberem Code, können Einzug in den Code-Review-Prozess halten.

Die Code Review verbessern: Best Practices

Das Ziel ist also klar, auch die Herausforderungen sind offensichtlich. Wie bekommt man das alles nun hin? Vor jeder Code Review muss bedacht werden, dass niemand unbegrenzt viel Zeit zur Verfügung hat, um eine Code Review durchzuführen. Also sollten vor dem Review-Auftrag zwei Fragen beantwortet werden: Kann dieser Prozess automatisiert werden? Worum geht es bei der Review wirklich?

Die erste Frage bezieht sich auf Faktoren wie offensichtliche Bugs und allgemeine Sicherheitsrisiken und den Stil des zu beurteilenden Codes. Diese Aspekte lassen sich über automatisierte Tests und eingebaute Features der gewählten IDE häufig zumindest erst einmal grob überprüfen. Diese Möglichkeit sollte genutzt werden, um den Aufwand für den Kollegen zu senken, der die Review danach durchführt.

Fokus für Qualität

Review-Tools und automatisierte Tests können nicht aber nur erste Probleme eigenständig lösen, sondern auch zur Vorauswahl der Teile des Codes genutzt werden, die danach einer genaueren Inspektion unterzogen werden. Häufig geht es in einer Code Review nicht nur um richtige und falsche Codezeilen; dabei würde es sich ja um eine Bug-Suche handeln. Ob eine vorgeschlagene Änderung am Code aber gute oder nicht ganz so gute Auswirkungen hat, ist häufig Auslegungssache. Ein Tool kann auf mögliche Konflikte hinweisen, die dann dem Reviewer übergeben werden.

Auch das Eingrenzen eines Review-Bereichs sollte vor der Peer-Review erfolgen. So könnte es sein, dass das Produkt besondere Anforderungen an die Performance stellt – dann sollte diese überprüft werden. Oder müssen die Daten besonders sicher sein; muss der Code über sehr lange Zeit hinweg von immer wieder wechselnden Entwicklern gepflegt werden? All diese Fragen  können zu einer Definition der spezifischen Review-Anforderungen herangezogen werden, sodass bei gleichem Zeitaufwand eine intensivere Auseinandersetzung mit einer konkreten Fragestellung möglich wird.

Arbeitsweise optimieren

Reviewer sollten außerdem darauf achten, nicht zu viel Code auf einmal zu inspizieren. Studienergebnisse haben gezeigt, dass eine Review von 200 bis 400 Zeilen Code in 60 bis 90 Minuten die besten Ergebnisse erzielt. Bei mehr als 500 Zeilen Code pro Stunde sinkt die Review-Qualität hingegen signifikant.

Checklisten helfen außerdem dabei, einen Standard für gute Code Reviews festzulegen. Ein Beispiel für eine solche Checkliste gibt es bei Gareth Wilson, der sich allerdings auf allgemeine Fehler und eine Review ohne inhaltlichen Fokus bezieht. Innerhalb eines Teams könnten aber eigene Checklisten erarbeitet werden, die zum Produkt und den dafür notwendigen Review-Prozessen passt. Für performanceorientierte Reviews könnte beispielsweise die Frage nach unnötigen Network-Calls und Datenbank-Zugriffen einen Platz auf der Liste finden.

Üben, üben, üben

Das alles ändert aber nichts daran, dass Reviewer Übung brauchen, um gute Reviews durchzuführen. Vor allem im Kontext der weiten Verbreitung von Ad-Hoc-Reviews ist es darum sinnvoll, das gesamte Entwicklerteam dazu zu ermutigen, ihren Code regelmäßig gegenseitig zu begutachten. Das hilft dabei, eine positive Review-Kultur zu etablieren und Sicherheit in dieser Hinsicht zu gewinnen. Dabei ist kein Codestück zu klein für eine Review – es geht nämlich nicht immer darum, unbedingt etwas ändern zu müssen, sondern auch darum, gegenseitig voneinander zu lernen. Wenn gute Code Reviews zum Standard werden, kann das einen echten Unterschied für die Produktqualität ausmachen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -