Code Reviews sind ein essenzieller Bestandteil der Arbeit in einem Team von Softwareentwickler:innen. In vielen Teams sind sie der primäre Moment des gemeinsamen Austauschs. Hier ist mein persönlicher Ansatz, wie sie gut gelingen:
Ziele
Zuerst einmal sollte man sich die Ziele eines Code Reviews bewusst machen:
Gemeinsames Verständnis schaffen: Nach dem Code Review sollte nicht nur die Autor:in, sondern mindestens auch die Reviewer:in verstehen, was geändert wurde und warum.
Fehler finden: Vier Augen sehen mehr als zwei. Die Reviewer:in sucht nach Fehlern, die der Autor:in entgangen sind.
Code-Style vereinheitlichen: Nicht im Sinne von den richtigen Quotation-marks oder Zeilenumbrüchen (dafür gibt es Formatter). Es geht darum, die gleichen Abstraktionen zu benutzen und die Autor:in darauf hinzuweisen, wenn ein Pattern schon vorhanden ist, eine API falsch benutzt wird oder sonstige technische Schulden aufgebaut werden, die sich mit dem Wissen der Reviewer:in vermeiden lassen.
Methoden
Ein gutes Code Review besteht ausschließlich aus Fragen.
Diese dienen den oben beschriebenen Zielen.
Wenn ich nicht verstehe, was der Code tut, den ich reviewen soll, stelle ich Fragen.
Wenn ich nicht verstehe, warum eine Änderung gemacht wurde, stelle ich Fragen.
Wenn ich die Stelle, die ich reviewen soll, nicht gut finde frage ich, warum dieser Abschnitt so gelöst wurde anstatt zu kritisieren. Häufig sind suboptimale Lösungen sorgfältig gewählte Kompromisse.
Wenn ich einen Fehler sehe frage ich, ob Abschnitt X nicht zu Problem Y führt.
Wenn ich eine Abstraktion sehe, die ich schon einmal sehr ähnlich an anderer Stelle in dieser Codebase gesehen, habe frage ich, warum die vorhandene Abstraktion nicht genutzt wurde.
Wenn ich denke, ich habe eine bessere Lösung, frage ich, warum das Problem nicht so gelöst wurde wie ich es mir vorstelle.
Kommunikation
Beim Fragen stellen (generell und besonders in Code Reviews) sollten wir beachten:
Dass wir unsere Kolleg:innen nicht in Erklärungsnot bringen. Das Ziel sollte sein, Verständnis zu schaffen, niemals die Kolleg:in zu zwingen, sich zu rechtfertigen.
Konstruktives Feedback zu geben: Wenn ich einen Verbesserungsvorschlag habe sollte ich diesen einbringen (in diesem Fall kann die Frage sein, ob die vorgeschlagene Lösung bereits in Betracht gezogen und gegebenenfalls aus guten Gründen nicht gewählt wurde).
Gewaltfrei zu kommunizieren, zu berücksichtigen wie wir unser Feedback bzw. unsere Fragen formulieren und wie sie von der Empfänger:in angenommen werden könnten.
Juniors
Du hast wenig Erfahrung und Bedenken, ob du fähig bist, den Code einer erfahreneren Entwickler:in zu beurteilen?
Musst du nicht, Verständnisfragen stellen reicht völlig. Meiner Erfahrung nach fallen bei einem Review von einer weniger erfahrenen Kolleg:in vergleichsweise weniger subtile Fehler auf, das wird aber mehr als wett gemacht durch den Anstoß, meine eigenen Entscheidungen zu erklären und dabei zu hinterfragen.
Und wenn du das Projekt nicht gut genug kennst und das Gefühl hast du weißt gar nicht wo du anfangen sollst? Wenn möglich sprich direkt mit der Autor:in und lass dir persönlich und unmittelbar erklären, was dort passiert.
Ausnahmen
Zu guter Letzt bestätigen Ausnahmen natürlich die Regel. Es gibt Situationen, in denen ein Review keine Frage ist. Es gibt Situationen, in denen ich mir sicher bin, dass eine Lösung so nicht übernommen werden darf, wie ich sie im Review vor mir habe. In diesen Fällen formuliere ich meine Anforderungen (nicht Fragen) und bestehe darauf, dass die entsprechenden Stellen geändert werden.
Ausnahmen erkenne ich in der Regel daran, dass ich mich dabei ertappe wie ich rhetorische Fragen formuliere (auf die es nur eine Antwort gibt).
