Nicht jeder Programmierer mag es gern, wenn sein (genialer) Code von anderen (weniger genialen) Programmierern begutachtet (durch den Kakao gezogen) wird. Das hat schon so was Persönliches an sich. Die emotionale Belastung dabei ist vielleicht mit der Bildbesprechung im Fotoclub vergleichbar. Da hagelt es dann Regeln, die man angeblich vergessen hat, während der Fotograf sich am Ende nur noch mit einem “Ich wollte das so!” aus der Affäre ziehen kann.
Nun ist Fotografie nur bedingt mit Programmierung zu vergleichen, obwohl in beidem künstlerische und handwerkliche Aspekte zusammen kommen. Bei dem Foto ist der letzte Richter der Betrachter, und jeder wird ein Foto auf seine ganz persönliche Weise anschauen und andere Erwartungen hinein setzen. Wie ist das bei Programmcode?
Der Access-Stammtisch Stuttgart hat heute etwas Besonderes vor. Mit freundlicher Genehmigung recycele ich mal ein paar Stellen der Einladung :-)
Jeder Teilnehmer soll mindestens eine Prozedur mitbringen. Diese wird vorgestellt und gemeinsam reviewed. Die Länge und der Inhalt der Prozedur sind nicht von Bedeutung. Die Teilnehmer des Reviews hinterfragen den Code. Im ersten Schritt geht es darum, den Code zu verstehen. Im zweiten Schritt machen die Teilnehmer Vorschläge, wie man den Code verändern könnte.
Gründe für solche Änderungen gibt es viele, u.a.
- Lesbarkeit
- Verständlichkeit
- Wartbarkeit
- Verbesserung der Lösung
- Performance
Auch die Vorschläge werden hinterfragt. Wichtig dabei ist, dass jeder Teilnehmer einen Vorschlag hinterfragen darf, nicht nur der Code-Sponsor.
Das Ziel ist, dass jeder Teilnehmer etwas lernt. Der Code-Sponsor hat zusätzlich noch den Nutzen, einen Haufen Vorschläge zu Verbesserung seiner Prozedur erhalten zu haben.
Der Access-Stammtisch Stuttgart hat zu einem Code-Review eingeladen. Wenn es noch eines Beweises bedürfte, dass Access-Entwickler professionell arbeiten, wäre er hiermit erbracht.
Neueste Kommentare