Was sind Code-Reviews und wie sparen sie tatsächlich Zeit?

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.

Dadurch 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-Überprüfungen profitieren. Agile Teams profitieren jedoch besonders davon, da die Arbeit dezentralisiert über das gesamte Team hinweg erfolgt.

Niemand ist die einzige Person, die einen bestimmten Teil der Codebasis kennt. Einfach ausgedrückt: Code-Überprüfungen helfen dabei, den Wissensaustausch über die Codebasis und das Team hinweg zu fördern.

Code-Reviews ermöglichen das Teilen von Wissen

Agile Team sind unschlagbar flexibel: Sie können Aufgaben aus dem Backlog nehmen und von allen Teammitgliedern bearbeiten lassen. Dadurch sind Teams besser in der Lage, neue Aufgaben gemeinsam anzugehen, da niemand der "kritische Pfad" ist.

Full-Stack-Entwickler können sowohl an Frontend- als auch an Server-seitigen Aufgaben arbeiten.

Code-Reviews für bessere Schätzungen

Erinnerst du dich an den Abschnitt zur Schätzung? Schätzung ist eine Teamaufgabe. Das Team macht bessere Schätzungen, da das Produktwissen im gesamten Team verteilt ist.

Wenn dem vorhandenen Code neue Funktionen hinzugefügt werden, kann der ursprüngliche Entwickler gutes Feedback und Schätzungen bereitstellen. Außerdem ist jeder Code-Überprüfer auch mit der Komplexität, den bekannten Problemen und Bedenken im Zusammenhang mit diesem Bereich der Codebasis konfrontiert.

Ein Code-Überprüfer hat dann also teil an dem Wissen, das der ursprüngliche Entwickler über diesen Teil der Codebasis besitzt. Auf diese Weise entsteht gut fundiertes Feedback aus mehreren Quellen, das eine endgültige Schätzung immer aussagekräftiger und zuverlässiger macht.

Code-Reviews ermöglichen Auszeiten

Niemand ist gerne der einzige Ansprechpartner für einen Code-Ausschnitt. Genauso möchte sich niemand mit einem kritischen Code-Ausschnitt befassen, den er nicht geschrieben hat, schon gar nicht während eines Notfalls in der Produktion.

Durch Code-Überprüfungen wird das Wissen mit dem gesamten Team geteilt, sodass jedes Teammitglied die Zügel in die Hand nehmen und das Schiff weiter steuern kann. (Wir bei Atlassian lieben anschauliche Metaphern!) Oder kurz gesagt: Wenn kein Entwickler allein für den kritischen Pfad verantwortlich ist, bedeutet das auch, dass sich die Teammitglieder bei Bedarf eine Auszeit nehmen können.

Wenn du an ein Versionskontrollsystem gebunden bist, ist die Code-Überprüfung eine hervorragende Möglichkeit, dir mehr Freiheit zu verschaffen. Du kannst den lang ersehnten Urlaub nehmen oder einige Zeit an einem anderen Bereich des Produkts arbeiten.

Code-Reviews als eine Art Mentor für neuere Entwickler

Ein besonderer Aspekt des agilen Ansatzes ist, dass neue Mitglieder, die dem Team beitreten, von erfahreneren Engineers betreut werden. Eine Code-Überprüfung hilft außerdem dabei, den Austausch über die Codebasis zu erleichtern.

Oft haben Teams Wissen im Code verborgen, das bei der Code-Überprüfung ans Licht kommt. Neuere Mitglieder sind unvoreingenommen und entdecken oft knifflige, zeitraubende Bereiche der Code-Basis, die einen neuen Blickwinkel benötigen. Durch Code-Überprüfungen wird zudem sichergestellt, dass neue Erkenntnisse mit vorhandenem Wissen kombiniert werden.

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

Hier sind drei Wege, um dies zu optimieren. 

Teilen der Last

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.

Review vor dem Mergen

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.

Druck von Kollegen zum eigenen Vorteil nutzen

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 ...!