Code Review - Der ultimative Leitfaden

Der ultimative Leitfaden zum Aufbau des Codeüberprüfungsprozesses Ihres Teams

Nachdem ich Hunderte von Codeüberprüfungen durchgeführt, Forschungs- und Entwicklungsteams geleitet und einige unbeabsichtigte Fehler selbst behoben habe, habe ich beschlossen, meine Schlussfolgerungen zum Aufbau des ultimativen Codeüberprüfungsprozesses für Ihr Team zu teilen.

In diesem Artikel wird davon ausgegangen, dass Sie wissen, was eine Codeüberprüfung ist. Wenn Sie dies nicht tun, klicken Sie hier für ein großartiges Intro.

Lassen Sie uns schnell einige einfache Gründe nennen, warum Sie Codeüberprüfungen durchführen sollten:

  1. Kann helfen, Fehler im Code zu reduzieren.
  2. Überprüfen Sie, ob alle Codierungsanforderungen erfüllt wurden.
  3. Eine effektive Möglichkeit, von Kollegen zu lernen und sich mit der Codebasis vertraut zu machen.
  4. Hilft bei der Aufrechterhaltung des Code-Stils im gesamten Team.
  5. Teamzusammenhalt - Ermutigen Sie Entwickler, miteinander über Best Practices und Codierungsstandards zu sprechen.
  6. Verbessert die allgemeine Codequalität aufgrund von Gruppenzwang.

Codeüberprüfungen können jedoch einer der schwierigsten und zeitaufwändigsten Teile des Softwareentwicklungsprozesses sein.

Das haben wir alle schon durchgemacht. Möglicherweise haben Sie Tage gewartet, bis Ihr Code überprüft wurde. Nach der Überprüfung haben Sie mit dem Prüfer ein erneutes Ping-Pong gestartet, um Ihre Pull-Anfrage erneut einzureichen. Plötzlich verbringst du Wochen damit, hin und her zu gehen. Sie wechseln den Kontext zwischen neuen Funktionen und alten Commits, die noch poliert werden müssen.

Wenn der Codeüberprüfungsprozess nicht richtig geplant ist, kann er mehr Kosten als Wert verursachen.

Aus diesem Grund ist es äußerst wichtig, einen genau definierten Prozess für die Codeüberprüfung in Ihrem Engineering-Team zu strukturieren und aufzubauen.

Im Allgemeinen müssen sowohl für den Prüfer als auch für den Prüfer genau definierte Richtlinien vorhanden sein, bevor Sie eine Pull-Anfrage erstellen und während sie geprüft wird. Genauer:

Definieren Sie die Voraussetzungen für das Erstellen von Pull-Anforderungen.

Ich habe festgestellt, dass Folgendes die Reibung stark reduziert:

  1. Stellen Sie sicher, dass der Code erfolgreich kompiliert wird.
  2. Lesen und kommentieren Sie Ihren Code.
  3. Erstellen Sie Tests und führen Sie sie aus, um den Umfang Ihres Codes zu überprüfen.
  4. Der gesamte Code in der Codebasis sollte getestet werden.
  5. Verknüpfen Sie relevante Tickets / Elemente in Ihrem Task-Management-Tool (z. B. JIRA) mit Ihrer Pull-Anfrage.
  6. Weisen Sie keinen Prüfer zu, bis Sie die obigen Schritte abgeschlossen haben.

Definieren Sie die Verantwortlichkeiten der Prüfer

Während der Prüfer der letzte in der Kette der Zusammenführung Ihrer PR ist, sind die Risiken auf lange Sicht umso geringer, je besser sie vom Prüfer übergeben werden. Hier sind einige Richtlinien, die sehr hilfreich sein können:

  1. Kommunizieren Sie mit Ihrem Prüfer - Geben Sie Ihren Prüfern Hintergrundinformationen zu Ihrer Aufgabe. Da die meisten von uns Autoren von Pull-Anfragen wahrscheinlich bereits Rezensenten waren, versetzen Sie sich einfach in die Lage des Rezensenten und fragen Sie: "Wie könnte das für mich einfacher sein?"
  2. Kleinere Pull-Anfragen stellen - Kleinere Pull-Anfragen sind der beste Weg, um Ihre Überprüfungszeit zu verkürzen. Halten Sie Ihre Pull-Anforderungen klein, damit Sie schneller und genauer iterieren können. Im Allgemeinen sind kleinere Codeänderungen auch einfacher zu testen und als stabil zu überprüfen. Wenn eine Pull-Anfrage klein ist, ist es für die Prüfer einfacher, den Kontext und die Vernunft mit der Logik zu verstehen.
  3. Vermeiden Sie Änderungen während der Codeüberprüfung - Wesentliche Änderungen in der Mitte der Codeüberprüfung setzen den gesamten Überprüfungsprozess grundsätzlich zurück. Wenn Sie nach dem Einreichen einer Bewertung größere Änderungen vornehmen müssen, möchten Sie möglicherweise Ihre vorhandene Überprüfung versenden und weitere Änderungen vornehmen. Wenn Sie nach dem Start des Codeüberprüfungsprozesses größere Änderungen vornehmen müssen, teilen Sie dies dem Prüfer so früh wie möglich mit.
  4. Auf alle umsetzbaren Rückmeldungen zur Codeüberprüfung reagieren - Auch wenn Sie deren Rückmeldungen nicht implementieren, antworten Sie darauf und erläutern Sie Ihre Argumentation. Wenn Sie etwas nicht verstehen, stellen Sie Fragen innerhalb oder außerhalb der Codeüberprüfung.
  5. Codeüberprüfungen sind Diskussionen, kein Diktat. Sie können sich die meisten Rückmeldungen zu Codeüberprüfungen eher als Vorschlag als als Bestellung vorstellen. Es ist in Ordnung, dem Feedback eines Rezensenten nicht zuzustimmen, aber Sie müssen erklären, warum und ihm die Möglichkeit geben, zu antworten.

Definieren Sie die Verantwortlichkeiten der Prüfer

Da der Prüfer vor dem Zusammenführen des Codes der letzte in der Kette ist, liegt ein großer Teil der Verantwortung bei ihm, Fehler zu reduzieren. Der Rezensent sollte:

  1. Beachten Sie die Aufgabenbeschreibung und die Anforderungen.
  2. Stellen Sie sicher, dass Sie den Code vollständig verstehen.
  3. Bewerten Sie alle Architekturkompromisse.
  4. Teilen Sie Ihre Kommentare in 3 Kategorien ein: Kritisch, Optional und Positiv. Das erste sind Kommentare, die der Entwickler akzeptieren muss, um Änderungen vorzunehmen, und das zweite sind Kommentare, die den Entwickler über Ihre Wertschätzung für nette Codeteile informieren.

Vermeiden Sie außerdem viele Kommentare und verwenden Sie stattdessen die Github-Überprüfung (siehe Beispiel unten).

Wenn Sie mehrere Kommentare haben, sollten Sie die Überprüfungsoption in Github verwenden, anstatt sie einzeln zu kommentieren, und den Entwickler (PR-Eigentümer) benachrichtigen, wenn Sie fertig sind.

Schließlich habe ich festgestellt, dass das Stellen der folgenden Fragen ein großartiges Werkzeug für einen insgesamt besseren und einfacheren Überprüfungsprozess ist:

  • Habe ich Schwierigkeiten, diesen Code zu verstehen?
  • Gibt es eine Komplexität im Code, die durch Refactoring reduziert werden könnte?
  • Ist der Code in einer sinnvollen Paketstruktur gut organisiert?
  • Sind die Klassennamen intuitiv und ist es offensichtlich, was sie tun?
  • Gibt es Klassen, die besonders groß sind?
  • Gibt es besonders lange Methoden?
  • Scheinen alle Methodennamen klar und intuitiv?
  • Ist der Code gut dokumentiert?
  • Ist der Code gut getestet?
  • Gibt es Möglichkeiten, wie dieser Code effizienter gestaltet werden kann?
  • Entspricht der Code den Styling-Standards unserer Teams?

Es gibt verschiedene effektive und unterschiedliche Methoden zur Codeüberprüfung, die je nach den Anforderungen des Teams variieren. Nehmen wir also an, dies ist meine persönliche Meinung und es gibt andere Möglichkeiten, die für Ihr Team funktionieren könnten. Letztendlich sollte der Aufbau eines solch sensiblen Prozesses subjektiv zu den Zielen Ihres Unternehmens, der Teamkultur und der gesamten F & E-Struktur sein.

Wenn Sie Fragen oder Feedback zur Verbesserung dieser Richtlinien haben, können Sie unten einen Kommentar hinzufügen!