Diesmal gibt es wieder einen Beitrag zum Thema QM. Nachdem ich schon die Installation zweier CI Server vorgestellt habe und die damit einhergehenden statischen Codeanalysen bekannt sein sollten, gibt es nun ein weitere Thema, das sehr spannend ist. Das Oberthema sind die Code Reviews und im speziellen geht es um Peer Reviews.
Es gibt verschiedene Arten Code Reviews. Allen gemeinsam ist die Tatsache, dass der Code von mindestens einer zweiten Person betrachtet wird. Ziel dieses Verfahrens ist eine zweite Expertenmeinung einzuholen und mögliche Schwachstellen aufzudecken. Das hört sich relativ akademisch an, ist in der Praxis durchaus auch mal einfach nur ein kleiner Tipp, den ein Kollege gibt. Auch wird das Wissen um den Code an weitere Kollegen weitergegeben. In der Theorie kann dieser Kollege den Code dann auch mal warten und versteht wie ein bestimmtes Feature umgesetzt wurde. In der Praxis stimmt das nur grob, da ein Entwickler nicht den gesamten Code einer komplexen Anwendung im Detail kennt. Aber nach einem Review weiß er in etwa, wo er schauen muss.
Es zuerst ein formelles Code Review, dieses ist wohlgeplant und benötigt zwischen 3 und 6 Personen. Diese werden auf folgende Rollen verteilt. Moderator, Reader, Reviewer und Observer. Der Moderator moderiert die ganze Veranstaltung, was ja nahe liegend ist. Der Reader list einfach den Code und versteht was passiert, übt aber keine Kritik. Für die kritische Betrachtung ist der Reviewer zuständig. Der Observer verfügt über fachliches Wissen und kann somit bei fachlichen Fragen beantworten.
Wegen der Anzahl an Personen, die beteiligt sind, kann ein solches nur geplant durchgeführt werden. Daneben ist das Fachwissen auch nicht immer verfügbar.
Weiter geht es in Teil 2. Dort gibt es eine Beschreibung zu „Peer Reviews“ und „Email Pass Around“.