Ich führe nun schon seit über einem Jahrzehnt täglich Code-Reviews durch. Die Vorteile von Code-Reviews sind vielfältig: Jemand prüft Ihre Arbeit auf Fehler, Sie lernen von Ihrer Lösung und die Zusammenarbeit hilft, den Gesamtansatz der Organisation in Bezug auf Tools und Automatisierung zu verbessern. Wenn Sie derzeit keine Code-Reviews in Ihrer Organisation durchführen, sollten Sie jetzt damit beginnen. Es wird jeden zu einem besseren Ingenieur machen.
Zahlreiche Personen und Organisationen haben ihre Best Practices für Code-Reviews mitgeteilt und erklärt, was die Definition guter Code-Reviews für sie bedeutet. Leitfäden von Google, dem SmartBear-Team und dem Ingenieur Philipp Hauer sind alle sehr lesenswert. Im Folgenden finden Sie meine persönliche Meinung dazu, wie gute Code-Reviews aussehen und wie man sie auf Team- und Organisationsebene noch besser machen kann. Dies steht im Kontext der Tech-Umgebung, in der ich gearbeitet habe – derzeit bei Uber, und davor bei Skype/Microsoft und Skyscanner.
Gute Code-Reviews sind die Messlatte, die wir alle anstreben sollten. Sie umfassen gängige und einfach zu befolgende Best Practices, mit denen jedes Team beginnen kann, während sie langfristig hochwertige und hilfreiche Reviews sicherstellen.
Bessere Code-Reviews sind solche, bei denen Ingenieure die Art und Weise, wie sie Code-Reviews durchführen, ständig verbessern. Diese Code-Reviews betrachten die Code-Änderung im Kontext der Codebasis, der Person, die sie anfordert und in welcher Situation. Diese Reviews passen ihren Ansatz basierend auf dem Kontext und der Situation an. Das Ziel ist nicht nur ein qualitativ hochwertiges Review, sondern auch, den Entwicklern und Teams, die das Review anfordern, zu helfen, produktiver zu sein.
Bereiche, die vom Code Review abgedeckt werden
Gute Code Reviews betrachten die Änderung selbst und wie sie in die Codebasis passt. Sie schauen sich die Klarheit des Titels und der Beschreibung und das „Warum“ der Änderung an. Sie befassen sich mit der Korrektheit des Codes, der Testabdeckung, den Änderungen an der Funktionalität und bestätigen, dass sie den Coding Guides und Best Practices folgen. Sie werden auf offensichtliche Verbesserungen hinweisen, z. B. auf schwer verständlichen Code, unklare Namen, auskommentierten Code, ungetesteten Code oder nicht behandelte Randfälle. Sie werden auch bemerken, wenn zu viele Änderungen in ein Review gequetscht werden, und vorschlagen, die Code-Änderungen auf einen einzigen Zweck zu beschränken oder die Änderung in fokussiertere Teile aufzuteilen.
Bessere Code-Reviews betrachten die Änderung im Kontext des größeren Systems und prüfen, ob die Änderungen einfach zu warten sind. Sie stellen vielleicht Fragen über die Notwendigkeit der Änderung oder wie sie sich auf andere Teile des Systems auswirkt. Sie schauen sich die eingeführten Abstraktionen an und wie diese in die bestehende Software-Architektur passen. Sie notieren Beobachtungen zur Wartbarkeit, wie z.B. komplexe Logik, die vereinfacht werden könnte, die Verbesserung der Teststruktur, das Entfernen von Duplikaten und andere mögliche Verbesserungen. Der Ingenieur Joel Kemp beschreibt großartige Code-Reviews als einen kontextbezogenen Durchlauf, der einem ersten, leichten Durchlauf folgt.
Ton des Reviews
Der Ton von Code-Reviews kann die Moral innerhalb von Teams stark beeinflussen. Reviews mit einem harschen Ton tragen mit ihren Mikroaggressionen zu einem Gefühl einer feindlichen Umgebung bei. Eine rechthaberische Sprache kann Menschen in die Defensive treiben und hitzige Diskussionen entfachen. Gleichzeitig kann ein professioneller und positiver Ton zu einem integrativeren Umfeld beitragen. Menschen in diesen Umgebungen sind offen für konstruktives Feedback und Code-Reviews können stattdessen gesunde und lebhafte Diskussionen auslösen.
Gute Code-Reviews stellen offene Fragen, anstatt starke oder meinungsstarke Aussagen zu machen. Sie bieten Alternativen und mögliche Umgehungslösungen an, die für die Situation besser funktionieren könnten, ohne darauf zu bestehen, dass diese Lösungen der beste oder einzige Weg sind, um vorzugehen. Diese Reviews gehen davon aus, dass der Reviewer etwas übersehen haben könnte und bitten um Klärung statt um Korrektur.
Bessere Code Reviews sind auch einfühlsam. Sie wissen, dass die Person, die den Code schreibt, viel Zeit und Mühe in diese Änderung investiert hat. Diese Code-Reviews sind freundlich und unaufdringlich. Sie applaudieren netten Lösungen und sind rundum positiv.
Genehmigen vs. Änderungsanfragen
Wenn ein Reviewer sein Review abgeschlossen hat, kann er es entweder als genehmigt markieren, das Review mit Änderungsanfragen blockieren oder keinen bestimmten Status setzen und es im Zustand „noch nicht genehmigt“ belassen. Wie Reviewer die Status „Genehmigt“ und „Änderungsanforderung“ verwenden, ist bezeichnend für die Code-Reviews.
Gute Code-Reviews genehmigen keine Änderungen, solange es offene Fragen gibt. Sie machen jedoch deutlich, welche Fragen oder Kommentare nicht blockierend oder unwichtig sind, und markieren sie deutlich. Sie sind explizit, wenn sie eine Änderung genehmigen – z.B. indem sie einen Daumen hoch Kommentar wie „sieht gut aus!“ hinzufügen. Mancherorts werden Akronyme wie LGTM verwendet – diese funktionieren auch, aber seien Sie sich bewusst, dass Neulinge diese Insider Akronyme für etwas anderes missverstehen könnten. Gute Code-Reviews sind ebenso explizit, wenn sie eine Nachbereitung fordern, und verwenden das Code-Review-Tool oder die Team-Konvention, um dies zu kommunizieren.
Bessere Code-Reviews sind fest im Prinzip, aber flexibel in der Praxis: Manchmal werden bestimmte Kommentare vom Autor mit einer separaten, nachfolgenden Code-Änderung angesprochen. Für Änderungen, die dringender sind als andere, versuchen die Reviewer sich für schnellere Reviews zur Verfügung zu stellen.
Von Code-Reviews zum Miteinander-Reden
Code-Reviews werden normalerweise asynchron und schriftlich über ein Code-Review-Tool durchgeführt. Dies geschieht in der Regel aus Bequemlichkeit, um Code-Reviews aus der Ferne zu ermöglichen und um mehreren Personen die Möglichkeit zu geben, dieselbe Codeänderung zu überprüfen. Aber wann ist es an der Zeit, das Tool nicht mehr zu benutzen, wie gut es auch sein mag, und anzufangen, von Angesicht zu Angesicht über den Code zu sprechen?
Gute Code-Reviews hinterlassen so viele Kommentare und Fragen, wie nötig sind. Wenn die Überarbeitung nicht auf alle eingeht, werden sie auch diese notieren. Wenn die Konversation zu einem langen Hin und Her wird, werden die Reviewer versuchen, zu einem persönlichen Gespräch mit dem Autor überzugehen, anstatt noch mehr Zeit mit dem Code-Review-Tool zu vergeuden.
Bessere Code-Reviews gehen proaktiv auf die Person zu, die die Änderung vornimmt, nachdem sie einen ersten Durchlauf des Codes gemacht haben und viele Kommentare und Fragen haben. Diese Leute haben gelernt, dass sie auf diese Weise eine Menge Zeit, Missverständnisse und harte Gefühle sparen. Die Tatsache, dass es viele Kommentare zum Code gibt, deutet darauf hin, dass es wahrscheinlich einige Missverständnisse auf beiden Seiten gibt. Diese Art von Missverständnissen lassen sich leichter erkennen und auflösen, wenn man die Dinge durchspricht.
Nitpicks
Nitpicks sind unwichtige Kommentare, bei denen der Code zusammengefügt werden könnte, ohne dass sie überhaupt angesprochen werden. Das können Dinge sein, wie Variablendeklarationen in alphabetischer Reihenfolge, Unit-Tests, die einer bestimmten Struktur folgen, oder Klammern, die in der gleichen Zeile stehen.
Gute Code-Reviews machen deutlich, wenn Änderungen unwichtige Nitpicks sind. Sie markieren solche Kommentare normalerweise deutlich, indem sie ihnen das Präfix „nit:“ voranstellen. Zu viele davon können frustrierend sein und die Aufmerksamkeit von den wichtigeren Teilen des Reviews ablenken, also versuchen die Reviewer, es mit diesen nicht zu übertreiben.
Bessere Code-Reviews erkennen, dass zu viele Nitpicks ein Zeichen von mangelnden Werkzeugen oder fehlenden Standards sind. Reviewer, die häufig auf diese stoßen, werden versuchen, dieses Problem außerhalb des Code-Review-Prozesses zu lösen. Zum Beispiel können viele der üblichen Nitpick-Kommentare durch automatisches Linting gelöst werden. Diejenigen, die nicht gelöst werden können, können in der Regel dadurch gelöst werden, dass das Team sich auf bestimmte Standards einigt und diese befolgt – vielleicht sogar automatisiert, irgendwann.
Code Reviews für Neueinsteiger
Der Start in einer neuen Firma ist für die meisten Leute überwältigend. Die Codebasis ist neu, der Stil der Programmierung ist anders als vorher, und die Leute überprüfen Ihren Code ganz anders. Sollten also Code-Reviews für Neueinsteiger sanfter sein, um sie an die neue Umgebung zu gewöhnen, oder sollten sie die Messlatte genauso hoch halten, wie für alle anderen?
Gute Code-Reviews verwenden die gleiche Qualitätslatte und den gleichen Ansatz für alle, unabhängig von der Stellenbezeichnung, dem Level oder dem Zeitpunkt des Eintritts in das Unternehmen. Demnach haben Code-Reviews einen freundlichen Ton, fordern bei Bedarf Änderungen an und gehen auf die Reviewer zu, wenn sie viele Kommentare haben.
Bessere Code-Reviews achten zusätzlich darauf, dass die ersten paar Reviews für Neueinsteiger eine tolle Erfahrung sind. Die Reviewer haben Verständnis für die Tatsache, dass der neue Teilnehmer vielleicht nicht alle Codierungsrichtlinien kennt und mit Teilen des Codes nicht vertraut ist. Diese Bewertungen geben sich zusätzliche Mühe, alternative Ansätze zu erklären und auf Anleitungen zu verweisen. Sie sind auch sehr positiv im Ton, und feiern die ersten paar Änderungen an der Codebasis, die der Autor vorschlägt.
Büro- und zeitzonenübergreifende Reviews
Code-Reviews werden schwieriger, wenn die Reviewer nicht am selben Ort sind. Sie sind besonders herausfordernd, wenn die Reviewer in sehr unterschiedlichen Zeitzonen sitzen. Ich habe im Laufe der Jahre meinen Anteil an solchen Reviews gehabt, indem ich Code von Teams in den USA und Asien modifiziert habe, während ich in Europa ansässig war.
Gute Code-Reviews berücksichtigen den Zeitzonenunterschied, wenn sie können. Die Reviewer versuchen, den Code in den sich überschneidenden Arbeitszeiten zwischen den Büros zu überprüfen. Bei Reviews mit vielen Kommentaren bieten die Reviewer an, direkt zu chatten oder einen Videoanruf zu machen, um Änderungen durchzusprechen.
Bessere Code-Reviews bemerken, wenn Code-Reviews wiederholt in Zeitzonen-Probleme geraten und suchen nach einer systemischen Lösung, außerhalb des Code-Review-Rahmens. Nehmen wir an, ein Team aus Europa ändert häufig einen Dienst, der Code-Reviews des in den USA ansässigen Besitzers dieses Dienstes auslöst. Die Frage auf Systemebene ist, warum diese Änderungen so häufig vorkommen. Werden die Änderungen in der richtigen Codebase durchgeführt oder sollte ein anderes System geändert werden? Wird die Häufigkeit der Änderungen gleich bleiben oder mit der Zeit abnehmen? Angenommen, die Änderungen werden in der richtigen Codebasis durchgeführt und die Häufigkeit wird nicht abnehmen, kann die büroübergreifende Abhängigkeit auf irgendeine Art und Weise unterbrochen werden? Lösungen für diese Art von Problemen sind oft nicht einfach und könnten Refactoring, die Erstellung neuer Dienste/Schnittstellen oder Tooling-Verbesserungen beinhalten. Aber das Lösen solcher Abhängigkeiten macht das Leben beider Teams einfacher und ihren Fortschritt langfristig effizienter, was bedeutet, dass der Return on Investment oft recht beeindruckend ist.
Organisatorische Unterstützung
Die Art und Weise, wie Unternehmen und ihre Entwicklungsorganisationen an Code-Reviews herangehen, ist ein großes Element dafür, wie effizient sie sein können. Organisationen, die sie als unwichtig und trivial ansehen, investieren am Ende wenig in die Erleichterung von Reviews. In solchen Kulturen könnte es verlockend sein, Code-Reviews einfach ganz abzuschaffen. Ingenieure, die sich für bessere Code-Reviews einsetzen, fühlen sich vielleicht isoliert, ohne Unterstützung von oben und geben schließlich auf. Das Ergebnis ist eine Organisation, in der sich Probleme ständig wiederholen und sich selbst verstärken.
Organisationen mit guten Code-Reviews stellen sicher, dass alle Ingenieure am Code-Review-Prozess teilnehmen – auch diejenigen, die vielleicht an Einzelprojekten arbeiten. Sie ermutigen dazu, die Qualitätslatte höher zu legen, und die Teams fördern gesunde Diskussionen über Code-Review-Ansätze sowohl auf Team- als auch auf Organisationsebene. Diese Unternehmen haben oft Code-Review-Guides für größere Codebasen, die von Ingenieuren initiiert und geschrieben wurden. Organisationen wie diese erkennen, dass Code-Reviews einen guten Teil der Zeit der Ingenieure in Anspruch nehmen. Viele dieser Unternehmen fügen Code-Reviews als Erwartungen zu den Job-Kompetenzen von Entwicklern hinzu und erwarten, dass leitende Ingenieure einen größeren Teil ihrer Zeit damit verbringen, den Code anderer zu überprüfen.
Organisationen mit besseren Code-Reviews haben harte Regeln, dass kein Code ohne Code-Review in die Produktion geht – genauso wie Änderungen der Geschäftslogik nicht ohne automatisierte Tests in die Produktion gehen. Diese Organisationen haben gelernt, dass es sich nicht lohnt, an der falschen Stelle zu sparen; stattdessen haben sie Prozesse für beschleunigte Reviews für dringende Fälle. Diese Unternehmen investieren in die Produktivität der Entwickler und arbeiten kontinuierlich an der Entwicklung effizienterer Code-Reviews und Tooling-Verbesserungen. Hilfreiche technische Führungskräfte müssen nicht von den Vorteilen von Code-Reviews und anderen technischen Best Practices überzeugt werden. Stattdessen unterstützen sie Initiativen zu besseren Werkzeugen oder effizienteren Code-Review-Prozessen, die von den Teams ausgehen.
Wenn Mitarbeiter auf Reviews stoßen, die sich feindselig anfühlen, haben sie das Gefühl, dass sie das Thema ansprechen können und von allen Seiten unterstützt werden, um das Problem zu lösen. Ältere Ingenieure und Manager betrachten Code-Reviews, die den Anforderungen nicht gerecht werden, genauso als Problem wie schlampigen Code oder schlechtes Verhalten. Sowohl Ingenieure als auch technische Manager fühlen sich befugt, die Durchführung von Code-Reviews zu verbessern.
Beginnen Sie mit dem Guten, machen Sie es besser
Gute Code-Reviews haben bereits eine Menge guter Arbeit hinter sich. Sie führen eine gründliche Überprüfung der Änderung selbst durch, vermeiden einen rechthaberischen Ton in den Kommentaren und machen Nitpicks deutlich. Sie halten eine einheitliche Messlatte aufrecht, unabhängig davon, wer die Überprüfung anfordert und versuchen, zeitzonenübergreifende Überprüfungen weniger schmerzhaft zu machen, indem sie diesen zusätzliche Aufmerksamkeit schenken. Organisationen die gute Reviews haben, stellen sicher, dass jeder Entwickler regelmäßig Code-Reviews erhält und durchführt. Dies ist bereits eine hohe Messlatte – aber wenn Sie hier ankommen, hören Sie nicht auf. Code-Reviews sind eine der besten Möglichkeiten, Ihre Fähigkeiten zu verbessern, andere zu beraten und zu lernen, wie man ein effizienterer Kommunikator ist.
Gehen Sie zu besseren Code-Reviews, indem Sie kontinuierlich an den Details feilen, aber fangen Sie auch an, Änderungen auf einer hohen Ebene zu betrachten. Seien Sie einfühlsam im Ton der Kommentare und überlegen Sie sich Wege außerhalb des Code-Review-Prozesses, um häufige Erbsenzählerei zu vermeiden. Machen Sie Code-Reviews besonders einladend für Neueinsteiger und suchen Sie nach systemischen Lösungen für schmerzhafte zeitzonenübergreifende Reviews. Unternehmen, die zukunftsorientiert sind, investieren in Werkzeuge und Prozessverbesserungen, um Code-Reviews besser zu machen, und ernten so mehr von den Vorteilen.
—
Gergely ist derzeit Engineering Lead in Amsterdam. Dieser Blogbeitrag erschien ursprünglich auf Gergelys Blog, The Pragmatic Engineer. Wenn Sie mehr von Gergely lesen möchten, können Sie seinen monatlichen Newsletter für seine Artikel über Engineering, Tech Leadership und verteilte Systeme abonnieren. Wenn Sie Artikel zum Stack Overflow-Blog beitragen möchten, senden Sie eine E-Mail an [email protected].
Tags: bulletin, code review, Technik, Softwareentwicklung