Sat Apr 22 19:28:36 +0200 2006 , Updated at
Code Reviews
Ich werde von nun ab hier in fortlaufenden Artikeln meine Eindrücke und Erfahrungen zu den derzeit viel diskutierten agilen Methoden niederschreiben. Input dafür bekomme ich durch das Studieren aktueller Literatur und dem Anwenden in der Praxis. Meine Favourits diesbezüglich sind die Buchtitel Practices of an Agile Developer und Ship IT!.
Der Fokus wird auf der Entwicklung von Wepapplikationen in kleinen Teams liegen bei denen die Teams bisher null bis wenig Erfahrung mit agilen Methoden haben doch aber im Kleinen damit beginnen wollen und einzelne Praktiken einführen möchten.
Hier im ersten Teil soll es um Code Reviews gehen:
Ein Code Review ist eine Art Korrekturlesen, eine Inspektion oder Durchsicht von Quelltexten durch einen anderen Entwickler. Ein Code Review soll der Verbesserung und Qualitätssicherung von Software dienen.
Wie kommt so ein Code Review zustande, wie kann das ablaufen?
Hans Dampf konnte nach 3 Stunden coden das Feature X im Modul Y für das er die Verantwortung übernommen hat umsetzten. Leider leider programmiert Hans alleine und nicht zu zweit im Pair Programming, so da� jetzt, bevor er seinen neuen Code eincheckt, er sich wie immer auf die Suche nach irgend einem andern Entwickler macht. Karl Knecht hat etwas Luft und so zeigt und erklärt Hans ihm emotionslos kurz und knapp was er da produziert hat. Ist Hans Lösung simpel, so lässt sich diese leicht erklären und Karl kann noch evtl. Verbesserungen vorschlagen oder auf Probleme hinweisen. Kann Hans nicht auf die Schnelle Karl erklären was da abläuft, dann ist nicht Karl zu doof dafür sondern der Code von Hans ist zu kompliziert und sollte überarbeitet werden. Vielleicht aber fallen Hans schon während er Karl den Code erklärt, Probleme und Fehler auf. Nach dem sich Hans und Karl sachlich 10-20min über den Code unterhalten haben war es das und somit ist Karl jetzt Pate für dieses Stück Quelltext. Hans bessert evtl. noch nach und checkt dann seinen Code ein, dabei vermerkt er in der Revision History das Karl den Code reviewt hat.
Code Reviews sollten mit wechselnden Reviewern für kleine Häppchen Code wie das mehrmals tägliche Zähneputzen etabliert werden. Kurz und knapp sollten sie sein. Sie sollten nicht als Last angesehen werden sondern eher als Möglichkeit seine Arbeit zu verbessern und von anderen Entwicklern zu lernen. So verteilt sich Wissen und Können. Dadurch das der Reviewer einen äu�eren Standpunkt hat, nicht so tief in der Implementierung steckt, fallen ihm Dinge auf die der Entwickler vor lauter Detailfragen nicht mehr wahr nimmt. Und auch alleine durch das Erklären, löst sich so manches Problem von selber auf. Man mu� halt darüber sprechen. Es sollte es egal sein, ob ein Senior als Reviewer für einen Junior dient oder umgekehrt. Jeder kann vom anderen lernen. Ein Reviewer übernimmt sozusagen die Patenschaft für dieses Codeteil.
Menschliche Aspekte kommen dabei auch ins Spiel: Scheut sich der Reviewer seinen Code zu zeigen, könnte dies daran liegen, das er ein schlechtes Gewissen hat seine dunklen Hacks preis zu geben. Andererseits sollte keiner für seinen Code gescholten werden.
Für besonderes wichtige Quelltexte sollten Reviews automatisiert ablaufen. Dies bedeutet, dass das Versions Contoll Managment automatisch nach Commits Change Notifications an die Verantwortlichen per eMail oder IRC versendet.
Hierbei gilt es den richtigen Drive zu finden. Es ist klar, daÃ? eine Ã?nderung im HTML Markup keinen Code Review braucht, wahrscheinlich auch nicht der eine gefixte Bug in Zeile 276. Wenn aber die Teilaufgaben etwas komplexer werden sind Reviews eine gute Sache.
