Codeüberprüfungen sind ein wichtiger Bestandteil des modernen Softwarelebenszyklus. Leider werden viele Zyklen vergeudet und die Moral leidet, weil Prüfern (und Prüflingen) nur wenige Richtlinien für konstruktives Feedback und effektive schriftliche Kommunikation gegeben werden. Im Folgenden finden Sie einige Tipps für einen besseren Codeüberprüfungsprozess.

Bestimmen Sie, warum Sie Codeüberprüfungen durchführen

Geht es darum, Fehler zu finden? Geht es darum, Wissen über die Codebasis zu verbreiten? Geht es darum, Architekturprobleme zu finden? Was bieten Codeüberprüfungen Ihrem Team? Wenn Sie die Antwort auf diese Frage nicht kennen, wissen Sie nicht, wie gut sie funktionieren.

Am besten besprechen Sie dies am besten explizit mit Ihrem Team. Es ist in Ordnung, dass Teams sie für unterschiedliche Dinge verwenden, aber es ist sehr wichtig, dass sowohl der Autor als auch der Prüfer wissen, was das erwartete Ergebnis einer Überprüfung ist.

Innerhalb unseres Teams gehe ich davon aus, dass ich Code hauptsächlich teile, um das Wissen über Änderungen an Codebasen zu verbreiten und um sicherzustellen, dass ich nichts unglaublich Dummes mache. Manchmal brauche ich die Anleitung eines Experten (zum Beispiel bei der Front-End-Arbeit oder bei Diensten, in die ich selten hineinschnüffle). Normalerweise versuche ich, dies zu bekommen, bevor ich jemanden in einem PR tagge. Wenn dies geschieht, ist es meiner Meinung nach am besten, ausdrücklich anzuerkennen, dass Sie erwarten, dass diese Person der Experte ist, damit sie sich die Sache genauer ansehen und Ihnen vielleicht bei einer Bereitstellung helfen kann.

Automatisieren Sie Ihren Styleguide

Wenn die Antwort auf die Frage „Warum führen Sie Code-Reviews durch?“ beinhaltet, „sicherzustellen, dass der Code einem einheitlichen Stil folgt“, dann lassen Sie es weg. Es ist schwierig, Code zu überprüfen, der schlecht formatiert ist. Und es ist wirklich, wirklich schwierig, Code sowohl auf Korrektheit als auch auf Stil zu überprüfen, ohne mehrere Durchgänge zu machen. Außerdem ist es für neue Ingenieure in einem Projekt sehr demoralisierend, ihren PR anzuschauen und Dutzende von Stilkommentaren zu sehen. Es gibt großartige automatisierte Stiltools, die Ihren Code automatisch stylen können, und Sie sollten diese verwenden. In meinem speziellen Team versuchen wir, Scalariform für unsere Scala-Sachen und Rubocop für unsere Ruby-Projekte zu verwenden. Im Jahr 2017 sollten Ingenieure Formatierungsprobleme unter keinen Umständen manuell beheben.

Als Fallback ist es in Fällen, in denen keine Automatisierung eingerichtet wurde, am besten, wenn der Prüfer die Formatierung selbst korrigiert, anstatt dem Autor Kommentare hinzuzufügen (dies gilt doppelt, wenn Sie Code für Ihren eigenen Teamkollegen prüfen). Kleine Dinge können direkt in der GitHub-Benutzeroberfläche erledigt werden, und wir sollten nicht davor zurückschrecken, ein paar sinnlose Commits hinzuzufügen, die vor dem Zusammenführen ohnehin zusammengedrückt werden.

Machen Sie Vorschläge, keine Befehle

Sagen Sie einem Committer in einer Codeüberprüfungsbemerkung nicht, dass er etwas falsch gemacht hat. Machen Sie einen Vorschlag und fragen Sie ihn, was er davon hält. Sehen Sie sich beispielsweise die folgenden Kommentare an:

Wiederholen Sie dies hier nicht, extrahieren Sie eine Funktion.

Das fühlt sich offensichtlich sehr negativ an. Der Autor könnte sich in die Defensive gedrängt fühlen und eine sinnlose Diskussion beginnen, auch wenn dies kaum Vorteile bringt; oder schlimmer noch, der Autor könnte sich als weniger wertvoller Beitragender fühlen und dem Vorschlag blind folgen. In beiden Fällen richten Kommentare wie dieser tatsächlich 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 (auch wenn Sie wirklich ein Gatekeeper sind).

Was halten Sie davon, dies mit dem oben Gesagten zu übernehmen und eine Funktion zu extrahieren?

Warum sollten Ihre Kommentare so zögerlich klingen? Weil Sie den Code Ihres Kollegen überprüfen. Sie müssen ihn auffordern, höflich zu erklären, was los ist, oder ihm mitzuteilen, dass Sie einen besseren Vorschlag gemacht haben. Wenn Sie in dieser Hinsicht keine Manieren haben, wird die Möglichkeit einer Diskussion für einen erheblichen Teil der Bevölkerung ausgeschlossen.

Lassen Sie uns über mein größtes Ärgernis bei Code-Reviews sprechen …

Warum hast du nicht…

Fragen Sie einen „ Warum hast du nicht ”-Frage impliziert sehr viele Dinge, von denen keines konstruktiv oder positiv ist. Sie setzt voraus, dass der Autor des Codes Ihren Vorschlag zuvor in Betracht gezogen und sich explizit für einen anderen entschieden hat, was möglicherweise nicht der Fall ist. Sie impliziert, dass Ihre Alternative offensichtlich besser ist (insbesondere im Sonderfall von „ warum hast du nicht einfach … “), und dass Sie verlangen, dass der Autor seine Lösung dagegen rechtfertigt. Das impliziert, dass das, was als bloßer Vorschlag gedacht sein könnte, in Wirklichkeit die Standardlösung ist.

Immer wenn ich Code überprüfe und mein Hochmut überprüft werden muss, versuche ich, einen Vorschlag zu machen.“ Wie fühlen Sie sich in Bezug auf … ' oder ' Was denkst du über… “ sind gute Ersatzworte für diese Phrase.

Verwenden Sie eine ausgesprochen positive Sprache

Es ist wichtig zu erkennen, dass schriftliche Kommunikation eine zutiefst negative Tendenz hat. Wir neigen dazu, neutrale Kommunikation als negativ und positive Kommunikation als neutral zu interpretieren, was bei Codeüberprüfungen zu großer Bestürzung führt. Um dem entgegenzuwirken, streben Sie nach offener Positivität.

Knappheit kann als unhöflich oder rücksichtslos ausgelegt werden. Vermeiden Sie insbesondere Kommentare mit zwei oder drei Wörtern.

Verwenden Sie Code-Reviews als Lernübung

Meine echte, nicht durch Daten unterstützte Meinung ist, dass die Qualität und Korrektheit des Codes nur geringfügig verbessert wird, wenn ein Code von einem Gatekeeper überprüft wird. Es kommt selten vor, dass ein Prüfer über die gleiche Kenntnis verfügt wie die Person, die den Code erstellt hat (na ja, außer bei der oben erwähnten „Überprüfung durch einen Experten“). Ein besseres Modell besteht darin, Codeüberprüfungen als Lernübung für den Prüfer zu betrachten, d. h. um die Änderungen am Code zu verstehen und sein Verständnis der Codebasis zu erweitern. Ich denke, diese Nivellierung verleiht ihren Fragen und Anmerkungen das entsprechende Gewicht und ermöglicht eine gesündere Diskussion über die größere Codebasis und wie die Änderungen mit ihr interagieren.

Natürlich müssen Sie nichts davon tun, um in Ihren Bewertungen netter zu sein.

Beim Empfang einer Codeüberprüfung

Um eine Codeüberprüfung zu erhalten, sollten Sie dieselben Vorschläge in umgekehrter Reihenfolge befolgen. Machen Sie sich bewusst, dass knappe Kommentare nicht bedeuten, dass der Prüfer weniger von Ihnen hält. Machen Sie sich bewusst, dass „Befehle“ normalerweise nur schlecht formulierte Vorschläge sind und eine Einladung an Sie, über das Problem auf eine (möglicherweise andere) Weise nachzudenken. Machen Sie sich bewusst, dass so ziemlich alles Geschriebene negativer rüberkommt als beabsichtigt, und geben Sie Ihren Teamkollegen viel Spielraum.

Man kann sich leicht vorstellen, dass brutale Codeüberprüfungen ein Ritual sind, das zu den besten Ergebnissen führt. Meiner Erfahrung nach reagieren Ingenieure viel sensibler auf Kritik, als sie zugeben, und sie sind viel eher bereit, Fehler zuzugeben, wenn sie sich als Kollaborateure und nicht als Angeklagte fühlen. Nehmen Sie sich ein paar Minuten mehr Zeit, um Ihren Überprüfungen etwas mehr Freundlichkeit zu verleihen, und ich denke, Sie werden feststellen, dass Ihre Überprüfungen viel produktiver sind und Sie sich am Ende des Tages besser fühlen.

^{*Dieser Beitrag erschien ursprünglich auf Cory Chamblins persönlicher Blog . Wir dachten, es wäre hilfreich für unsere Blog-Leser und haben daher beschlossen, es auch hier zu teilen.}