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

Vorsicht Spoiler: Wenn du klare architekturbezogene Entscheidungen liebst und nicht der Entwickler sein willst, der zu einem Engpass führt, wird dir dies gefallen.

Dan Radigan Dan Radigan

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.

Was genau ist also ein Code-Review?

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 Aufgaben-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 Dinge überprüft, die Maschinen übersehen. Außerdem wird verhindert, dass sich schlechte Entscheidungen bezüglich des Codes auf die Hauptentwicklung auswirken. 

Was bedeutet das für ein agiles Team?

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.

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

Code-Reviews für bessere Schätzungen

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.

Code-Reviews ermöglichen Auszeiten

Nobody likes to be the sole point of contact on a piece of code. Likewise, nobody wants to dive into a critical piece of code they didn’t write–especially during a production emergency. Code reviews share knowledge across the team so that any team member can take up the reins and continue steering the ship. (We love mixed metaphors at Atlassian!) But here's the point: with no single developer the critical path, it also means team members can take time off as needed. If you find yourself tied to a desk on the version control system, code review is an excellent way to find freedom. Freedom to take that needed vacation, or freedom to spend some time working on a different area of the product.

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

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.

Profitipp:

Denke daran, dass bei einem Code-Review nicht nur ein erfahrenes Teammitglied den Code eines neueren Teammitglieds überprüft. Der Code-Review sollte teamübergreifend in jeder Richtung erfolgen. Wissen kennt keine Grenzen! Natürlich kann ein Code-Review für neuere Entwickler hilfreich sein, sollte aber keinesfalls als reine Mentoring-Übung eingesetzt werden. 

Code-Reviews brauchen aber doch Zeit!

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

Up Next
Ausführen