Denn: Ein ordentlich gestaltetes Code Review macht nicht nur das Entwicklungsteam selber zufrieden, sondern längerfristig auch AnwenderInnen und AuftraggeberInnen.

‍

Wozu Code Reviews?

Grundsätzlich dienen Code Reviews zur Verbesserung der Qualität der Codebase. Jeder Commit, jeder Merge und jedes Feature sollen die Qualität steigern und die beste Möglichkeit das zu garantieren, ist ein Code Review. Hier lassen sich Fehler und Bugs frühzeitig erkennen, was hilft, technische Schulden zu vermeiden und dadurch längerfristig Zeit zu sparen. 

Neben funktionalen Fehlern können beim Code Review auch Punkte wie Architektur und Code Style angesprochen werden. Diese tragen ebenso zur Qualität bei, lassen sich aber nicht durch Automatismen wie Unit Tests überprüfen.

Wie Code Reviews abhalten?

Vor Beginn des Code Reviews soll sichergestellt werden, dass alle TeilnehmerInnen am aktuellen Stand sind. Das betrifft sowohl die Version des Codes als auch das Wissen über den Code. Die reviewenden Personen müssen wissen, was der Teil des Programms machen soll, da Code, von dem man nichts weiß, nur schwer ordentlich durchgeschaut werden kann. Ebenso wichtig ist es, dass alle Tests erfolgreich durchlaufen, bevor man das Code Review startet. Es macht nur wenig Sinn, funktional fehlerhaften Code auf Qualität zu überprüfen.

Das Code Review selber kann auf viele verschiedene Arten stattfinden: persönlich oder remote, gemeinsam im Team oder one-on-one, als eigenes Meeting oder per Austausch durch einschlägige Kommunikationstools. Die Schritte bleiben gleich, lediglich die Menge des Inputs und die Länge der Feedback Cycles unterscheiden sich.

Die erste Aufgabe im Code Review ist es, den Code durchzusehen, zu verstehen und aufgrund festgelegter Kriterien zu bewerten. Falls Mängel festgestellt werden, gilt es diese anzusprechen und die entsprechende Stelle richtig zu kritisieren. Jedoch ist es nur mit Aufzeigen der Fehler noch nicht getan. Im Anschluss müssen auch noch Lösungen gefunden werden, die am besten anhand von konkreten Beispielen veranschaulicht werden können.

Um bei Code Reviews nicht den Faden zu verlieren, bietet es sich an, eine Checkliste zu erstellen. So kann eine Struktur in das Code Review gebracht werden, an die sich alle TeilnehmerInnen halten. Aber dazu später mehr.

Was gibt es zu beachten?

Sehr wichtig ist es, das Code Review nicht zu groß aufzuziehen. Von tausend Zeilen Code erschlagen zu werden, führt oft dazu, dass weniger kritisch bewertet wird. Ebenso darf das Code Review nicht zu lange dauern, da sonst die Konzentration der Teilnehmer zu stark nachlässt und Fehler übersehen werden.

‍

Zusammenfassend gesagt: Bei steigender kognitiver Last lässt die Effektivität des Code Reviews nach. Daher sind kleine Code Reviews, die häufiger gemacht werden, besser als groß angelegte, die beispielsweise ein ganzes Feature durchgehen. Grobe Richtlinien für Dauer und Menge sind maximal eine Stunde und weniger als 400 Lines of Code.

‍

Um die Code Qualität objektiv bewerten zu können, braucht es konkrete Metriken, an denen man diese festmachen kann. Diese können bestimmte Werte sein (wie die Testabdeckung in Prozent) oder Richtlinien, die befolgt werden müssen (etwa ein Style Guide). Am besten verwenden Teams in der Zusammenarbeit für diese Metriken auch Tools, die automatisch Alarm schlagen. Beispielsweise findet statische Code Analyse häufige Fehlerquellen, welche dann gleich ohne viel Diskussion ausgebessert werden können. Idealerweise werden diese Tools schon bei der Entwicklung verwendet, um die dadurch gefundenen Fehler nicht mehr beim Code Review ansprechen zu müssen.

Der wohl wichtigste Punkt hat jedoch weniger mit dem Technischen als mit dem Menschlichen zu tun. Das richtige Kritisieren hat große Bedeutung für den Erfolg eines Code Reviews. Es geht nicht darum, zu zeigen, wie gut man selber programmieren kann, oder sein Gegenüber in Grund und Boden zu reden, sondern darum, die Qualität des Codes zu steigern. Dies erreicht man am besten, indem die Kritik sachlich bleibt, Begründungen gegeben werden und man sich nicht auf die Person bezieht, die den Code produziert hat (kein “Du”!). Es ist auch nicht verboten, Positives zu erwähnen, schließlich bekommt jeder gern Komplimente. Generell sollte beim Code Review eine positive Stimmung herrschen, dann ist es auch am effektivsten.

Code Review Checklisten

Wie oben bereits erwähnt, sind Code Review Checklisten eine Art Leitfaden und stellen sicher, dass nichts vergessen wird. Auf der Checkliste werden Merkmale notiert, auf die der Code überprüft werden soll. Was diese Merkmale sind, wird vom Team entschieden. Hat ein Team keine Checkliste, so sollte zu Beginn nur eine kleine erstellt werden (siehe Beispiel unten). Diese kann dann mit der Zeit erweitert und verbessert werden, ganz nach Ermessen des Teams. Mit steigender Qualität der Checkliste, steigt auch die Qualität des Code Reviews und dadurch auch des Codes an sich.

‍

Starter-Checkliste:

• Der Code ist verständlich.
• Festgelegte Code Standards sind erfüllt.
• Es sind Tests für die Änderungen vorhanden.
• Der Code erfüllt die technischen Anforderungen.

‍

‍

Zur Profi-Checkliste: Sie möchten einfach und schnell Ihren Code auf dessen Qualität checken?

Hier finden Sie die konkrete Objectbay Code Review Checkliste, die Sie Schritt für Schritt durch den Review Prozess führt.