Die beste aber am meisten verhasste XP-Technik für guten Quellcode ist… Pair Programming. Ich habe es etliche Male versucht. Das Ergebnis war großartig und jeder Mythos von Managern, dass in der gleichen Zeit Programmierer einzeln doppelt so viel Code (mit nahezu der gleichen Qualität und Quantität) schreiben könnten, gehört definitiv der Vergangenheit an. ABER: Es ist wirklich hart 4-6 Stunden konzentriert gemeinsam am Code zu arbeiten. Programmierer sind ein eigener Schlag Menschen, die dieser Praxis meist nicht sehr zugeneigt sind. Fakt ist: Pair Programming ist nicht sehr verbreitet.
Gute Codequalität und mehr durch Code Reviews
Unbestritten sehen vier Augen mehr als zwei. Was also tun? Man führt Code Reviews ein. Also eine Überprüfung der Codequalität durch ein oder mehrerer Teammitglieder. Diese können dann Kommentare zum programmierten Code abgeben und Fehler identifizieren. Aber wer mag schon gerne kritisiert werden? Genau das passiert aber bei Code Reviews. Wenn man das ganze natürlich im Team nur als Kritik betrachtet, hat man meiner Meinung nach Code Reviews missverstanden. Es geht hierbei vielmehr um “Collective Code Ownership”, also dass sich alle Teammitglieder in nahezu allen Bereichen des Codes auskennen. Dies hilft dabei,dass die Qualität und der Stil des Quellcodes über die gesamte Codebase gleich ist. Ich persönlich fand es immer interessant zu sehen, wie meine Kollegen Probleme gelöst haben. Gerade für neue Mitarbeiter und Junior Programmierer sind Code Reviews ein tolles Instrument: Als Reviewer lernt man die neue Codebase besser kennen und für den Programmierer wird sichergestellt, dass die Qualität des neuen Codes stimmt.
Best Code Reviews Practicies
Die Best Practicies beziehen sich auf Erfahrung im Einsatz von Crucible – dem Online Code Review Tool von Atlassian. Es ist sehr simpel, Mitarbeiter einzuladen, sich Änderungen am Code anzuschauen und ggf. zu kommentieren. Es gibt einige Regeln zu beachten, damit Code Reviews nicht zum Bottleneck werden und zu Frustrationen führen:
- Nicht zu viele Kollegen zu einem Review einladen
Lädt man zu viele Mitarbeiter zu einem Review ein, fühlen sich die einzelnen Programmierer nicht für die Qualität des Reviews verantwortlich und übersehen Code-Smells und Fehler. Zwei Reviewer pro Änderung haben sich für Atlassian als sehr praktikabel erwiesen. - Reviews dürfen nicht zu groß sein
Wenn man 100 Änderungen in 80 Klassen reviewen soll, verliert man schnell den Überblick und findet wenig Fehler. Man sollte vielmehr kleine Änderungen für ein Review einstellen. - Reviews für Refactorings von Features trennen
Damit man den Grund von Änderungen im Review versteht, sollten Refactorings von Änderungen für neue Features oder Bugfixes getrennt werden. Man verliert sonst schnell die Übersicht. - Nicht alles unter Review stellen
Man sollte eine pragmatischen Ansatz für Code Reviews wählen, und nur relevante Änderungen unter Review stellen. Macht man simple Änderungen an Valueobjekten oder ändert den Namen einer Methode mit Änderungen in 300 Klassen, macht ein Review nicht unbedingt Sinn. - Reviews sofort durchführen
Um schnell Feedback zu erhalten, sollten Code Reviews nicht länger als 48 Stunden offen sein. Das heisst, dass der Code nach 48 Stunden vollständig reviewt sein sollte. Sind Änderungen notwendig, sollte diese sofort gemacht werden. Es sollten keine langen Diskussionen im Online Tool stattfinden. Lieber sollten der Autor und der Reviewer dann direkt miteinander sprechen, damit der Code so schnell wie möglich korrigiert wird. Erst dann ist der Task fertig (Definition of Done). - Nicht sarkastisch sein
Keiner sollte vor Code Reviews Angst haben. Sarkastische Kommentare sollten vermieden werden, sonst werden Code Reviews nicht im Team akzeptiert. Die Kommunikation in Code Reviews sollte der im Team entsprechen: Offen und wertschätzend!
Sven Peters 