Bei FIS gehört das Review selbstverständlich zum Entwicklungsprozess dazu. Im Bereich Kundenentwicklung, also Anpassung unserer Lösungen an die Anforderungen und Wünsche unserer Kunden, wurde der Reviewprozess noch vereinfacht, indem eine Protokollvorlage erstellt wurde. Die Ausgestaltung des Reviews obliegt selbstverständlich den einzelnen Entwicklerteams, die Rahmenbedingungen werden aber von der Vorlage bereits abgesteckt.
Im Team Kundenentwicklung der Abteilung FIS/EIMSolutions ist der Reviewprozess als Speed Review ausgelegt. Wie beim Speed-Dating bekommt jeder Entwickler einen Partner zugeteilt. Nach einer definierten Zeitspanne, hier üblicherweise 2 Wochen, wird der Partner gewechselt. Die Reviews werden innerhalb dieses Zeitraums mit dem jeweiligen Partner durchgeführt.
Das Review Board ist auf einem Whiteboard bildhaft dargestellt. Jeder Entwickler ist dort in Form eines mit Hilfe von SAP Scenes erstellten und ggf. mittels Post-It-Notizzetteln kreativ angepassten Avatars dargestellt. Damit ist für jeden Mitarbeiter jederzeit einsehbar wie der aktuelle Stand ist und bis wann er mit seinem Partner die Reviews durchgeführt haben muss. Grüne Magneten bedeuten ein bereits durchgeführtes Review, bei roten Magneten muss es noch durchgeführt werden.
Das Review selbst wird vor der Freigabe des Transportauftrags durchgeführt, so dass etwaige Nachbesserungen noch schnell und einfach durchgeführt werden können. Im Umfang eines jeden Reviews werden unter anderem die Dokumentation der Entwicklung im FIS/oss inkl. Transportaufträge und aller Änderungsstellen geprüft. Code Kommentare müssen in ausreichender Menge vorhanden sein und sollen die Motivation der Änderung erklären sowie die Änderungsstellen abgrenzen. Eine statische Codeprüfung wird mit Hilfe des Code Inspectors oder des ABAP Test Cockpits (ATC) durchgeführt und darf keine Auffälligkeiten beinhalten. Der Code selbst wird im Sinne eines Walkthroughs der IEEE-Norm 1028 inspiziert. Dabei erklärt der Entwickler der Programmierung seinem Review Partner wie der Code aufgebaut ist und was der Gedankengang dahinter ist. Der Reviewer achtet auf Einhaltung der Namenskonventionen sowie logische Lücken und Optimierungsmöglichkeiten. Er findet so erste Verbesserungen noch bevor etwas im Test negativ auffallen könnte und prüft die Entwicklung auch auf eine vernünftige Modularisierung. Den Funktionstest kann das Review natürlich nicht ersetzen.
Seit der Einführung des Speed Reviews im Jahr 2016 wurden bereits eine Vielzahl an Reviews durchgeführt. Der Lerneffekt ist bereits deutlich spürbar und auch die Kommunikation im Team, die vorher bereits sehr gut war, wurde noch einmal gefördert. Was mich aber besonders stolz macht, ist die Tatsache, dass die Entwicklungen insgesamt sehr viel schöner werden. Man könnte meinen, dass es ausreicht, wenn eine Entwicklung funktioniert.
Wie Donald Knuth, einer der Pioniere der Softwareentwicklung einmal gesagt hat, kann man Programmieren durchaus als Kunst ansehen, weil es „gesammeltes Wissen auf die Welt anwendet, weil es Fähigkeit und Einfallsreichtum benötigt, und insbesondere weil es Objekte der Schönheit produziert.“ Wenn Programmieren also Kunst ist, folgt es, dass ein Softwareentwickler auch Künstler ist.
Künstler sind nicht mit der erstbesten Lösung zufrieden – die Lösung soll nicht nur funktionieren, sondern auch eine Schönheit aufweisen!
