Code-Reviews sind ein wichtiger Bestandteil des modernen Software-Lebenszyklus. Leider werden viele Zyklen verschwendet und die Motivation leidet, weil es nur wenige Richtlinien für Reviewer (und Reviewees) zu konstruktivem Feedback und effektiver schriftlicher Kommunikation gibt. Im Folgenden finden Sie einige Tipps für einen besseren Code-Review-Prozess.

Ermitteln Sie, warum Sie Code-Reviews durchführen.

Dienen sie dazu, Fehler zu finden? Dienen sie dazu, das Wissen über die Codebasis zu verbreiten? Dienen sie dazu, Architekturprobleme aufzudecken? Was bringen Code-Reviews Ihrem Team? Wenn Sie diese Frage nicht beantworten können, wissen Sie nicht, wie gut sie funktionieren.

Am besten besprechen Sie das direkt mit Ihrem Team. Es ist in Ordnung, wenn Teams die Tools für unterschiedliche Zwecke nutzen, aber es ist sehr wichtig, dass sowohl der Autor als auch der Reviewer wissen, welches Ergebnis von einem Review erwartet wird.

Innerhalb unseres Teams erwarte ich, dass ich Code hauptsächlich teile, um das Wissen über Änderungen an der Codebasis zu verbreiten und um sicherzustellen, dass ich keine groben Fehler mache. Manchmal benötige ich fachliche Unterstützung (zum Beispiel bei der Frontend-Entwicklung oder bei Diensten, mit denen ich mich selten beschäftige). Normalerweise versuche ich, diese zu erhalten, bevor ich jemanden in einem Pull Request markiere. In solchen Fällen halte ich es für ratsam, explizit darauf hinzuweisen, dass man von dieser Person Fachkenntnisse erwartet, damit sie sich das genauer ansehen und gegebenenfalls beim Deployment helfen kann.

Automatisieren Sie Ihren Styleguide

Wenn die Antwort auf die Frage „Warum führt man Code-Reviews durch?“ lautet: „Um sicherzustellen, dass der Code einem einheitlichen Stil entspricht“, dann lassen Sie das. Es ist schwierig, schlecht formatierten Code zu überprüfen. Und es ist wirklich extrem schwierig, Code ohne mehrere Durchgänge sowohl auf Korrektheit als auch auf Stil zu prüfen. Außerdem ist es für neue Entwickler in einem Projekt sehr demotivierend, Dutzende von Stilkommentaren in ihrem Pull Request zu finden. Es gibt hervorragende automatisierte Stilwerkzeuge, die Ihren Code automatisch formatieren können, und Sie sollten diese nutzen. In meinem Team verwenden wir Scalariform für unsere Scala-Projekte und Rubocop für unsere Ruby-Projekte. Unter keinen Umständen sollten Ingenieure im Jahr 2017 Formatierungsprobleme manuell beheben.

Falls keine Automatisierung eingerichtet ist, sollte der Reviewer die Formatierung am besten selbst korrigieren, anstatt dem Autor Kommentare hinzuzufügen (dies gilt insbesondere für Code-Reviews von Teammitgliedern). Kleinere Änderungen lassen sich direkt in der GitHub-Benutzeroberfläche vornehmen, und wir sollten uns nicht scheuen, ein paar unnötige Commits hinzuzufügen, die ohnehin vor dem Mergen wieder zusammengeführt werden.

Vorschläge machen, keine Befehle.

Weisen Sie einen Mitwirkenden in einem Code-Review-Kommentar nicht darauf hin, was er falsch gemacht hat. Machen Sie stattdessen einen Verbesserungsvorschlag und fragen Sie nach seiner Meinung dazu. Sehen Sie sich beispielsweise die folgenden Kommentare an:

Das hier nicht wiederholen, sondern eine Funktion extrahieren.

Das wirkt eindeutig sehr negativ. Der Autor könnte sich angegriffen fühlen und eine sinnlose Auseinandersetzung beginnen, selbst wenn diese kaum Vorteile bringt; oder schlimmer noch, er könnte sich als weniger wertvoller Beitragender fühlen und dem Vorschlag blind folgen. In beiden Fällen richten solche Kommentare Schaden an.

Das Beste, was Sie tun können, ist, einen Vorschlag zu machen, nicht als Gatekeeper, sondern als jemand, der versucht, mehr über die Änderungen am Code zu erfahren (selbst wenn Sie in Wirklichkeit ein Gatekeeper sind).

Was halten Sie davon, dies mit dem oben Genannten zu kombinieren und eine Funktion daraus zu extrahieren?

Warum sollten Ihre Kommentare so zurückhaltend klingen? Weil Sie den Code Ihres Kollegen überprüfen. Sie sollten ihn höflich dazu einladen, die Situation zu erklären oder auf Ihren besseren Vorschlag hinzuweisen. Unhöfliches Verhalten in dieser Hinsicht schließt einen erheblichen Teil der Nutzer von der Diskussion aus.

Lasst uns über meinen größten Kritikpunkt bei Code-Reviews sprechen…

Warum hast du nicht…

Eine Frage stellen Warum hast du nicht Die Frage impliziert vieles, was weder konstruktiv noch positiv ist. Sie setzt voraus, dass der Autor des Codes Ihren Vorschlag bereits geprüft und sich explizit für einen anderen entschieden hat, was möglicherweise nicht der Fall ist. Sie impliziert, dass Ihre Alternative offensichtlich überlegen ist (insbesondere im Sonderfall von „ Warum hast du nicht einfach… “), und dass Sie vom Autor verlangen, seine Lösung dagegen zu begründen. Dies impliziert, dass das, was als bloßer Vorschlag gedacht war, in Wirklichkeit die Standardeinstellung ist.

Immer wenn ich Code überprüfe und meine Überheblichkeit hinterfragt werden muss, versuche ich, einen Verbesserungsvorschlag zu machen. Wie stehen Sie zu…? ' oder ' Was denkst du darüber… „“ sind gute, direkte Ersatzlösungen für diese Formulierung.

Verwenden Sie eine ausgesprochen positive Sprache.

Es ist wichtig zu erkennen, dass schriftliche Kommunikation eine stark negative Tendenz aufweist. Wir neigen dazu, neutrale Aussagen als negativ und positive als neutral zu interpretieren, was bei Code-Reviews oft zu Verwirrung führt. Um dem entgegenzuwirken, sollte man eine ausgesprochen positive Ausdrucksweise anstreben.

Kurz angebundenheit kann als unhöflich oder rücksichtslos aufgefasst werden. Vermeiden Sie insbesondere Kommentare, die nur aus zwei oder drei Wörtern bestehen.

Nutzen Sie Code-Reviews als Lernübung

Meine ehrliche, nicht durch Daten belegte Meinung ist, dass Codequalität und Korrektheit durch Code-Reviews von externen Prüfern nur geringfügig verbessert werden. Es kommt selten vor, dass ein Prüfer über das gleiche Fachwissen verfügt wie der Autor des Codes (außer natürlich bei den bereits erwähnten „Experten-Reviews“). Ein besseres Modell ist es, Code-Reviews als Lernprozess für den Prüfer zu gestalten, um die Codeänderungen zu verstehen und sein Verständnis der Codebasis zu vertiefen. Ich denke, diese Einstufung verleiht seinen Fragen und Anmerkungen das angemessene Gewicht und ermöglicht eine konstruktivere Diskussion über die gesamte Codebasis und die Wechselwirkungen der Änderungen.

Natürlich müssen Sie das alles nicht tun, um in Ihren Rezensionen freundlicher zu sein.

Wenn Sie eine Codeüberprüfung erhalten

Wenn Sie eine Code-Review erhalten, sollten Sie die gleichen Empfehlungen in umgekehrter Reihenfolge befolgen. Bedenken Sie, dass knappe Kommentare nicht bedeuten, dass der Reviewer weniger von Ihnen hält. Sehen Sie „Anweisungen“ meist nur schlecht formulierte Vorschläge und eine Einladung, das Problem aus einer (möglicherweise anderen) Perspektive zu betrachten. Seien Sie sich bewusst, dass fast alles Geschriebene negativer wirkt als beabsichtigt, und geben Sie Ihren Teamkollegen viel Freiraum.

Man könnte meinen, gnadenlose Code-Reviews seien ein Ritual, das zu den besten Ergebnissen führt. Meine Erfahrung zeigt jedoch, dass Entwickler viel sensibler auf Kritik reagieren, als sie zugeben, und viel eher bereit sind, Fehler einzugestehen, wenn sie sich als Partner und nicht als Ankläger fühlen. Nehmen Sie sich ein paar Minuten mehr Zeit, um Ihre Reviews freundlicher zu gestalten. Sie werden feststellen, dass sie dadurch deutlich produktiver werden und Sie sich am Ende des Tages besser fühlen.

^{Dieser Beitrag erschien ursprünglich auf Cory Chamblins persönlicher Blog Wir dachten, es könnte für unsere Blogleser hilfreich sein, deshalb haben wir beschlossen, es auch hier zu teilen.}