Ein Code-Review ist ein Prozess, in dem andere Entwickler den Code eines Teammitglieds analysieren, um Bugs zu finden, logische Fehler zu identifizieren und übersehene Grenzfälle zu entdecken. Und Code-Reviews haben klare Ziele: Die Code-Qualität soll erhöht werden; das Team will Fehler und Probleme möglichst während des Entwicklungszyklus’ finden und beheben und nicht erst, nachdem Kunden sie aufgedeckt haben.

Laut einer Umfrage von 2020 ist das Code-Review tatsächlich der beste Weg, um die Code-Qualität zu erhöhen. Eine frische Perspektive und ein unverstellter Blick helfen, verbesserungswürdige Design-Muster und Bugs zu identifizieren. So gewährleisten Teams, dass Features oder Produkte stets auf hochqualitativem Code basieren.

In diesem Beitrag gehen wir auf fünf Praktiken ein, die helfen, den Nutzen von Code-Reviews zu maximieren.

Code-Review-Checklisten

Eine Code-Review-Checkliste besteht aus einer vorgefertigten Sammlung mit Fragen und Regeln, denen das Team während des Review-Prozesses folgt. Dadurch entsteht ein strukturierter Ansatz im Hinblick auf die nötigen Qualitäts-Checks, bevor der zu prüfende Code freigegeben wird und in die Codebasis eingehen kann. So eine Checkliste kann unter anderem diese Elemente umfassen:

• Lesbarkeit: Gibt es irgendwelche redundanten Kommentare im Code?
• Sicherheit: Eröffnet der Code Angriffsflächen auf das System?
• Testabdeckung: Besteht die Notwendigkeit für mehr Testfälle?
• Architektur: Verwendet der Code Kapselung und Modularisierung, um "Separation of Concerns" zu erreichen?
• Wiederverwendbarkeit: Nutzt der Code wiederverwendbare Komponenten, Funktionen und Services?

Metriken für Code-Reviews

Entwickler können die Code-Qualität anderer Entwickler nicht erhöhen, wenn sie kein objektives Maß dafür haben. Metriken helfen, die Effizienz der Reviews zu ermitteln, die Auswirkungen von Änderungen auf den Prozess zu analysieren und den Zeitaufwand bis zur Fertigstellung eines Projekts zu prognostizieren. Häufig genutzte Review-Metriken sind beispielsweise diese:

• Inspektionsrate: Die Geschwindigkeit, mit der das Team ein bestimmtes Volumen an Code untersucht. Dafür wird die Anzahl der Codezeilen durch die Zahl der Inspektionsstunden geteilt. Wenn es sehr lange dauert, den Code zu reviewen, könnte es Probleme in Sachen Lesbarkeit geben, die angegangen werden müssen.
• Defektrate: Die Frequenz, mit der Defekte identifiziert werden. Sie wird berechnet, indem die Anzahl der Defekte durch die Inspektionsstunden geteilt wird. Diese Metrik hilft, die Effizienz der Testprozesse zu messen. Wenn die Entwickler beispielsweise sehr viel Zeit brauchen, um Defekte zu finden, sind womöglich bessere Testwerkzeuge nötig.
• Defektdichte: Die Anzahl der Defekte, die in einem bestimmten Code-Volumen identifiziert werden. Hierfür wird die Defektzahl durch die Codezeilen geteilt. Die Defektdichte hilft zu ermitteln, welche Komponenten defektanfälliger sind als andere. Dementsprechend können den vulnerablen Komponenten mehr Ressourcen zugewiesen werden. Wenn zum Beispiel die Web-Applikationen signifikant mehr Defekte aufweist als andere Bestandteile desselben Projekts, ist es vielleicht ratsam, mehr Entwickler mit umfangreicher Erfahrung an diesen Teilen arbeiten zu lassen.

Änderungen gut begründen

Wenn Entwickler Code reviewen, reicht es nicht aus, Fixes und Verbesserungen einfach vorzuschlagen. Vielmehr sollten sie ihre Intention gut erklären. Während des Entwicklungsprozesses hat es das Team oft mit Problemen zu tun, für die es mehrere unterschiedliche Lösungsansätze gibt. Die Kommentare, die die Reviewer im Code hinterlassen, sind ein Produkt ihres Wissens und ihrer Erfahrungen. Auf dieser Basis gehen sie ein Problem vielleicht auf eine spezielle Art und Weise an, die sich vom Ansatz des ursprünglichen Autoren unterscheidet. Deshalb ist es wichtig, die Review-Entscheidungen zu erläutern.

Nehmen wir an, ein Entwickler reviewt ein Stück Code und ist der Meinung, dass hier kein Multi-Threading erforderlich ist. Statt dem Teamkollegen einfach den Verzicht auf die Nutzung von Threads nahezulegen, sollte der Reviewer ihm darlegen, dass der ursprüngliche Ansatz in diesem Szenario keinerlei Performance-Vorteile bringt und deshalb Single Thread sinnvoll ist.

Dieser Weg bietet zwei Vorteile. Erstens weiß der Code-Autor, aus welchem Grund eine bestimmte Änderung nötig ist – und das hilft ihm, Lösungsansätze für ähnliche Probleme in der Zukunft zu finden. Zweitens bedeuten verständliche erklärende Code-Kommentare, dass keine langwierigen persönlichen Diskussionen nötig sind. Das spart allen Beteiligten Zeit.

Nur kleine Code-Umfänge reviewen

Mehr als 400 Code-Zeilen (Lines of Code, LoC) zu prüfen, kann einen negativen Effekt auf die Fähigkeit, Bugs zu finden, haben. Tatsächlich finden Reviewer die meisten Fehler in den ersten 200 Zeilen, wie zum Beispiel eine Studie von Cisco belegt. Darüber hinaus fällt die Trefferquote deutlich ab.

Automatisierungsmöglichkeiten nutzen

Wenn das Entwicklungsteam Bitbucket als Git-Lösung nutzt, ist es oft sinnvoll, die Plattform um passgenaue Funktionen zu erweitern. Dafür bietet der Atlassian Marketplace zahlreiche Apps für erweiterte Anwendungsfälle – beispielsweise Workzone. Mit dieser Lösung kann das Team planen, wie und wann Änderungen gepusht und wie Reviewer oder Gruppen zu neuen Pull-Requests hinzugefügt werden.

Eine andere Bitbucket-App, die bei der Automatisierung von Code-Reviews hilft, ist Code Owners for Bitbucket. Mit diesem Tool kann das Team entscheiden, welche User in Bitbucket Pull-Requests reviewen sollten. Das Konzept dahinter ist der Code-Owner-Ansatz.

Git und Bitbucket effektiv nutzen? Wir sind Ihr Partner!

Möchten Sie mehr über Atlassians Git-Repository-Manager Bitbucket erfahren? Würden Sie die Lösung gerne unverbindlich testen? Oder suchen Sie Unterstützung bei der Transition zu Git? Wir sind Atlassian Platinum Solution Partner und helfen Ihnen bei allen Aspekten rund um die Einführung von Bitbucket Data Center oder Bitbucket Cloud sowie aller Apps auf dem Atlassian Marketplace.

Weiterführende Infos

Bitbucket: Neue Workflows für Code-Reviews und inaktive Pull-Requests
Code-Reviews mit den Google Cloud Source Repositories
Bitbucket Data Center: Noch effizienter mit Pull-Requests arbeiten
Wie Code Insights für Bitbucket andere Entwickler-Tools integriert und Pull-Requests beschleunigt