Code-Reviews, ganz persönlich

Immer wieder begegne ich Entwicklern, die Tools für Code-Reviews benutzen. Ich tue das nicht mehr. Bisher ist mir kein einziges Review-Tool begegnet, das es mir ermöglicht, einen Review in der Qualität durchzuführen, die ich anstrebe. Weder Crucible, noch Jupiter oder mein Namensvetter Gerrit.

Das Resultat vieler Reviews, die in solchen Tools gemacht werden ist, dass sie die Qualität einer minimalen PMD- oder CheckStyle-Konfiguration aufweisen. Dazu ist mit die Zeit von Entwicklern zu wertvoll.

Die meisten solcher Review-Tools arbeiten entweder auf Datei- oder Patchset-Ebene und vorgesehen sind nur Kommentare für Zeilen oder Dateien. Die besseren können Blöcke. Assoziationen, Packages, Klassen, eben die Ebene auf der man beim Codieren denkt, unterstützen sie alle nicht. Nun ist es aber für das Verstehen von Code unerlässlich über die Grenzen von Dateien hinweg zu denken und Strukturen zu erkennen und zu hinterfragen, die auf Zeilenebene nur schwer zu verstehen und zu kommentieren sind. Das ist mit einem solchen Tool aber extrem schwierig. Deshalb setze ich mich für Code-Reviews immer neben den Entwickler und lasse mir erklären, was er da warum gemacht hat und hinterfrage das dann. Ich habe festgestellt, dass die Leute beim Erklären oft Schwachstellen in ihrem eigenen Code entdecken, die ich mit Zeilenkommentaren nie hätte erläutern können. Einige davon hätte ich sogar selbst nie entdeckt. Bei solch einem Gespräch können immer zwei lernen.

Abgesehen davon verleiten die meisten solcher asynchronen Tools auch dazu, Reviews zu machen, wenn gerade Zeit ist. Das ist dann meist eine Weile nachdem der vielleicht schlechte Code im Repository gelandet ist. Dabei will man den dort gar nicht haben. Der Review muss meiner Meinung nach vor dem Commit stattfinden. Idealerweise als Gespräch zwischen zwei erwachsenen Leuten. Damit erspart man dem Entwickler auch die Zeit, sich wieder in den Code von vor ein paar Tagen reinzudenken, was eigentlich immer länger dauert, als ihn direkt vor dem Commit kurz durchzugehen.

Software-Architektur und Software-Qualität kann man nicht auf Ebene von Dateien oder Code-Zeilen offline diskutieren – genau das ist aber das Ziel eines Reviews: ein kritisches Gespräch über Architektur und Qualität von Quellcode. Man braucht dazu einen Gegenüber, einen Menschen der einen in seine Gedanken einweiht, dessen Spiegel man sein kann. Nur auf diese Weise besteht die Möglichkeit, Entwicklern Erfahrung und Wissen zu vermitteln, nur auf diese Weise kann man nachhaltig lernen.

Schreibe einen Kommentar

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