Es war ja gut gemeint – das Team wollte (sollte?) regelmäßige Code Reviews machen. Das heißt, bevor eine größere Änderung in die Applikation übernommen wird, schaut nochmal ein anderer Entwickler drüber. Damit kann man Flüchtigkeitsfehler entdecken, oder auf Probleme aufmerksam machen, an die der Autor dieser Änderung nicht gedacht hat. Das funktioniert so ähnlich wie der “Peer Review” - Prozess in der Wissenschaft. Dort wird jeder Artikel von Fachkollegen geprüft, bevor er zur Veröffentlichung freigegeben wird,

Auf GitHub wird dieses Vorgehen sehr schön unterstützt: Wenn ich eine Aufgabe erledigt habe, fasse ich meine Änderungen zu einem “Pull Request” zusammen. Ich beschreibe, warum ich diese Änderungen machen will, gebe vielleicht noch ein paar Hinweise für den Reviewer und für das Testen. Meist gibt es auch einen Link zu einem Ticket, in dem die Aufgabe beschrieben ist.

Dann sieht sich ein Kollege meinen Pull Request an, und wenn es keinen Diskussionsbedarf gibt, kann er meine Änderungen mit einem Knopfdruck in den Haupt-Entwicklungsstrang übernehmen (“Merge”). Wenn etwas unklar ist oder geändert werden sollte, kann man an der entsprechenden Zeile einen Kommentar hinzufügen. Manchmal entspinnen sich dann Diskussionen, weitere Änderungen werden gemacht usw., bis beide, Autor und Reviewer, zufrieden sind. Wenn so ein Review-Prozess gut praktiziert wird, hat das vielfältige positive Auswirkungen auf die Code-Qualität. So führt z.B. allein der Gedanke, dass mein Code vor den Augen eines Kollegen bestehen muss, schon zur besseren Einhaltung von gemeinsam definierten Standards.

So weit die Theorie. In dem oben erwähnten Team gab es auch 100% Code Review d.h. jeder Pull Request musste von jemand anderem gesehen und akzeptiert werden. Nur wenn man sich das auf GitHub ansah, fand man, dass es über Monate keinerlei Diskussionen gab. Alle Pull Requests wurden also einfach durchgewunken. Lag es daran, dass die Entwickler immer auf Anhieb alles richtig gemacht hatten? Sicher nicht. Wieder ein Beispiel dafür, dass etwas oberflächlich gut aussieht (“Wir machen 100% Code Review”), ohne dass das dahinter stehende Ziel erreicht wird.

Übrigens: Der Artikel How to do code review in a Pull Request auf dem Codacy Blog gibt gute Hinweise, wie man sinnvolle und hilfreiche Code Reviews machen kann.

Matthias Berth