Code-Reviews // deutsch

Code-Reviews sind trotz Coding-Standards und dem automatisierten Testen von Code unerlässlich, um eine hohe Codequalität sicherzustellen. Die Frage ist aber, wie man Code-Reviews durchführt. Hierfür gibt es unterschiedliche Ansätze, die ihre individuellen Vor- und Nachteile haben. Was empfiehlt sich wann?

────────────────────

Über the native web 🦄

Wir sind ein Beratungs-, Schulungs- und Entwicklungsunternehmen, das sich auf Web- und Cloud-Technologien spezialisiert hat. Wir streben nach intelligenten und eleganten Lösungen für komplexe Probleme, und wir glauben, dass Softwareentwicklung kein Selbstzweck ist. Stattdessen sollte Software tatsächliche Probleme der realen Welt lösen.

Wir glauben, dass native Web- und Cloud-Technologien das Fundament sind, auf dem die Zukunft aufbaut. Unsere Kernkompetenz ist der Entwurf und die Entwicklung verteilter Web- und Cloud-Anwendungen unter Verwendung dieser Technologien in interdisziplinären Teams. Wir entwickeln auch unser eigenes Open-Source-Framework namens wolkenkit. Und wir lieben es, unser Wissen in Schulungen und Workshops, auf Konferenzen und bei Usergroups zu teilen.

────────────────────

Weiterführende Links 🌍

[seeking]

Das Medium Video wird auf diesem Channel für meine Ansprüche kaum bis gar nicht genutzt. Es ist immer hilfreich visuelle Anker zu geben, um den Zuschauer abzuholen. Ansonsten würde ein Podcast vollkommen ausreichen. Aber hat ein Vorteil es als Podcast zu sehen: Ich lade mir die Videos einfach als mp3 runter und höre sie mir in der Bahn an 😅

[svenludwig]

CRs sind meiner nach extrem mächtig, wenn man es richtig macht. Wir nehmen uns dafür viel Zeit, Qualität hat oberste Priorität. Im CR finden wir häufig Bugs, die später sehr teuer wären. Auch gibt es einen enormen Wissenstransfer im Team, der durch das CR und die Diskussionen darin initiiert wird. Jede Zeile Code wird bei uns durch 2 Code Reviewer gründlich geprüft.

Im Agenturgeschäft ist dafür leider oft keine Zeit und der Kunde auch sparsam. Beim eigenen Produkt aber sehr wichtig, um eine hohe Qualität zu erreichen und das gesamte Team weiterzuentwickeln.

Pair programming ist da natürlich auch ein tolles Werkzeug mit seinen Stärken und Schwächen. Ersetzt aber für mich kein CR, bei dem man sich in Ruhe reindenken kann und so meist noch tiefer eintauchen kann als im PP.

[casinoking]

Hey Golo ich finde Reviews auch relativ sinnfrei. Das einzige was ich persönlich dennoch mag ist immer wieder über bestimmte Lösungen zu reden. Aber eher als Hands-On im Team. Bin mal auf morgen gespannt. ;)

[JentaroYusong]

Wir verwenden anstelle von Code Reviews auch Pair Programming. Sämtlicher Code wird also immer von zwei Personen gemeinsam entwickelt.

Die einzige Ausnahme hiervon sind Prototypen. Diese können auch von einer Person und ohne Tests / nicht testgetrieben entwickelt werden.
Im Anschluss wird der Prototyp allerdings vollständig verworfen und wieder mittels TDD und Pair Programming von Grund auf neu entwickelt.

Gute Code Reviews kosten einfach (zu) viel Zeit. Pair Programming ist nach unserem Empfinden effizienter und bietet darüber hinaus noch andere Vorteile.

Bei einem Code Review wird sich die / der ReviewerIn im besten Fall viel Zeit nehmen, um die Gedankengänge der / des anderen nachzuvollziehen.
Oftmals wird sich diese Zeit aber gar nicht erst genommen - dann kann man das CR gleich unterlassen.
Werden im CR nun grobe Fehler im Design entdeckt, erzeugt das einen hohen Kommunikationsbedarf und reißt die / den AutorIn aus dem Flow, da diese Person sich sicherlich schon neuen Aufgaben zugewidmet hat. Ein derartiger Kontextwechsel benötigt viel mentale Arbeit und ist dementsprechend zeitintensiv.
Beim Pair Programming können sich die Partner hingegen schon vor der Implementierung über verschiedene Designansätze Gedanken machen und erhalten meist mehr Perspektiven, als dies eine Einzelperson täte.
Somit ist die Wahrscheinlichkeit höher einen robusten Designansatz zu wählen.
Insbesondere ist die Wahrscheinlichkeit, "stecken zu bleiben" aufgrund des höheren Erfahrungsschatzes der zwei Personen geringer.

Das sind aber natürlich nur unsere Erfahrungswerte. In anderen Teams mögen CR gut funktionieren.
Etwa im Bereich von OSS ist Pair Programming auch schlichtweg leider oft nicht möglich.

Ein weiterer Vorteil des PP ist m.E. auch, dass das Onboarding neuer Teammitglieder völlig reibungslos verläuft, da hierzu kein gesonderter Prozess nötig ist und ein höherer Wissenstransfer innerhalb des Teams stattfindet - sowohl technisch als auch fachlich. Dadurch können "Wissensinseln" aktiv vorgebeugt werden.