„Wir führen nun Code-Reviews ein“. Dies ist ein Satz, der oft gesagt wird, um den Startschuss für bessere Code-Qualität und eine Wissensverteilung im Team zu geben. Bevor eine Quellcode-Änderung in den Haupt-Entwicklungszweig zurückgeführt wird, wird diese von mindestens einem anderen Entwickler begutachtet und freigeben. Man verspricht sich dadurch, dass eventuelle Fehler identifiziert werden, bevor die Quellcode-Änderung in das Produktiv-System übertragen wird und Schaden verursachen.

Code-Reviews in der Praxis

Beim Code-Review wird der Quellcode von einem weiteren Entwickler begutachtet. Dieser schaut sich diesen an und gibt Hinweise für Verbesserungen. Code-Reviews werden i.d.R. im Rahmen sog. Merge- oder Pull-Requests durchgeführt. Dabei beantragt der Entwickler eine Übernahme seiner Quellcode-Änderungen in den Haupt-Entwicklungszweig und bietet anderen Entwicklern die Möglichkeit, die Quellcode-Änderungen einzusehen und zu kommentieren.

Bei größeren Software-Projekten kann es schnell passieren, dass nicht alle Entwickler alle Funktionen der Software kennen. Dabei kann es sich um technische oder fachliche Funktionen der Software handeln. Eine technische Funktionen der Software wäre z.B., dass das verwendete Software-Framework eine Klasse für das Lesen und Schreiben von CSV-Dateien zur Verfügung stellt, der Entwickler diese jedoch nicht verwendet hat. Der Code-Reviewer könnte somit darauf hinweisen, dass es eine Klasse XY für diesen Anwendungsfall gibt, die verwendet werden sollte. Aber auch fachlich kann der Code-Reviewer Tipps geben: Angenommen ein Entwickler erweitert das Rechnungswesen-Modul einer Buchhaltungs-Software um die Behandlung der deutschen Mehrwertsteuer. In dem Fall könnte der Code-Reviewer den fachlichen Hinweis geben, dass es in Deutschland nicht nur die bereits implementierte 19% MwSt, sondern auch 7% MwSt und sogar MwSt-freie Verkäufe gibt. Dies muss bei der Entwicklung berücksichtigt werden.

Was wird dabei vergessen?

Bei den o.a. Beispielen handelt es sich jeweils um den Fall, dass der im Merge-bzw. Pull-Request ersichtliche Quellcode begutachtet und kommentiert wird. Dies ist sehr bequem, da lediglich durch den Merge-Request gescrollt und der Quellcode nach technischen und fachlichen Fehlern durchsucht werden muss. Ein solcher Code-Review ist jedoch nur die halbe Miete. Genauso wichtig ist der restliche Quellcode, der nur indirekt durch die Quellcode-Änderung betroffen ist. Eine Änderung am Datenmodell kann z.B. auch eine Änderung eines Datenbankfeldes erfordern. Das o.a. Beispiel der MwSt-Berechnung kann z.B. erfordern, dass auch die angebundene DATEV-Schnittstelle für den Steuerberater um die MwSt-Behandlung erweitert werden muss.

Fazit

Es muss nicht nur ein Review der Quellcode-Änderungen durchgeführt, sondern auch immer die direkt und indirekt beeinflussten Software-Komponenten (ggf. auch angebundener Software-Projekte) berücksichtigt werden. Der Reviewer benötigt dafür einen umfassenden technischen und fachlichen Überblick über die Software, um eine Quellcode-Änderung beurteilen zu können. Wird der Fokus beim Code-Review nur auf den hinzugefügten und entfernten Quellcode gerichtet, wird das Auftreten von Seiteneffekten riskiert. Dadurch bekommt man dann das bekannte „Wir korrigieren einen Fehler und an zwei anderen Stellen geht etwas kaputt“-Gefühl.

Beim Code-Review bitte nicht nur auf die Quellcode-Formatierung und die Benamung der Variablen achten, sondern einen ganzheitlichen Blick auf die Quellcode-Änderungen und deren Auswirkungen auf andere Bereiche der Software werfen. Dann klappt’s auch mit der Reduzierung der Bug-Quote!


0 Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert