Code Review Best Practices: How to Review (and Be Reviewed) — txt1.ai

Ich erinnere mich noch an das Code-Review, das mich fast dazu gebracht hätte, die Softwareentwicklung aufzugeben. Es war 2012, ich war sechs Monate in meinem ersten Job bei einem Fintech-Startup, und ich hatte gerade das eingereicht, was ich für eine brillante Umstrukturierung unseres Zahlungssystem hielt. Die Rückmeldung des Senior Engineers kam mit 47 Kommentaren zurück—die meisten davon Variationen von "das ist falsch" ohne Erklärung. Ich habe drei Tage damit verbracht, alles neu zu schreiben, nur um denselben Prüfer zu haben, der es mit einem einzigen Wort genehmigte: "In Ordnung." Diese Erfahrung hat mir nichts darüber beigebracht, wie man besseren Code schreibt, aber alles darüber, wie man ein Code-Review NICHT durchführt.

Spulen wir zwölf Jahre vor, und ich bin jetzt Principal Engineer bei einem SaaS-Unternehmen der Serie C, habe über 8.000 Pull Requests überprüft und 40+ Entwickler durch den Code-Review-Prozess begleitet. Ich habe gesehen, wie Code-Reviews Unternehmen von katastrophalen Bugs gerettet haben, und ich habe erlebt, wie sie die Team-Moral so gründlich zerstört haben, dass ganze Ingenieurabteilungen innerhalb von sechs Monaten gewechselt wurden. Der Unterschied? Nicht die Qualität des zu überprüfenden Codes, sondern die Qualität des Überprüfungsprozesses selbst.

Code-Review ist gleichzeitig eines der mächtigsten Werkzeuge in der Softwareentwicklung und eines der häufigsten Missbrauchs. Laut dem SmartBear-Bericht "State of Code Review 2023" fangen Teams, die strukturierte Code-Review-Prozesse implementieren, 60-90% der Mängel vor der Produktion ab, dennoch zeigt dieselbe Forschung, dass 73% der Entwickler negative Erfahrungen mit Code-Reviews berichten, die ihr Vertrauen oder ihre Beziehungen zu Teamkollegen geschädigt haben. Dieses Paradoxon existiert, weil die meisten Teams sich darauf konzentrieren, WAS zu überprüfen, anstatt WIE zu überprüfen.

Die Psychologie des Code-Reviews: Warum die meisten Reviews scheitern, bevor sie beginnen

Hier ist, was dir niemand über Code-Reviews sagt: Sie beziehen sich nicht in erster Linie auf Code. Sie betreffen Menschen. Jede Pull-Anfrage repräsentiert Stunden intellektueller Mühe, kreativen Problemlösens und beruflicher Identität. Wenn du Code überprüfst, bewertest du nicht nur Logik und Syntax—du beschäftigst dich mit einem Produkt der Arbeit eines anderen Menschen in einer Weise, die ihn entweder aufbaut oder niederreißt.

Ich habe das auf die harte Tour gelernt, nachdem ich ein Exit-Gespräch mit einer talentierten Junior-Entwicklerin geführt habe, die unser Team verlassen hat. Sie erzählte mir, dass ein einzelner abwertender Kommentar zu der Code-Überprüfung—"Warum hättest du es überhaupt so machen sollen?"—sie dazu brachte, zu hinterfragen, ob sie im Ingenieurwesen dazugehört. Der Prüfer hatte es als ernsthafte Frage gemeint, neugierig auf ihr Denken. Sie interpretierte es als Urteil. Das war der Moment, in dem ich erkannte, dass das Medium asynchroner Texte Ton, Gesichtsausdrücke und Körpersprache wegnimmt und nur Worte übrig lässt, die im schlechtesten Licht interpretiert werden können.

Die psychologischen Forschungen unterstützen dies. Eine im Jahr 2021 veröffentlichte Studie in den IEEE Transactions on Software Engineering zeigte, dass Code-Review-Kommentare, die als hart oder abwertend wahrgenommen werden, die Zeit bis zur Zusammenführung im Durchschnitt um 3,2 Tage erhöhen und die Wahrscheinlichkeit, dass der Autor künftige Verbesserungen beisteuert, um 34% verringern. Umgekehrt führten Reviews, die spezifisches Lob zusammen mit konstruktivem Feedback enthielten, zu einer 28% schnelleren Iterationszeit und einer 41% höheren Codequalität in nachfolgenden Einreichungen desselben Autors.

Das bedeutet nicht, dass wir alles beschönigen oder vermeiden sollten, Probleme aufzuzeigen. Es bedeutet, dass wir Code-Reviews mit einer Absicht auf die Person auf der anderen Seite angehen müssen. Bevor ich einen Kommentar für eine Überprüfung schreibe, stelle ich mir drei Fragen: Ist das wahr? Ist das notwendig? Ist das freundlich? Wenn ich nicht auf alle drei Fragen mit Ja antworten kann, schreibe ich den Kommentar um. Dieser einfache Filter hat verändert, wie mein Team kommuniziert, und hat unsere durchschnittliche PR-Zykluszeit in den letzten zwei Jahren von 4,3 Tagen auf 1,8 Tage reduziert.

Die Checkliste des Prüfers: Worauf man tatsächlich achten sollte

Wenn ich neue Prüfer ausbilde, stellen sie immer die gleiche Frage: "Worauf sollte ich achten?" Die Antwort ist keine einfache Liste von Syntaxregeln oder Stilrichtlinien—die sollten automatisiert werden. Deine Aufgabe als menschlicher Prüfer besteht darin, die Dinge zu bewerten, die Maschinen nicht können: Designentscheidungen, Wartbarkeit und die Korrektheit der Geschäftlogik.

Ich verwende ein Vier-Stufen-Prioritätssystem, das mir hilft, meine Überprüfungsenergie dort zu konzentrieren, wo sie am meisten erforderlich ist. Stufe 1 Probleme sind Blocker: Sicherheitsanfälligkeiten, Risiken eines Datenverlusts oder Breaking Changes, die zu Produktionsvorfällen führen werden. Diese werden sofort mit klaren Erklärungen des Risikos gekennzeichnet. In meiner Erfahrung treten echte Stufe 1 Probleme in weniger als 5% der Pull Requests auf, aber wenn sie auftreten, ist das Auffinden der Grund, warum wir Code-Reviews machen.

Stufe 2 Probleme sind architektonische Bedenken: Code, der funktioniert, aber technische Schulden einführt, erprobte Muster verletzt oder zukünftige Änderungen erschwert. Diese sind am schwierigsten zu überprüfen, da sie erfordern, sowohl den aktuellen Code als auch die zukünftige Richtung des Teams zu verstehen. Ich habe festgestellt, dass es besser funktioniert, diese als Fragen und nicht als Anweisungen zu formulieren: "Ich bin besorgt, dass dieser Ansatz es schwieriger machen könnte, Feature X im nächsten Quartal umzusetzen—hast du in Betracht gezogen, stattdessen Muster Y zu verwenden?" Das lädt zur Diskussion ein, anstatt zur Abwehr.

Stufe 3 Probleme sind Verbesserungen der Lesbarkeit und Wartbarkeit: unklare Variablennamen, fehlende Kommentare zu komplexer Logik oder Funktionen, die zur Klarheit aufgebrochen werden könnten. Diese sind wichtig, aber sie sind nicht dringend. Ich beschränke mich typischerweise auf drei Stufe 3 Kommentare pro Überprüfung und konzentriere mich auf die Bereiche, die die größte Auswirkung auf die zukünftige Wartbarkeit haben werden. Mehr als das, und der Autor wird überwältigt und hört auf, auf das Feedback einzugehen.

Stufe 4 ist alles andere: Stilpräferenzen, alternative Ansätze, die nicht unbedingt besser sind, oder Kleinigkeiten bezüglich der Formatierung. Hier ist meine umstrittene Meinung: Du solltest fast nie Stufe 4 Kommentare hinterlassen. Wenn es wichtig genug ist, standardisiert zu werden, füge es deinem Linter oder Style Guide hinzu. Wenn es nicht wichtig genug ist, um automatisiert zu werden, ist es nicht wichtig genug, um einen Pull Request zu verlangsamen. Ich habe gesehen, wie Teams Stunden damit verbracht haben, zu debattieren, ob man einfache oder doppelte Anführungszeichen verwenden sollte, während sie Code mit tatsächlichen Logikfehlern auslieferten. Sei nicht dieses Team.

Die Kunst des konstruktiven Kommentars

Der Unterschied zwischen einem hilfreichen Code-Review-Kommentar und einem demotivierenden liegt oft in ein paar Worten. Vergleiche diese beiden Kommentare zum selben Stück Code:

"Diese Funktion ist zu lang und macht zu viele Dinge." "Diese Funktion behandelt sowohl die Validierung als auch die Datenumwandlung, was es schwieriger macht, jede Sorge unabhängig zu testen. Ziehe in Betracht, sie in validateUserInput() und transformToApiFormat() aufzuteilen—so können wir die Logik der Validierung testen, ohne die Umwandlung simulieren zu müssen, und umgekehrt."

Der erste Kommentar ist technisch korrekt, aber nutzlos. Er sagt dem Autor, was falsch ist, aber nicht, warum es wichtig ist oder wie man es beheben kann. Der zweite Kommentar erklärt das Problem, beschreibt die Auswirkungen und schlägt eine spezifische Lösung vor. Es hat mich