© Roman Samborskyi/Shutterstock.com
Endlich gute Qualität durch methodische Codereviews

Clean Pull Requests und Prüfen mit System


Trotz guter Toolings, erfahrener Entwickler, des richtigen Mindsets und eines vernünftig wirkenden Reviewprozesses liefern Codereviews häufig nicht die gewünschte Qualität. Nicht nur der Revie-wer entscheidet darüber, ob Codereviews erfolgreich sind – neben einem geplanten Ressourceneinsatz sind Clean Pull Requests die unabdingbare Basis für gute Reviews. Dieser Artikel zeigt, wieso Codereviews in vielen Projekten unbemerkt scheitern, und erläutert, wie sich durch eine ganzheitliche methodische Betrachtung ein tatsächlich zielführender Qualitätssicherungsprozess etablieren lässt.

Qualität ist für viele Produkte ein Muss. Sie ist Verkaufsargument. Für das (Teil-)Produkt Software sollte das genauso gelten [1]. Bezüglich externer Qualität und Nutzungsqualität (Quality in Use) mag darüber noch ein halbwegs breiter Konsens bestehen – für die interne Qualität und somit die Codequalität, scheinen diese Regeln jedoch häufig nicht zu gelten. „Was man nicht sieht (in diesem Fall einen Mangel an Codequalität), gibt es nicht“, scheint da die Devise zu sein. Dennoch sollte allen bewusst sein, dass die Codequalität viele Dinge beeinflusst, u. a. Wartbarkeit und Erweiterbarkeit – auf Dauer wird es sehr teuer, Software mit neuen Features zu erweitern, wenn bei Architektur und Design das Thema Erweiterbarkeit nie betrachtet wurde. Für die Architekturarbeit existiert mit Quality-driven Software Architecture [2] eine Methode, die das bewusste Hinarbeiten auf vorher definierte Qualitätsziele explizit ins Zentrum rückt.

Die Voraussetzungen

Eine hohe Codequalität kann nicht erreicht werden, wenn die notwendigen Voraussetzungen fehlen: Dazu zählen engagierte und gut ausgebildete Mitarbeiter, ein vernünftiger Entwicklungsprozess und das richtige Tooling. Nichts davon wird jedoch nachhaltig zu einer hohen Codequalität führen, wenn die zugrunde liegende Unternehmenskultur nicht passt (Abb. 1).

marquardt_codereviews_1.tif_fmt1.jpgAbb. 1: Voraussetzungen für (Code-)Qualität

Die Herstellung dieser Voraussetzungen ist jedoch nicht Gegenstand dieses Beitrags. Gehen wir davon aus, dass die Basis intakt ist und die in den folgenden Abschnitten aufgeführten Annahmen zutreffen.

Die Unternehmenskultur

Diese ist die Basis. Nur mit der richtigen Unternehmenskultur wird man die richtigen Mitarbeiter finden und halten können. Das Unternehmen muss Codequalität als Business Value erkennen und bereit sein, hier zu investieren. Es muss den Mitarbeitern vertrauen und sie im Sinne agiler Entwicklung befähigen, sich selbst zu organisieren [3]. Nur so können Prozesse und Tooling laufend verbessert werden, um das Team bestmöglich zu unterstützen, anstatt es durch unpassende Vorgaben zu behindern.

Die Mitarbeiter

Die Mitarbeiter sind motiviert und engagiert – sie haben das richtige Mindset und wollen qualitativ hochwertigen Code schreiben. Sie leben den Software-Craftsmanship-Gedanken und bilden sich eigenständig weiter, um die notwendigen Qualifikationen zu erlangen und auszubauen (Kasten: „Software Craftsmanship und Clean Code“).

Software Craftsmanship und Clean Code

Konkret sind für das Thema Software Craftsmanship [4], [5] und Codequalität die Beiträge aus der Clean-Code-Community rund um Robert C. Martin [6], [7] eine wichtige Quelle für die meisten Entwickler. Eine sehr gute erste Anlaufstelle bietet die Clean Code Developer Initiative [8]: Hier werden Entwickler mittels des Grade-Systems systematisch und Stück für Stück mit den wichtigsten Prinzipien und Praktiken vertraut gemacht.

Das Management fördert die Weiterentwicklung der Mitarbeiter, auch durch Investition und das Bereitstellen von Ressourcen. Deutlich wichtiger als ihre technischen Fähigkeiten ist also das Mindset der Mitarbeiter. Gleichzeitig ist sichergestellt, dass ausreichend erfahrene Mitarbeiter im Team sind, um das Projekt zum Erfolg zu führen. Diese können zudem die noch weniger erfahrenen Teammitglieder coachen, bis sie auf einem entsprechenden Niveau mitarbeiten können.

Der Prozess

Der Prozess soll die Entwickler bei ihrer Arbeit unterstützen. Gemeint ist der gesamte Entwicklungsprozess und konkret der Codereviewprozess. Um Codequalität zu erreichen, muss jeder Commit, der auf master landet, eine Review durchlaufen haben. Daher wird nach einem Workflow gearbeitet, der Pull Requests (PR, synonym zu Merge Requests) unterstützt, wie etwa der Feature-Branch-Workflow (Kasten: „Git-Workflows“).

Git-Workflows

Es gibt verschiedene Workflows, die auf Git aufsetzen. Clean Pull Requests implizieren – wenig überraschend – einen Workflow, der auf Pull Requests basiert. Der Feature-Branch-Workflow (oder GitHub Flow) und der gitflow sind die prominenten Beispiele für Pull-Request-Workflows. Ich persönlich bevorzuge den Feature-Branch-Workflow; im Gegensatz zum gitflow ist er schlank und effektiv, der komplexere gitflow für sich genommen ist zudem kein Garant für eine höhere Codequalität.

Die Tools

Wie der Prozess, so sollen auch die eingesetzten Tools den Entwicklern helfen. Gute Tools unterstützen Entwickler dabei, einerseits ihre Arbeit gut zu machen, und nehmen ihnen andererseits durch Automatisierung unnötige Arbeit ab. Manchmal ist dafür eine Umstellung notwendig, denn nicht immer sind von vorherein dem Ziel dienliche Tools im Einsatz, vgl. Git. Mit den richtigen Mitarbeitern ist das jedoch kein Problem, falls das Tooling an sich seinen Zweck erfüllt. Das falsche Tooling kann hingegen regelrecht behindern. Im schlimmsten Fall führt es zu Frust. Falls dieses Problem nicht behoben wird, werden sich engagierte Mitarbeiter letztendlich einen anderen Arbeitsplatz suchen.

Mit Git [9] gibt es ein Versionsverwaltungssystem, das eine hohe Codequalität im Sinne einer sauberen Commit-Historie ermöglicht. Der Rest des Artikels setzt eine Verwendung von Git daher voraus. Zudem wird Tooling verwendet, das einen Pull-Request-Workflow unterstützt. Azure DevOps, GitLab, GitHub, Bitbucket, Gerrit – all diese Werkzeuge tun das prinzipiell.

Voraussetzungen erfüllt – wieso scheitern wir trotzdem?

Engagierte Mitarbeiter, die richtige Unternehmenskultur, ausreichend Ressourcen, vernünftige Tools – und ein Entwicklungsprozess, der vorschreibt, dass jeder Commit eine Review durchlaufen muss, um auf master zu kommen. Viel besser kann es doch kaum sein – was soll da noch schief gehen? (Mit diesen Voraussetzungen kann man sich tatsächlich glücklich schätzen!) Schauen wir uns das einmal genauer an.

Ein typisches Problem

Code wird geschrieben und letztendlich zur Review freigegeben: Ein Pull Request wird erstellt. Dank der Review kann manch oberflächlicher Fehler innerhalb des Pull Requests gefixt werden. Andere, oft größere Probleme bleiben allerdings unbemerkt und vergrößern somit die technischen Schulden. Warum ist das so? Und was lässt sich verbessern?

Tatsächlich ist das – mit den guten Voraussetzungen im Hinterkopf – auf den ersten Blick überraschend. Und für viele Teams sehr frustrierend, wenn sie merken, dass die technischen Schulden trotz idealer Bedingungen anwachsen, anstatt kleiner zu werden.

Erfolgsfaktoren für Codereviews

Ganz allgemein hängt der Erfolg von Codereviews an verschiedenen Dingen: erst einmal an der Erfahrung und Methodik des Reviewers. Checklisten helfen ihm, alle für die Review relevanten Qualitätskriterien zu beachten. Darüber hinaus braucht es aber die notwendigen Ressourcen im Sinne von ungestörter Reviewzeit, die effizient zu nutzen ist. Voraussetzung: Bestimmte Aspekte werden, soweit das sinnvoll möglich ist, schon vorher durch Automatisierung abgeprüft.

Der übersehene Erfolgsfaktor

Es wird allerdings oft übersehen, dass der Einsteller des Pull Requests (im Folgenden gleichgesetzt mit dem Codeautor) einen mindestens ebenso großen Anteil am Erfolg der Review hat wie der Reviewer selbst. Im Projektalltag sind Pull Requests meist so groß und komplex, dass der Reviewer sie nicht in überschaubarer Zeit adäquat überprüfen kann. Daraus kann folgen, dass er Pull Requests ablehnt – eine sinnvolle Konsequenz. Häufiger aber werden sie mit wenigen Kommentaren und eher unbedeutenden Verbesserungsvorschlägen durchgewunken.

Als Resultat hat man zwar in diese Reviews einiges an Zeit investiert, letztendlich aber wenig an Qualität hinzugewonnen – und zudem die Chance verpasst, Reviews als effizientes Mittel zum Wissenstransfer zu nutzen.

Die letzte Variante: Je nach Gewissenhaftigkeit des Reviewers kann es vorkommen, dass enorm viel Zeit durch den Versuch verloren geht, den Pull Request trotz aller Schwierigkeiten gründlich zu prüfen. Das ist sowohl frustrierend für den Reviewer als auch schlecht für die Effizienz des Projekts.

Clean Pull Requests

Der Codeautor ist also in der Verantwortung, den Pull Request so aufzubereiten, dass ein Reviewer in einem tolerablen Zeitrahmen gute Arbeit machen kann. Das ist nur zu schaffen, wenn der Pull Request klein und gut verständlich ist. Folgende Kriterien sollten dafür erfüllt sein:

  • klein (Kasten „Studie bei Cisco zu Codereviews“)

  • gut verständlich

    • in sich abgeschlossen

    • gemäß Single Responsibility Principle (SRP) verantwortlich nur für eine Sache

    • guter Titel und gute Beschreibung (ermöglicht durch die beiden vorigen Punkte)

    • saubere Commit-Historie, bestehend aus sauberen, gut verständlichen Commits; das schließt explizit den völlig validen Fall mit ein, dass der Pull Request nur einen Commit enthält; eine saubere Commit-Historie ist nicht nur für den Reviewer hilfreich, sondern für jeden Leser des Codes – also potenziell auch noch Jahre später

Einen Pull Request, der diese Anforderungen erfüllt, nenne ich Clean Pull Request (Kasten: „Alternativlose Methodik?“).

Studie bei Cisco zu Codereviews

Gemäß einer großen, von SmartBear Software im Jahr 2006 veröffentlichen Studie bei Cisco [10] besagt eine Heuristik Folgendes: Die Anzahl geänderter Zeilen Code sollte nicht größer als 200-400 sein und innerhalb von 60-90 Minuten 70-90 Prozent der Defects identifizieren. (Die Anzahl geänderter Codezeilen sagt für sich genommen jedoch noch wenig aus, denn ein simples Renaming einer einzelnen Methode über viele Files hinweg mag deutlich mehr Zeilen verändern als das Hinzufügen von hochkomplexem Algorithmuscode.)

Alternativlose Methodik?

Die hier vorgestellte Methodik (basierend auf ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang