Code Review: Methoden und Tools vor­ge­stellt

Code Review ist ein in­te­gra­ler Be­stand­teil der modernen Soft­ware­ent­wick­lung. Die Code­über­prü­fung durch andere Mit­glie­der des Pro­gram­mier­teams deckt Fehler auf und trägt zur Ver­bes­se­rung der Code­qua­li­tät bei. Dabei kommen un­ter­schied­li­che Techniken und Ansätze zum Einsatz, die wir im Folgenden näher vor­stel­len.

Bei Code Review, zu Deutsch „Code­über­prü­fung“, handelt es sich um eine Maßnahme zur Qua­li­täts­si­che­rung bei der Soft­ware­ent­wick­lung. Quellcode ist das grund­le­gen­de Medium der Ent­wick­lungs­ar­beit und primäres Produkt der Pro­gram­mie­rung. Neu­erstell­ter oder ver­än­der­ter Code wird einem Code Review un­ter­zo­gen. Dabei über­prü­fen ein oder mehrere Team­mit­glie­der die Arbeit eines Pro­gram­mie­rers oder einer Pro­gram­mie­re­rin.

Ein Soft­ware­pro­jekt umfasst eine „Codebase“ – eine Sammlung von Code-Dateien, die zu­sam­men­ge­nom­men dazu dienen, ein Produkt aus­zu­lie­fern. Dazu gehören der ei­gent­li­che Produkt-Code, Kon­fi­gu­ra­ti­on, Ent­wick­lungs-Tools, Tests und mehr, allesamt in Code ab­ge­bil­det. Die gesamte Codebase wird mit einem Ver­si­ons­kon­troll­sys­tem wie Git verwaltet. Über mehrere „Branches“, zu Deutsch „Äste“, lassen sich mehrere Versionen der Codebase parallel verwalten. So kann die Ent­wick­lung neuer Features fort­schrei­ten, ohne dass die Pro­duk­ti­ons­ver­si­on der Codebase verändert wird.

Die Ent­wick­lungs­ar­beit findet für ge­wöhn­lich auf so­ge­nann­ten Feature-Branches statt, die pe­ri­odisch in den Main-Branch in­te­griert werden. Die Code­über­prü­fung wird vor dem „Merge“ durch­ge­führt, d. h. bevor neuer oder ver­än­der­ter Code mit der be­stehen­den Codebase zu­sam­men­ge­führt wird. Ziel ist, Fehler früh­zei­tig zu erkennen und zu be­sei­ti­gen, bevor der Code in die Pro­duk­ti­on geht.

Doch das Ausmerzen von Bugs ist nicht der einzige Nutzen der Code­über­prü­fung. Dass Code funk­tio­niert, also feh­ler­frei läuft und das ge­wünsch­te Ergebnis erzielt, ist lediglich eine Grund­vor­aus­set­zung. Darüber hinaus gibt es eine Vielzahl weiterer Gü­te­kri­te­ri­en für Clean Code. Das Vor­han­den­sein von Kom­men­ta­ren, die Klarheit und Kon­sis­tenz des Codes, das Erfüllen von Stil­vor­ga­ben und die In­te­grier­bar­keit in exis­tie­ren­de Systeme sind allesamt kritisch und werden beim Code Review beachtet.

Da die Ent­wick­lungs­ar­beit größ­ten­teils in Gruppen statt­fin­det, gehen Aus­wir­kun­gen von Code Review über die reine Code­qua­li­tät hinaus. Denn die Code­über­prü­fung erfolgt durch andere Mit­glie­der des Ent­wick­lungs­teams und erzeugt soziale Effekte: Neue Mit­glie­der erhalten Feedback zu Kon­ven­tio­nen und Best Practices, Wissen wird innerhalb der Or­ga­ni­sa­ti­on aus­ge­tauscht und verteilt. So trägt die Code­über­prü­fung dazu bei, eine Qua­li­täts­kul­tur zu pflegen.

Auch wenn die Code­über­prü­fung von Menschen vor­ge­nom­men wird, werden die Code-Review-Prozesse heut­zu­ta­ge für ge­wöhn­lich durch spezielle Code-Review-Tools un­ter­stützt. Code-Review-Tools schaffen Effizienz und entlasten die be­tei­lig­ten Personen von der klein­tei­li­gen und auf­wen­di­gen Ko­or­di­na­ti­on der Prozesse. So können sich die Menschen auf das ei­gent­li­che Code Review kon­zen­trie­ren.

Kon­zep­tu­ell liegt das Code Review durch Menschen zwischen zwei au­to­ma­ti­sier­ten Ana­ly­se­me­tho­den, der sta­ti­schen und der dy­na­mi­schen Analyse. Die Un­ter­schie­de im Überblick:

Das Konzept eines Code Review ist an sich simpel: Ver­än­der­ter oder neu­ge­schrie­be­ner Code wird von einem oder mehreren Mit­glie­dern des Ent­wick­lungs­teams (genannt „Reviewer“) auf Kor­rekt­heit überprüft. Die Reviewer lesen den Code und iden­ti­fi­zie­ren mögliche Fehler sowie Ab­wei­chun­gen von den im Team eta­blier­ten Kon­ven­tio­nen. Entweder ver­bes­sern die Reviewer den Code im Anschluss oder sie übergeben ihre Er­kennt­nis­se an die ur­sprüng­li­chen Autoren bzw. Au­torin­nen, die die Än­de­run­gen ein­pfle­gen.

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 De­tail­fra­gen: Welche Än­de­run­gen gehören zusammen und wie werden diese den Reviewern über­mit­telt? Wie werden gefundene Fehler und Kom­men­ta­re den ent­spre­chen­den Stellen im Code zu­ge­ord­net und den für die Ver­bes­se­rung Ver­ant­wort­li­chen zur Verfügung gestellt? Ohne spezielle Code-Review-Tools lässt sich dies nur innerhalb kleinster Teams ko­or­di­nie­ren.

In ver­teil­ten, agilen Pro­gram­mier­teams ist Code Review meistens ein fester Teil des Ent­wick­lungs­pro­zes­ses. Im Rahmen der Con­ti­nuous In­te­gra­ti­on (CI) wird Code kon­ti­nu­ier­lich ge­schrie­ben, getestet und in die be­stehen­de Codebase ein­ge­pflegt. Das Code Review durch einen Menschen ist Teil der au­to­ma­ti­sier­ten CI-Pipeline, die jede Einheit Code durch­läuft. Nur wenn alle Tests bestanden werden, wird der Code in­te­griert und im Anschluss an Pro­duk­ti­ons­sys­te­me aus­ge­spielt.

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 in­te­grie­ren
   1. Code auf Feature-Branch au­to­ma­ti­siert ana­ly­sie­ren und for­ma­tie­ren
   2. Code Review durch­füh­ren und Ver­bes­se­run­gen ein­pfle­gen
   3. Code in Main-Branch mergen
   4. Main-Branch auf Staging-Site aus­spie­len und testen
       
3. Code in Pro­duk­ti­on bringen
   1. Code in Release-Branch mergen
   2. Release-Branch auf Live-Site aus­spie­len

Das Code Review ist ein wichtiger Be­stand­teil der Qua­li­täts­kon­trol­le bei der Soft­ware­ent­wick­lung. So stellt die Code­über­prü­fung sicher, dass neu­ge­schrie­be­ner Code möglichst feh­ler­frei ist und den Qua­li­täts­stan­dards der Or­ga­ni­sa­ti­on genügt. Lang­fris­tig minimiert dies tech­ni­sche Schulden; kurz­fris­tig wird ver­hin­dert, dass feh­ler­haf­ter Code auf Pro­duk­ti­ons­sys­te­men läuft.

Code ist ein mächtiges Medium; einmal ge­schrie­ben läuft derselbe Code immer wieder oder gleich­zei­tig als multiple Instanzen. So führen Fehler zu einem „Ripple Effect“, bei dem kleine Fehler an einer zentralen Stelle große Aus­wir­kun­gen auf das Ge­samt­sys­tem haben. Daher ist es in der Regel weitaus auf­wen­di­ger, Fehler in Code zu beheben, der bereits im Pro­duk­ti­ons­sys­tem läuft, als bereits im Vorfeld.

Das Code Review trägt dazu bei, Qua­li­täts­un­ter­schie­de zwischen ver­schie­de­nen Teilen der Codebase aus­zu­glei­chen. Denn die Code­qua­li­tät schwankt stark in Ab­hän­gig­keit der beim Schreiben des Codes vor­herr­schen­den Umstände. Die folgenden Faktoren senken allesamt die Qualität der Code­ent­wick­lung eines Pro­gram­mie­rers oder einer Pro­gram­mie­re­rin:

• mangelnde Pro­gram­mier­erfah­rung
• geringe Kennt­nis­se des Systems
• fehlende Ver­traut­heit mit Team­kon­ven­tio­nen
• Stress bei der Ent­wick­lung
• Ent­wick­lung unter Zeitdruck
• mentale Er­schöp­fung

Heut­zu­ta­ge geht der Einsatz von Code über das Schreiben von Pro­gram­men hinaus. Denn Code ist ein aus­drucks­star­kes Medium, das sich zur präzisen Be­schrei­bung von Systemen aller Art eignet. So wird Code u. a. ein­ge­setzt, um Block­chain-basierte Smart Contracts zu rea­li­sie­ren oder Cloud-Um­ge­bun­gen per In­fra­struc­tu­re-as-Code zu de­fi­nie­ren. Auch für diese Ansätze kommt ggf. ein Code Review zum Tragen.

Die hier dar­ge­stell­ten Best Practices ent­stam­men einer breit­flä­chig an­ge­leg­ten em­pi­ri­schen Un­ter­su­chung eines Cisco-Pro­gram­mier­teams durch die Firma Smart Bear. Zum Teil spiegeln die Best Practices die Li­mi­ta­tio­nen der mensch­li­chen Reviewer wider. Code ist ein komplexes Medium, dessen Über­prü­fung viel Auf­merk­sam­keit benötigt. Ein Mensch verfügt über begrenzte mentale Ka­pa­zi­tä­ten, die sich mit fort­lau­fen­dem Einsatz er­schöp­fen. Fehlt die Auf­merk­sam­keit, werden Fehler leicht übersehen und die Zeit für das Code Review ver­schwen­det.

Ferner zielen die Best Practices darauf ab, si­cher­zu­stel­len, dass Code Review-Prozesse ziel­füh­rend sind. Werden Fehler gefunden, dann müssen sie auch aus­ge­bes­sert werden. Dies benötigt klare Zu­stän­dig­kei­ten und Mög­lich­kei­ten, die Prozesse zu steuern und den Fort­schritt zu über­wa­chen. Schauen wir uns die ge­fun­de­nen Best Practices im Überblick an:

• Maximal 400 Zeilen Code pro Sitzung über­prü­fen: Bei größere Mengen Code werden Fehler leicht übersehen.
   
• Nicht mehr als 500 Zeilen Code pro Stunde über­prü­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 Kon­zen­tra­ti­on.
   
• Ziele setzen und Metriken erfassen: Wie viele Fehler werden pro Zeit­ein­heit oder pro Zeilen Code gefunden?
   
• Code-Autoren sollten Quelltext vor der Über­prü­fung an­no­tie­ren: Die An­no­ta­tio­nen leiten die Reviewer durch die Code­än­de­run­gen und erklären diese.
   
• Check­lis­ten nutzen: Diese sollten Punkte enthalten, die bei jeder Über­prü­fung beachtet werden.
   
• Prozess eta­blie­ren, gefundene Fehler zu kor­ri­gie­ren: Es reicht nicht, Fehler bloß auf­zu­spü­ren. Um Fehler zu kor­ri­gie­ren, bedarf es klarer Vorgaben und Struk­tu­ren.
   
• Eine positive Code-Review-Kultur befördern: Fehler sollten nicht als per­sön­li­ches Ver­schul­den dar­ge­stellt werden, sondern als Chance, da­zu­zu­ler­nen.
   
• Die un­ter­be­wuss­ten Im­pli­ka­tio­nen der ge­gen­sei­ti­gen Über­prü­fung nutzen: Ist bekannt, dass Code einer Über­prü­fung un­ter­zo­gen wird, geben sich Pro­gram­mie­ren­de mehr Mühe.
   
• Auf leicht­ge­wich­ti­ge Code-Review-Prozesse setzen: Moderne Code-Review-Tools haben die Code­über­prü­fung effizient gemacht.

Generell gilt Code Review als es­sen­zi­el­ler Be­stand­teil der Soft­ware­ent­wick­lung. Denn die Vorteile der Code­über­prü­fung liegen klar auf der Hand. Jedoch ergeben sich aus der Nutzung auch einige Nachteile. Schauen wir uns Vor- und Nachteile der Code­über­prü­fung an.

Der primäre Vorteil der Code­über­prü­fung liegt darin, Fehler im Vorfeld auf­zu­spü­ren und zu be­sei­ti­gen, bevor diese negative Kon­se­quen­zen her­vor­ru­fen. Dies ist weitaus ef­fi­zi­en­ter, als Fehler an einem späteren Punkt des Code-Lifecycle zu erkennen und zu be­rich­ti­gen. Ist feh­ler­haf­ter Code bereits Be­stand­teil eines Pro­duk­tiv­sys­tems, bauen ggf. andere Kom­po­nen­ten darauf auf, was Ver­bes­se­run­gen erschwert.

Doch der Nutzen re­gel­mä­ßi­ger Code Reviews geht über die Suche einzelner Fehler hinaus. Ins­be­son­de­re zählt auch der Blick aufs „Big Picture“: Wie ordnet sich der Code in die Codebase ein? Kon­ti­nu­ier­li­che Code Reviews helfen, über­grei­fen­de Muster zu erkennen und Standards fest­zu­le­gen. Neben funk­tio­na­len Fehlern werden Code Smells iden­ti­fi­ziert und an­ge­gan­gen. Ggf. kommen Re­fac­to­ring und Design Patterns zum Einsatz, um Ho­mo­ge­ni­tät über mehrere Kom­po­nen­ten hinweg zu schaffen.

Code Reviews in­vol­vie­ren die Mit­glie­der des Pro­gram­mier­teams und bringen diese in Diskurs mit­ein­an­der. So über­rascht es nicht, dass eta­blier­te Code-Review-Prozesse dazu beitragen, die Code­fä­hig­kei­ten des Teams zu steigern. Code Reviews binden und verteilen Wissen im Team und ver­bes­sern die Code­fer­tig­kei­ten einzelnen Mit­glie­der.

Auf Ebene der Or­ga­ni­sa­ti­on tragen Code Reviews dazu bei, eine Qua­li­täts­kul­tur zu eta­blie­ren. Wenn bekannt ist, dass die eigene Arbeit überprüft wird, gibt man sich ten­den­zi­ell mehr Mühe. Zum Erzielen des positiven Effekts ist es aus­rei­chend, ca. ein Drittel des er­stell­ten Codes einem Code Review zu un­ter­zie­hen.

Natürlich bedeutet ein Code Review mehr Aufwand für die Or­ga­ni­sa­ti­on. Die Code­über­prü­fung kostet Zeit und bindet Mit­ar­bei­ter, ferner werden Res­sour­cen zur Steuerung der be­tei­lig­ten Prozesse benötigt. Die auf­zu­brin­gen­den Kosten dienen jedoch dazu, die Code­qua­li­tät zu steigern. Dabei sollte man nicht vergessen, dass mangelnde Code­qua­li­tät er­heb­li­che Kosten ver­ur­sacht.

Ohne un­ter­stüt­zen­de Code-Review-Tools ist die Code­über­prü­fung ggf. sehr in­ef­fi­zi­ent. Dies war besonders bei her­kömm­li­chen Methoden pro­ble­ma­tisch, bevor sich das leicht­ge­wich­ti­ge Code Review durch­setz­te. In jedem Fall sind klare Ziele und Vorgaben für Code-Review-Prozesse vonnöten. So werden Aufwand und Nutzen kal­ku­lier­bar und Schwe­be­zu­stän­de vermieden.

Auf Ent­wick­ler­sei­te sollten Code Reviews einen Zuwachs an Wissen und Team­zu­sam­men­halt bewirken. Wichtig hierfür ist eine kon­struk­ti­ve und kol­le­gia­le Umgebung. Kommt es beim Code Review zu An­fein­dun­gen oder Schuld­zu­wei­sun­gen, kann sich dies auf Be­trof­fe­ne trau­ma­tisch auswirken. Neu­zu­gän­ge im Team, Mit­glie­der von Min­der­hei­ten und relativ un­er­fah­re­ne Pro­gram­mie­rer und Pro­gram­mie­re­rin­nen sind hiervon besonders betroffen.

Die erste Form des Code Reviews war als „Fagan-In­spek­ti­on“ bekannt. Dabei handelte es sich um einen auf­wen­di­gen Prozess, der vier Personen benötigte und neben mehreren Meetings das Aus­dru­cken des Codes auf Papier vorsah. Wenn auch effektiv im Aufspüren von Fehlern, lässt sich die Fagan-In­spek­ti­on unmöglich in die moderne, agile Ent­wick­lungs­ar­beit in­te­grie­ren.

Im Gegensatz zur schwer­fäl­li­gen Code-In­spek­ti­on nach Fagan kommen heut­zu­ta­ge leicht­ge­wich­ti­ge Ansätze für Code Review zum Einsatz. Allesamt in­vol­vie­ren den oder die Urheber bzw. Ur­he­be­rin­nen 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ä­sen­tiert einem anderen Mitglied des Ent­wick­lungs­teams (Reviewer) den ge­schrie­be­nen Code. Neben der Suche nach Fehlern werden Code­struk­tu­ren be­spro­chen und al­ter­na­ti­ve Ansätze erläutert. Die direkte Kom­mu­ni­ka­ti­on zwischen prä­sen­tie­ren­der Person und Reviewer er­mög­licht schnelles Feedback und das sofortige Ein­pfle­gen von Ver­bes­se­run­gen.

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ä­sen­tiert. Dies erlaubt die Nutzung aller auf der Ent­wick­lungs­ma­schi­ne be­find­li­chen Res­sour­cen und Tools. Ein „Über die Schulter“-Code-Review ist un­kom­pli­ziert und lässt sich gut ad hoc abhalten.

Kon­zep­tu­ell ähnlich zum „Über die Schulter“-Code-Review ist die Code­über­prü­fung durch Pair-Pro­gramming. Wiederum sind zwei Mit­glie­der des Pro­gram­mier­teams in­vol­viert. Der Un­ter­schied liegt in der zeit­li­chen Abfolge der Prozesse von Code­er­stel­lung und Code-Review. Während das „Über die Schulter“-Code-Review nach der Er­stel­lung des Codes statt­fin­det, sind bei der Paar-Pro­gram­mie­rung beide Prozesse ver­floch­ten.

Während der Paar-Pro­gram­mie­rung schreibt eine als „Driver“ be­zeich­ne­te Person Code und kümmert sich um die Details der Im­ple­men­tie­rung. Die andere Person, als „Reviewer“ bekannt, überwacht den ge­schrie­be­nen Code und gibt Feedback. Dabei hat der Reviewer auch das „Big Picture“ im Auge; der Code muss nicht nur feh­ler­frei sein und für sich funk­tio­nie­ren, sondern auch den pro­jekt­über­grei­fen­den Mustern und Regeln folgen.

Wichtig ist, dass Driver und Reviewer re­gel­mä­ßig ihre Rollen tauschen. So erfolgt ein Wechsel der Per­spek­ti­ven, der für ein Aus­glei­chen der Macht­ver­hält­nis­se sorgt und beiden Personen die Mög­lich­keit gibt, sich mental zu erholen. Ferner wird dem Teil­neh­mer mit weniger Erfahrung die Chance eröffnet, in beiden Rollen da­zu­zu­ler­nen.

Än­de­run­gen an oder Neuzugang von Code bei größeren Projekten erfordert häufig eine Code­über­prü­fung durch mehrere Personen. Das Code Review per E-Mail-Runde besteht darin, eine Übersicht der Än­de­run­gen an alle Be­tei­lig­ten zu schicken. An­schlie­ßend folgen mehrere Runden E-Mail-Dis­kus­si­on und das Ein­pfle­gen von Än­de­run­gen bis zum Abschluss des Reviews und dem Fer­tig­stel­len des Codes.

Wie man sich leicht vor­stel­len kann, dürfte der Prozess bei einer Vielzahl von Mit­wir­ken­den schnell un­über­sicht­lich werden. Das Code Review per E-Mail-Runde funk­tio­niert daher am besten mit Un­ter­stüt­zung durch geeignete Code-Review-Tools.

Moderne Ansätze für Code Review nutzen spezielle Code-Review-Tools. Diese struk­tu­rie­ren die Review-Prozesse, schaffen Effizienz und sammeln Metriken. Die Tools machen Review-Prozess planbar, steuerbar und ve­ri­fi­zier­bar.

Es existiert eine große Band­brei­te ver­füg­ba­rer Code-Review-Tools. Teilweise sind diese in­te­griert in be­stehen­de Ansätze für Con­ti­nuous In­te­gra­ti­on bzw. Con­ti­nuous Delivery (CI/CD). Wir stellen die ver­schie­de­nen Arten von Tools samt Bei­spie­len vor.

Die Grundlage der Code-Review-Tools bilden verteilte Ver­si­ons­kon­troll­sys­te­me („Dis­tri­bu­ted version control systems“, DVCS) und ins­be­son­de­re das all­ge­gen­wär­ti­ge Git. Sie be­inhal­ten die Funk­tio­na­li­tät, Än­de­run­gen am Code zu verfolgen und als „Diffs“ sichtbar zu machen. Auf Git auf­bau­en­de Platt­for­men wie GitHub und GitLab ver­bes­sern die Dar­stel­lung und stellen die Arbeit im Team in den Vor­der­grund. Mit ihren Merge Requests bieten diese Platt­for­men ein in­te­grier­tes Code Review vor dem Ak­zep­tie­ren neuen Codes.

Diese Tools nutzen Git oder ein anderes ver­teil­tes Ver­si­ons­kon­troll­sys­tem (DVCS) als Basis. Darauf aufbauend kommt für ge­wöhn­lich eine web­ba­sier­te Be­nut­zer­ober­flä­che zum Einsatz, die Code Reviews im Team or­ga­ni­siert. Manche Code-Review-Tools verfügen ferner über eigene Kom­man­do­zei­len-Schnitt­stel­len (Command line interface, CLI).

GitHub hat sich als Stan­dard­platt­form für die web­ba­sier­te Ver­wal­tung von Git-Re­po­si­to­ries etabliert. Als primärer Me­cha­nis­mus für Code Review kommen die so­ge­nann­ten Pull Requests zum Einsatz: Möchte man Än­de­run­gen am Code eines Re­po­si­to­rys vornehmen, folgt man einem einfachen Schema:

1. Re­po­si­to­ry als lokale Kopie klonen
2. Än­de­run­gen in eigenem Branch vornehmen
3. Pull Request erstellen: Man bittet die Main­tai­ner des Re­po­si­to­rys, die Än­de­run­gen zu über­prü­fen und bei positiver Bewertung in das Haupt-Re­po­si­to­ry zu mergen.

Das Code-Review-Tool Review Board stellt die Review Requests in den Vor­der­grund. Die moderne und freund­li­che Web­ober­flä­che bietet eine Übersicht aller in Arbeit be­find­li­cher Review Requests über Re­po­si­to­ries und Branches hinweg. Der eigene rbt-Befehl er­mög­licht einen schnellen Zugriff von der Kom­man­do­zei­le aus. Neben Code lassen sich auch Grafiken und PDF-Dokumente in die Review-Prozesse ein­be­zie­hen.

Gerrit wird auf einem eigenen Server ein­ge­rich­tet und fungiert als Schnitt­stel­le zwischen Än­de­run­gen am Code und der Pro­duk­ti­ons-Codebase. Än­de­run­gen werden durch Code Review überprüft und gelangen erst bei Bestehen in die Pro­duk­ti­on. Eine Gerrit-In­stal­la­ti­on umfasst eine selbst­ge­hos­te­te Git-Umgebung mit SSH-Zugriff sowie eine web­ba­sier­te Ober­flä­che, die über HTTPS verfügbar ist. Neben op­tio­na­len E-Mail-Be­nach­rich­ti­gun­gen enthält Gerrit ein System zum Abstimmen über Code-Än­de­run­gen.

Das Code-Review-Tool Code Col­la­bo­ra­tor von Smart Bear rückt die User Stories in den Vor­der­grund. Dabei handelt es sich um nut­zer­zen­tri­sche Spe­zi­fi­ka­tio­nen von Funk­tio­na­li­tät, die in Code umgesetzt und durch Tests validiert werden. Das Tool in­vol­viert neben dem Pro­gram­mier­team die Manager und die Testteams und er­mög­licht es, Än­de­run­gen von User Stories, Code und Test­plä­nen kon­sis­ten­te Über­prü­fung.

Diese als „Linter“ bekannten Tools dienen dazu, Code au­to­ma­ti­siert zu ana­ly­sie­ren und zu for­ma­tie­ren und damit auf das Code Review vor­zu­be­rei­ten. Technisch handelt es sich um eine statische Analyse, denn der Code wird abgelesen, jedoch nicht aus­ge­führt. Linter kommen als Teil der CI-Pipeline zum Einsatz, um die For­ma­tie­rung von Code zu ver­ein­heit­li­chen bzw. den Code an Stil­vor­ga­ben an­zu­pas­sen.

Die statische Analyse liefert ferner Code­me­tri­ken wie die Anzahl von Code­zei­len („Lines of code“, LOC) pro Datei, Klasse oder Funktion. Auch häufige Fehler lassen sich durch Linter im Vorfeld der mensch­li­chen Code­über­prü­fung aufspüren. Dazu gehören u. a. Ty­pi­sie­rungs­feh­ler, SQL-In­jec­tions und Out-of-Bounds-Fehler.

Diese relativ neuen Tools funk­tio­nie­ren kon­zep­tu­ell wie ein web­ba­sier­ter Code-Editor mit Syn­chro­ni­sie­rung der Än­de­run­gen zwischen mehreren Nutzenden. Sie erlauben die Paar­pro­gram­mie­rung in ver­teil­ten Um­ge­bun­gen und er­mög­li­chen „Über die Schulter“-Code-Reviews über geo­gra­fi­sche Grenzen hinweg. Gerade im Zuge der Corona-Pandemie haben diese Tools große Be­liebt­heit erlangt.

Sowohl das web­ba­sier­te Replit als auch das in Mi­cro­softs Editor VSCode in­te­grier­te LiveShare lassen sich als kol­la­bo­ra­ti­ve HTML-Editoren nutzen. Selbst­ver­ständ­lich be­herr­schen beide Tools weitere Sprachen und erlauben das kol­la­bo­ra­ti­ve Arbeiten mit mehreren Dateien und sogar das Ausführen von Code.