Code Review: Methoden und Tools vorgestellt

Code Review ist ein integraler Bestandteil der modernen Softwareentwicklung. Die Codeüberprüfung durch andere Mitglieder des Programmierteams deckt Fehler auf und trägt zur Verbesserung der Codequalität bei. Dabei kommen unterschiedliche Techniken und Ansätze zum Einsatz, die wir im Folgenden näher vorstellen.

Bei Code Review, zu Deutsch „Codeüberprüfung“, handelt es sich um eine Maßnahme zur Qualitätssicherung bei der Softwareentwicklung. Quellcode ist das grundlegende Medium der Entwicklungsarbeit und primäres Produkt der Programmierung. Neuerstellter oder veränderter Code wird einem Code Review unterzogen. Dabei überprüfen ein oder mehrere Teammitglieder die Arbeit eines Programmierers oder einer Programmiererin.

Ein Softwareprojekt umfasst eine „Codebase“ – eine Sammlung von Code-Dateien, die zusammengenommen dazu dienen, ein Produkt auszuliefern. Dazu gehören der eigentliche Produkt-Code, Konfiguration, Entwicklungs-Tools, Tests und mehr, allesamt in Code abgebildet. Die gesamte Codebase wird mit einem Versionskontrollsystem wie Git verwaltet. Über mehrere „Branches“, zu Deutsch „Äste“, lassen sich mehrere Versionen der Codebase parallel verwalten. So kann die Entwicklung neuer Features fortschreiten, ohne dass die Produktionsversion der Codebase verändert wird.

Die Entwicklungsarbeit findet für gewöhnlich auf sogenannten Feature-Branches statt, die periodisch in den Main-Branch integriert werden. Die Codeüberprüfung wird vor dem „Merge“ durchgeführt, d. h. bevor neuer oder veränderter Code mit der bestehenden Codebase zusammengeführt wird. Ziel ist, Fehler frühzeitig zu erkennen und zu beseitigen, bevor der Code in die Produktion geht.

Doch das Ausmerzen von Bugs ist nicht der einzige Nutzen der Codeüberprüfung. Dass Code funktioniert, also fehlerfrei läuft und das gewünschte Ergebnis erzielt, ist lediglich eine Grundvoraussetzung. Darüber hinaus gibt es eine Vielzahl weiterer Gütekriterien für Clean Code. Das Vorhandensein von Kommentaren, die Klarheit und Konsistenz des Codes, das Erfüllen von Stilvorgaben und die Integrierbarkeit in existierende Systeme sind allesamt kritisch und werden beim Code Review beachtet.

Da die Entwicklungsarbeit größtenteils in Gruppen stattfindet, gehen Auswirkungen von Code Review über die reine Codequalität hinaus. Denn die Codeüberprüfung erfolgt durch andere Mitglieder des Entwicklungsteams und erzeugt soziale Effekte: Neue Mitglieder erhalten Feedback zu Konventionen und Best Practices, Wissen wird innerhalb der Organisation ausgetauscht und verteilt. So trägt die Codeüberprüfung dazu bei, eine Qualitätskultur zu pflegen.

Auch wenn die Codeüberprüfung von Menschen vorgenommen wird, werden die Code-Review-Prozesse heutzutage für gewöhnlich durch spezielle Code-Review-Tools unterstützt. Code-Review-Tools schaffen Effizienz und entlasten die beteiligten Personen von der kleinteiligen und aufwendigen Koordination der Prozesse. So können sich die Menschen auf das eigentliche Code Review konzentrieren.

Konzeptuell liegt das Code Review durch Menschen zwischen zwei automatisierten Analysemethoden, der statischen und der dynamischen Analyse. Die Unterschiede im Überblick:

Das Konzept eines Code Review ist an sich simpel: Veränderter oder neugeschriebener Code wird von einem oder mehreren Mitgliedern des Entwicklungsteams (genannt „Reviewer“) auf Korrektheit überprüft. Die Reviewer lesen den Code und identifizieren mögliche Fehler sowie Abweichungen von den im Team etablierten Konventionen. Entweder verbessern die Reviewer den Code im Anschluss oder sie übergeben ihre Erkenntnisse an die ursprünglichen Autoren bzw. Autorinnen, die die Änderungen einpflegen.

So einfach die Idee ist, in der Praxis bläht sich der Aufwand für Code Review-Prozesse schnell auf. Dabei liegt der Teufel in den Detailfragen: Welche Änderungen gehören zusammen und wie werden diese den Reviewern übermittelt? Wie werden gefundene Fehler und Kommentare den entsprechenden Stellen im Code zugeordnet und den für die Verbesserung Verantwortlichen zur Verfügung gestellt? Ohne spezielle Code-Review-Tools lässt sich dies nur innerhalb kleinster Teams koordinieren.

In verteilten, agilen Programmierteams ist Code Review meistens ein fester Teil des Entwicklungsprozesses. Im Rahmen der Continuous Integration (CI) wird Code kontinuierlich geschrieben, getestet und in die bestehende Codebase eingepflegt. Das Code Review durch einen Menschen ist Teil der automatisierten CI-Pipeline, die jede Einheit Code durchläuft. Nur wenn alle Tests bestanden werden, wird der Code integriert und im Anschluss an Produktionssysteme ausgespielt.

Schauen wir uns die einzelnen Schritte einer CI-Pipeline und die Position des Code Review darin in der Übersicht an:

1. Code schreiben
   1. Code auf Feature-Branch schreiben
   2. Code in lokaler Umgebung testen
       
2. Code in Codebase integrieren
   1. Code auf Feature-Branch automatisiert analysieren und formatieren
   2. Code Review durchführen und Verbesserungen einpflegen
   3. Code in Main-Branch mergen
   4. Main-Branch auf Staging-Site ausspielen und testen
       
3. Code in Produktion bringen
   1. Code in Release-Branch mergen
   2. Release-Branch auf Live-Site ausspielen

Das Code Review ist ein wichtiger Bestandteil der Qualitätskontrolle bei der Softwareentwicklung. So stellt die Codeüberprüfung sicher, dass neugeschriebener Code möglichst fehlerfrei ist und den Qualitätsstandards der Organisation genügt. Langfristig minimiert dies technische Schulden; kurzfristig wird verhindert, dass fehlerhafter Code auf Produktionssystemen läuft.

Code ist ein mächtiges Medium; einmal geschrieben läuft derselbe Code immer wieder oder gleichzeitig als multiple Instanzen. So führen Fehler zu einem „Ripple Effect“, bei dem kleine Fehler an einer zentralen Stelle große Auswirkungen auf das Gesamtsystem haben. Daher ist es in der Regel weitaus aufwendiger, Fehler in Code zu beheben, der bereits im Produktionssystem läuft, als bereits im Vorfeld.

Das Code Review trägt dazu bei, Qualitätsunterschiede zwischen verschiedenen Teilen der Codebase auszugleichen. Denn die Codequalität schwankt stark in Abhängigkeit der beim Schreiben des Codes vorherrschenden Umstände. Die folgenden Faktoren senken allesamt die Qualität der Codeentwicklung eines Programmierers oder einer Programmiererin:

• mangelnde Programmiererfahrung
• geringe Kenntnisse des Systems
• fehlende Vertrautheit mit Teamkonventionen
• Stress bei der Entwicklung
• Entwicklung unter Zeitdruck
• mentale Erschöpfung

Heutzutage geht der Einsatz von Code über das Schreiben von Programmen hinaus. Denn Code ist ein ausdrucksstarkes Medium, das sich zur präzisen Beschreibung von Systemen aller Art eignet. So wird Code u. a. eingesetzt, um Blockchain-basierte Smart Contracts zu realisieren oder Cloud-Umgebungen per Infrastructure-as-Code zu definieren. Auch für diese Ansätze kommt ggf. ein Code Review zum Tragen.

Die hier dargestellten Best Practices entstammen einer breitflächig angelegten empirischen Untersuchung eines Cisco-Programmierteams durch die Firma Smart Bear. Zum Teil spiegeln die Best Practices die Limitationen der menschlichen Reviewer wider. Code ist ein komplexes Medium, dessen Überprüfung viel Aufmerksamkeit benötigt. Ein Mensch verfügt über begrenzte mentale Kapazitäten, die sich mit fortlaufendem Einsatz erschöpfen. Fehlt die Aufmerksamkeit, werden Fehler leicht übersehen und die Zeit für das Code Review verschwendet.

Ferner zielen die Best Practices darauf ab, sicherzustellen, dass Code Review-Prozesse zielführend sind. Werden Fehler gefunden, dann müssen sie auch ausgebessert werden. Dies benötigt klare Zuständigkeiten und Möglichkeiten, die Prozesse zu steuern und den Fortschritt zu überwachen. Schauen wir uns die gefundenen Best Practices im Überblick an:

• Maximal 400 Zeilen Code pro Sitzung überprüfen: Bei größere Mengen Code werden Fehler leicht übersehen.
   
• Nicht mehr als 500 Zeilen Code pro Stunde überprüfen: Ansonsten leidet die Fähigkeit der Reviewer, Fehler zu erkennen.
   
• Code Reviews auf maximal 60 Minuten begrenzen: Bei längeren Code Reviews fehlt den Reviewern die benötigte Konzentration.
   
• Ziele setzen und Metriken erfassen: Wie viele Fehler werden pro Zeiteinheit oder pro Zeilen Code gefunden?
   
• Code-Autoren sollten Quelltext vor der Überprüfung annotieren: Die Annotationen leiten die Reviewer durch die Codeänderungen und erklären diese.
   
• Checklisten nutzen: Diese sollten Punkte enthalten, die bei jeder Überprüfung beachtet werden.
   
• Prozess etablieren, gefundene Fehler zu korrigieren: Es reicht nicht, Fehler bloß aufzuspüren. Um Fehler zu korrigieren, bedarf es klarer Vorgaben und Strukturen.
   
• Eine positive Code-Review-Kultur befördern: Fehler sollten nicht als persönliches Verschulden dargestellt werden, sondern als Chance, dazuzulernen.
   
• Die unterbewussten Implikationen der gegenseitigen Überprüfung nutzen: Ist bekannt, dass Code einer Überprüfung unterzogen wird, geben sich Programmierende mehr Mühe.
   
• Auf leichtgewichtige Code-Review-Prozesse setzen: Moderne Code-Review-Tools haben die Codeüberprüfung effizient gemacht.

Generell gilt Code Review als essenzieller Bestandteil der Softwareentwicklung. Denn die Vorteile der Codeüberprüfung liegen klar auf der Hand. Jedoch ergeben sich aus der Nutzung auch einige Nachteile. Schauen wir uns Vor- und Nachteile der Codeüberprüfung an.

Der primäre Vorteil der Codeüberprüfung liegt darin, Fehler im Vorfeld aufzuspüren und zu beseitigen, bevor diese negative Konsequenzen hervorrufen. Dies ist weitaus effizienter, als Fehler an einem späteren Punkt des Code-Lifecycle zu erkennen und zu berichtigen. Ist fehlerhafter Code bereits Bestandteil eines Produktivsystems, bauen ggf. andere Komponenten darauf auf, was Verbesserungen erschwert.

Doch der Nutzen regelmäßiger Code Reviews geht über die Suche einzelner Fehler hinaus. Insbesondere zählt auch der Blick aufs „Big Picture“: Wie ordnet sich der Code in die Codebase ein? Kontinuierliche Code Reviews helfen, übergreifende Muster zu erkennen und Standards festzulegen. Neben funktionalen Fehlern werden Code Smells identifiziert und angegangen. Ggf. kommen Refactoring und Design Patterns zum Einsatz, um Homogenität über mehrere Komponenten hinweg zu schaffen.

Code Reviews involvieren die Mitglieder des Programmierteams und bringen diese in Diskurs miteinander. So überrascht es nicht, dass etablierte Code-Review-Prozesse dazu beitragen, die Codefähigkeiten des Teams zu steigern. Code Reviews binden und verteilen Wissen im Team und verbessern die Codefertigkeiten einzelnen Mitglieder.

Auf Ebene der Organisation tragen Code Reviews dazu bei, eine Qualitätskultur zu etablieren. Wenn bekannt ist, dass die eigene Arbeit überprüft wird, gibt man sich tendenziell mehr Mühe. Zum Erzielen des positiven Effekts ist es ausreichend, ca. ein Drittel des erstellten Codes einem Code Review zu unterziehen.

Natürlich bedeutet ein Code Review mehr Aufwand für die Organisation. Die Codeüberprüfung kostet Zeit und bindet Mitarbeiter, ferner werden Ressourcen zur Steuerung der beteiligten Prozesse benötigt. Die aufzubringenden Kosten dienen jedoch dazu, die Codequalität zu steigern. Dabei sollte man nicht vergessen, dass mangelnde Codequalität erhebliche Kosten verursacht.

Ohne unterstützende Code-Review-Tools ist die Codeüberprüfung ggf. sehr ineffizient. Dies war besonders bei herkömmlichen Methoden problematisch, bevor sich das leichtgewichtige Code Review durchsetzte. In jedem Fall sind klare Ziele und Vorgaben für Code-Review-Prozesse vonnöten. So werden Aufwand und Nutzen kalkulierbar und Schwebezustände vermieden.

Auf Entwicklerseite sollten Code Reviews einen Zuwachs an Wissen und Teamzusammenhalt bewirken. Wichtig hierfür ist eine konstruktive und kollegiale Umgebung. Kommt es beim Code Review zu Anfeindungen oder Schuldzuweisungen, kann sich dies auf Betroffene traumatisch auswirken. Neuzugänge im Team, Mitglieder von Minderheiten und relativ unerfahrene Programmierer und Programmiererinnen sind hiervon besonders betroffen.

Die erste Form des Code Reviews war als „Fagan-Inspektion“ bekannt. Dabei handelte es sich um einen aufwendigen Prozess, der vier Personen benötigte und neben mehreren Meetings das Ausdrucken des Codes auf Papier vorsah. Wenn auch effektiv im Aufspüren von Fehlern, lässt sich die Fagan-Inspektion unmöglich in die moderne, agile Entwicklungsarbeit integrieren.

Im Gegensatz zur schwerfälligen Code-Inspektion nach Fagan kommen heutzutage leichtgewichtige Ansätze für Code Review zum Einsatz. Allesamt involvieren den oder die Urheber bzw. Urheberinnen des Codes sowie einen oder mehrere Reviewer.

Bei der „Über die Schulter“-Methode handelt es sich um die simpelste Form des Code Reviews. Der Autor oder die Autorin präsentiert einem anderen Mitglied des Entwicklungsteams (Reviewer) den geschriebenen Code. Neben der Suche nach Fehlern werden Codestrukturen besprochen und alternative Ansätze erläutert. Die direkte Kommunikation zwischen präsentierender Person und Reviewer ermöglicht schnelles Feedback und das sofortige Einpflegen von Verbesserungen.

Das „Über die Schulter“-Code-Review findet vor Ort am eigenen Rechner statt. Der Kollege oder die Kollegin schaut einem über die Schulter, während man den Code präsentiert. Dies erlaubt die Nutzung aller auf der Entwicklungsmaschine befindlichen Ressourcen und Tools. Ein „Über die Schulter“-Code-Review ist unkompliziert und lässt sich gut ad hoc abhalten.

Konzeptuell ähnlich zum „Über die Schulter“-Code-Review ist die Codeüberprüfung durch Pair-Programming. Wiederum sind zwei Mitglieder des Programmierteams involviert. Der Unterschied liegt in der zeitlichen Abfolge der Prozesse von Codeerstellung und Code-Review. Während das „Über die Schulter“-Code-Review nach der Erstellung des Codes stattfindet, sind bei der Paar-Programmierung beide Prozesse verflochten.

Während der Paar-Programmierung schreibt eine als „Driver“ bezeichnete Person Code und kümmert sich um die Details der Implementierung. Die andere Person, als „Reviewer“ bekannt, überwacht den geschriebenen Code und gibt Feedback. Dabei hat der Reviewer auch das „Big Picture“ im Auge; der Code muss nicht nur fehlerfrei sein und für sich funktionieren, sondern auch den projektübergreifenden Mustern und Regeln folgen.

Wichtig ist, dass Driver und Reviewer regelmäßig ihre Rollen tauschen. So erfolgt ein Wechsel der Perspektiven, der für ein Ausgleichen der Machtverhältnisse sorgt und beiden Personen die Möglichkeit gibt, sich mental zu erholen. Ferner wird dem Teilnehmer mit weniger Erfahrung die Chance eröffnet, in beiden Rollen dazuzulernen.

Änderungen an oder Neuzugang von Code bei größeren Projekten erfordert häufig eine Codeüberprüfung durch mehrere Personen. Das Code Review per E-Mail-Runde besteht darin, eine Übersicht der Änderungen an alle Beteiligten zu schicken. Anschließend folgen mehrere Runden E-Mail-Diskussion und das Einpflegen von Änderungen bis zum Abschluss des Reviews und dem Fertigstellen des Codes.

Wie man sich leicht vorstellen kann, dürfte der Prozess bei einer Vielzahl von Mitwirkenden schnell unübersichtlich werden. Das Code Review per E-Mail-Runde funktioniert daher am besten mit Unterstützung durch geeignete Code-Review-Tools.

Moderne Ansätze für Code Review nutzen spezielle Code-Review-Tools. Diese strukturieren die Review-Prozesse, schaffen Effizienz und sammeln Metriken. Die Tools machen Review-Prozess planbar, steuerbar und verifizierbar.

Es existiert eine große Bandbreite verfügbarer Code-Review-Tools. Teilweise sind diese integriert in bestehende Ansätze für Continuous Integration bzw. Continuous Delivery (CI/CD). Wir stellen die verschiedenen Arten von Tools samt Beispielen vor.

Die Grundlage der Code-Review-Tools bilden verteilte Versionskontrollsysteme („Distributed version control systems“, DVCS) und insbesondere das allgegenwärtige Git. Sie beinhalten die Funktionalität, Änderungen am Code zu verfolgen und als „Diffs“ sichtbar zu machen. Auf Git aufbauende Plattformen wie GitHub und GitLab verbessern die Darstellung und stellen die Arbeit im Team in den Vordergrund. Mit ihren Merge Requests bieten diese Plattformen ein integriertes Code Review vor dem Akzeptieren neuen Codes.

Diese Tools nutzen Git oder ein anderes verteiltes Versionskontrollsystem (DVCS) als Basis. Darauf aufbauend kommt für gewöhnlich eine webbasierte Benutzeroberfläche zum Einsatz, die Code Reviews im Team organisiert. Manche Code-Review-Tools verfügen ferner über eigene Kommandozeilen-Schnittstellen (Command line interface, CLI).

GitHub hat sich als Standardplattform für die webbasierte Verwaltung von Git-Repositories etabliert. Als primärer Mechanismus für Code Review kommen die sogenannten Pull Requests zum Einsatz: Möchte man Änderungen am Code eines Repositorys vornehmen, folgt man einem einfachen Schema:

1. Repository als lokale Kopie klonen
2. Änderungen in eigenem Branch vornehmen
3. Pull Request erstellen: Man bittet die Maintainer des Repositorys, die Änderungen zu überprüfen und bei positiver Bewertung in das Haupt-Repository zu mergen.

Das Code-Review-Tool Review Board stellt die Review Requests in den Vordergrund. Die moderne und freundliche Weboberfläche bietet eine Übersicht aller in Arbeit befindlicher Review Requests über Repositories und Branches hinweg. Der eigene rbt-Befehl ermöglicht einen schnellen Zugriff von der Kommandozeile aus. Neben Code lassen sich auch Grafiken und PDF-Dokumente in die Review-Prozesse einbeziehen.

Gerrit wird auf einem eigenen Server eingerichtet und fungiert als Schnittstelle zwischen Änderungen am Code und der Produktions-Codebase. Änderungen werden durch Code Review überprüft und gelangen erst bei Bestehen in die Produktion. Eine Gerrit-Installation umfasst eine selbstgehostete Git-Umgebung mit SSH-Zugriff sowie eine webbasierte Oberfläche, die über HTTPS verfügbar ist. Neben optionalen E-Mail-Benachrichtigungen enthält Gerrit ein System zum Abstimmen über Code-Änderungen.

Das Code-Review-Tool Code Collaborator von Smart Bear rückt die User Stories in den Vordergrund. Dabei handelt es sich um nutzerzentrische Spezifikationen von Funktionalität, die in Code umgesetzt und durch Tests validiert werden. Das Tool involviert neben dem Programmierteam die Manager und die Testteams und ermöglicht es, Änderungen von User Stories, Code und Testplänen konsistente Überprüfung.

Diese als „Linter“ bekannten Tools dienen dazu, Code automatisiert zu analysieren und zu formatieren und damit auf das Code Review vorzubereiten. Technisch handelt es sich um eine statische Analyse, denn der Code wird abgelesen, jedoch nicht ausgeführt. Linter kommen als Teil der CI-Pipeline zum Einsatz, um die Formatierung von Code zu vereinheitlichen bzw. den Code an Stilvorgaben anzupassen.

Die statische Analyse liefert ferner Codemetriken wie die Anzahl von Codezeilen („Lines of code“, LOC) pro Datei, Klasse oder Funktion. Auch häufige Fehler lassen sich durch Linter im Vorfeld der menschlichen Codeüberprüfung aufspüren. Dazu gehören u. a. Typisierungsfehler, SQL-Injections und Out-of-Bounds-Fehler.

Diese relativ neuen Tools funktionieren konzeptuell wie ein webbasierter Code-Editor mit Synchronisierung der Änderungen zwischen mehreren Nutzenden. Sie erlauben die Paarprogrammierung in verteilten Umgebungen und ermöglichen „Über die Schulter“-Code-Reviews über geografische Grenzen hinweg. Gerade im Zuge der Corona-Pandemie haben diese Tools große Beliebtheit erlangt.

Sowohl das webbasierte Replit als auch das in Microsofts Editor VSCode integrierte LiveShare lassen sich als kollaborative HTML-Editoren nutzen. Selbstverständlich beherrschen beide Tools weitere Sprachen und erlauben das kollaborative Arbeiten mit mehreren Dateien und sogar das Ausführen von Code.