Warum Code-Reviews wichtig sind (und tatsächlich Zeit sparen!)

Agile Teams organisieren sich dank teamübergreifender Kompetenzen selbst. Dies wird teilweise durch Code-Reviews erreicht. Mit einem Code-Review lernen Entwickler nicht nur die Codebasis kennen, sondern erlernen auch neue Technologien und Verfahrensweisen, die ihre Kompetenzen erweitern.

Wenn ein Entwickler die Arbeit an einem Vorgang beendet hat, sieht sich ein anderer Entwickler den Code an und stellt Fragen wie:

• Gibt es offensichtliche Logikfehler im Code?
• Wurden alle anforderungsbezogenen Fälle implementiert?
• Reichen die neuen automatisierten Tests für den neuen Code aus? Müssen vorhandene automatisierte Tests neu geschrieben werden, um Änderungen im Code zu berücksichtigen?
• Entspricht der neue Code vorhandenen Formatierungsrichtlinien?

Code-Reviews sollten in den vorhandenen Prozess eines Teams integriert werden. Wenn ein Team beispielsweise Task-Branching-Workflows verwendet, solltest du einen Code-Review initiieren, nachdem der gesamte Code geschrieben wurde und automatisierte Tests ausgeführt und bestanden wurden, aber bevor der Code in den Upstream gemergt wird. Damit wird sichergestellt, dass der Code-Reviewer den Code auf Probleme überprüft, die Maschinen übersehen. Außerdem wird verhindert, dass sich schlechte Entscheidungen bezüglich des Codes auf die Hauptentwicklung auswirken.

Jedes Team kann unabhängig von den Entwicklungsmethoden von Code-Reviews profitieren. Agile Teams profitieren jedoch besonders, da die Arbeit dezentralisiert über das gesamte Team hinweg erfolgt. Es gibt nie nur eine einzige Person, die einen bestimmten Teil der Codebasis kennt. Einfach gesagt tragen Code-Reviews dazu bei, Wissen einfacher über die Codebasis und das Team hinweg zu teilen.

Agile Team sind unschlagbar flexibel: Sie können Aufgaben aus dem Backlog nehmen und von allen Teammitgliedern bearbeiten lassen. Teams können deshalb neue Aufgaben gemeinsam angehen, da niemand einen Engpass darstellt. Full-Stack-Entwickler können sowohl Front-end- als auch serverseitige Arbeiten erledigen.

Erinnerst du dich noch an den Abschnitt zur Schätzung? Die Schätzung ist Teamarbeit und das Team kann präzisere Schätzungen abliefern, wenn sich das Produktwissen über das Team verteilt. Wenn neue Features zum vorhandenen Code hinzugefügt werden, kann der ursprüngliche Entwickler ein gutes Feedback und eine präzise Schätzung bereitstellen. Darüber hinaus wird jeder Code-Reviewer auch mit der Komplexität, bekannten Problemen und Bedenken in diesem Bereich der Codebasis konfrontiert. Der Code-Reviewer steht dann in Bezug auf diesen Teil der Codebasis auf demselben Wissensstand wie der ursprüngliche Entwickler. Diese Vorgehensweise ermöglicht mehrere sachkundige Inputs, die dafür sorgen, dass eine endgültige Schätzung genauer und zuverlässiger ist.

Niemand möchte der einzige Ansprechpartner für einen Codebereich sein. Und genauso möchte sich niemand in einen wichtigen Codebereich einarbeiten müssen, den er nicht geschrieben hat – schon gar nicht bei einem Notfall in der Produktion. Da Code-Reviews das Wissen über das Team verteilen, kann jedes Teammitglied die Zügel in die Hand nehmen und das Boot weiter steuern. (Gemischte Metaphern sind bei Atlassian sehr beliebt!) Aber der Punkt ist: Wenn kein Entwickler einen Engpass darstellt, können sich Teammitglieder nach Bedarf eine Auszeit gönnen. Wenn du feststellst, dass du an den Schreibtisch des Versionskontrollsystems gefesselt bist, ist ein Code-Review ein exzellentes Mittel, um deine Freiheit wiederzugewinnen. Sei es, um dringend benötigten Urlaub zu nehmen oder Zeit für einen anderen Bereich des Produkts zu haben.

Ein besonderer Aspekt agiler Methoden ist, dass erfahrene Entwickler als Mentoren für neue Teammitglieder agieren. Und ein Code-Review vereinfacht Gespräche über die Codebasis. Oft ist das Wissen des Teams im Code verborgen und kommt während eines Code-Reviews ans Tageslicht. Neuere Teammitglieder können oft mit ungetrübtem Blick erhebliche, über die Zeit verschleppte Bereiche der Codebasis erkennen, die eine neue Sichtweise benötigen. Ein Code-Review stellt also auch sicher, dass neue Einsichten mit vorhandenem Wissen gekoppelt werden.

Natürlich brauchen sie Zeit. Aber diese Zeit ist nicht vergeudet – ganz im Gegenteil.

Hier sind drei Wege, um dies zu optimieren.

Bei Atlassian werden in vielen Teams zwei Reviews für jeden Code verlangt, bevor der Code in die Codebasis eingecheckt wird. Hört sich nach viel Aufwand an? Ist es aber eigentlich nicht. Ein Autor, der einen Reviewer auswählt, streckt seine Fühler in alle Richtungen aus. Und das Input kann von zwei beliebigen Entwicklern kommen. Damit wird der Prozess dezentralisiert, damit niemand zu einem Engpass wird. Zudem wird sichergestellt, dass Code-Reviews teamübergreifend abgedeckt werden.

Ein Code-Review vor dem Upstream-Merging sorgt dafür, dass kein nicht geprüfter Code in das Produkt gelangt. Das bedeutet, dass fragwürdige architekturbezogene Entscheidungen um zwei Uhr morgens und eine unangemessene Verwendung eines Factory-Musters durch den Praktikanten erkannt werden, bevor sie sich endgültig (und bedauerlicherweise) auf die Anwendung auswirken können.

Wenn Entwickler wissen, dass ihr Code von einem Teamkollegen überprüft wird, achten sie besonders darauf, dass alle Tests bestanden werden und der Code möglichst so gut entworfen ist, dass der Review reibungslos verläuft. Durch diese Aufmerksamkeit verläuft der Codierungsprozess an sich oft reibungsloser und letztendlich schneller.

Wenn Feedback zu einem früheren Zeitpunkt im Entwicklungszyklus erforderlich ist, solltest du nicht auf einen Code-Review warten. Frühes und häufiges Feedback sorgt für besseren Code – zögere deshalb nicht, andere – in welcher Form auch immer – einzubeziehen. Das verbessert nicht nur deine Arbeit, sondern sorgt auch dafür, dass deine Teamkollegen bessere Code-Reviewer werden. Und damit setzt sich der positive Kreislauf fort ...!