T3 23.00 – Code-review

Bitte entschuldigt den verspäteten Eintrag. Codereview hat sehr lange gedauert und nach kurzem Schlaf kamen dann auch schon die Zusammenfassung mit allen Studenten und eine lange Heimreise.

Da wir jetzt wissen, dass dies der letzte Tag war, an dem wir produktiv arbeiten konnten, interessiert uns das heutige Ergebnis natürlich ganz besonders und wir verziehen uns in die örtliche Cocktailbar, um bei einschlägigen Wiesn-Hits den vorhandenen Code mal genauer zu untersuchen.

Wir befinden uns nachwievor im ersten Sprint und sind damit leider nicht ganz da wo wir gerne sein würden. Dennoch ist eine ganze Menge Code entstanden, der – laut PMs - theoretisch schon fast funktionieren sollte. Wir schauen rein…

Nun. Was wir da im Code gesehen haben war sehr zweigeteilt. Wir haben an ziemlich vielen Stellen beeindruckenden Code gesehen. Aus dem Grund beeindrucken, weil wir von den verantwortlichen Studenten im Vorfeld die Info bekommen haben, dass sie garnicht so genau wissen, wie das funktioniert. Stored Procedures sind da ein gutes Beispiel. Auch die Web Services wurden einwandfrei implementiert, obwohl es da Anfangs noch Probleme mit den Sessions gab. Außerdem war an vielen Stellen die Dokumentation wirklich hervorragend ausführlich.

Leider gab‘s auch Stellen im Code, an denen es sicher großes Verbesserungspotential hat. Gerade bei der Verwendung von Referenzen auf andere Projekte wurde nicht gespart, obwohl es zentrale Schnittstellen gibt, um die Komponenten zu entkoppeln. Es gab sogar einen direkten Verweis des Frontends auf das Backend, obwohl die Kommunikation über den Webservice gehen sollte. Das hat sich aber dann als Überbleibsel einer früheren Entwicklungsphase herausgestellt, wo es noch keinen Webservice gab.

Zusammengefasst kann man sagen: Es gab gute Stellen, es gab schlechte Stellen. Aber abgesehen von den Patzern mit den Referenzen – die vermutlich durch das anfängliche Unverständnis für die Architektur zurückzuführen sind – war der Code in einem ordentlichen Zustand und kompilierte. Ich habe es sogar geschafft die Webservices auf einen Demorechner zu installieren. Da Datenbank und Manager bereits größtenteils funktionierten, hat da schon einiges funktioniert. Die Simulator-Gruppe hatte den härtesten Job, weil deren Teil bereits im ersten Sprint fertig sein musste, es aber dann keine größeren Änderungen mehr zu erwarten gab. Leider konnte nie eine Simulation gestartet werden um zu sehen, ob alles läuft, aber der Code sah schon vielversprechend aus. Übel hat es das Frontend-Team getroffen. Diese Gruppe musste hauptsächlich auf Schnittstellen-Änderungen des darunter liegenden Webservice reagieren, weshalb die Demonstrationsoberfläche nicht besonders viel Zuneigung bekam und noch die eine oder andere NotImplementedExpcetion wirft.

Fazit: Mal wieder hat sich gezeigt, dass das Grundverständnis für das Gesamtprojekt essenziell für ein zuverlässiges Arbeitsergebnis ist. Die Teams müssen Zusammenhänge und Ursachen für Designentscheidungen verstehen, um zielgerichtet zu arbeiten und den Aufwand ordentlich abzuschätzen.