Heute hatte ich einen sehr angenehmen Termin mit einem Kunden, dem ich geholfen habe, die Build-Umgebung für seine Software einzurichten, die er von einem anderen Dienstleister warten lässt, und die ich im Vorfeld auf Performance und Stabilität hin untersuchen sollte. Allein die Tatsache, dass nur der Dienstleister weiß, wie die IDE einzurichten ist, zeigt ein Problem der Maintenance: Wissen sitzt in Köpfen und geht mit dem Wechsel der Personen verloren.
Für die Analyse der Software musste ich mir selbst die Build-Umgebung aufsetzen. Dabei konnte ich einem 3-seitigen Dokument folgen, das beschreibt, wie die Sourcen aus dem Versionierungssystem zu holen sind, welche Module davon in den Eclipse-Workspace einzubinden sind, wie der Applicationserver aufzusetzen ist, wie mit Mocks die Nachbarsysteme zu ersetzen sind, und am Ende konnte ich die Anwendung doch nicht aus der IDE starten, da es sich um ein Applet handelt, das auf das umgebende HTML-Dokument zugreifen will, was im Appletviewer nicht geht. Um mit der Analyse selbst anfangen zu können, habe ich mit FindBugs und Sonar die Sourcen gescannt, um einen ersten Überblick zu bekommen. Die Funktionsweise der Applikation habe ich jedoch erst verstanden, nachdem ich einige Male mit dem Debugger an einer tief im Stacktrace vergrabenen Stelle gelandet bin. Ab da war einigermaßen klar, wie die Anwendung tickt, und ich konnte ohne Probleme die Analyse durchführen.
Da ich mein Ziel erreicht habe, könnte ich mich auf den Standpunkt stellen, dass ja eigentlich kein weiteres Schriftstück wirklich notwendig ist. Da mein Kunde aber gerne meine Unterstützung beim Einrichten der Umgebung angenommen hat, gehe ich davon aus, dass etwas mehr an Doku schon gut wäre. Zu viel soll es aber auch nicht sein. Jede Dokumentation muss mit Veränderung des Codes auf Korrektheit überprüft und gegebenenfalls angepasst werden. Andernfalls veraltet sie und ist im schlimmsten Falle irreführend, so dass es besser wäre gar keine Doku zu haben als eine falsche. Eine Gratwanderung: Wieviel ist richtig? Die Berater-Antwort: It depends. So viel wie nötig, um schnell einen (praktischen, nicht theoretischen) Einstieg in die Software zu bekommen, und so wenig wie möglich, um den Pflegeaufwand und damit die Kosten für eine Änderung gering zu halten. Was wir uns aber als Fazit merken können: Wichtig für jede „definition of done“ in der Maintenance ist die Aktualisierung der Dokumentation.
Was also hätte ich mir gewünscht, damit ich schneller ans Ziel komme? An Dokumentation genau zwei Dinge:
- Eine vollständige (!) Beschreibung zur Einrichtung der Build-Umgebung.
- Ein Architektur-Diagramm der Komponenten und wie diese zusammenarbeiten, sowie einen Einstiegspunkt, welche Klasse in welcher Komponente die wichtigste ist.
Mit diesem Dokumentations-Minimum ist es möglich, schnell einen Überblick über die Funktionsweise der Software zu bekommen, und zu verstehen, wo im Code welche Zuständigkeiten sind. Was mich aber wirklich aufgehalten hat, war nicht die mangelhafte Doku, sondern die umfangreiche Arbeit, die notwendig war, um die Build-Umgebung einzurichten. Da wäre viel zu verbessern. Macht man sich bewusst, dass jeder, der die Software für sich lauffähig bekommen möchte oder muss, diese Hürde zu überwinden hat, können sich ein paar Tage Aufwand recht schnell lohnen. Im schlimmsten Fall kann auch die fehlerhafte Einrichtung der IDE bei einem Entwickler dazu führen, dass ungeeignete Lösungen den Weg in den Code finden, und dann wird’s richtig teuer. Auch dieses Risiko sollte man mit einrechnen. Die Empfehlung, das Aufsetzen der Build-Umgebung zu erleichtern, habe ich meinem Kunden auch mitgegeben, da im konkreten Fall die Bearbeiter des Produkts häufig wechseln.
Die Analyse, die ich erstellt habe, war eine Sammlung von Maßnahmen, die umzusetzen vor allem zukünftige Änderungen an der Software erleichtert und damit die Qualität in puncto „Stabilität gegenüber Veränderungen“ erhöht. Der Kunde hatte sich eigentlich mehr konkrete Aufgaben gewünscht, die er seinem Dienstleister in Auftrag geben kann. Die Wirkung dessen wäre jedoch wahrscheinlich gewesen, dass genau diese Punkte abgearbeitet worden wären, ohne dass das Gesamtbild über den Zustand der Software bewusst geworden wäre. So ist es aber die Softwarequalität, die profitiert, wenn man die Änderungen im Gesamtkontext sieht und vornimmt. Und mein Kunde hat ein Dokument bekommen, in dem Punkte stehen, die abgearbeitet werden (können), und nach deren Abarbeitung das Dokument überflüssig wird. Gute Doku hat man, wenn die überflüssigen Teile entfernt worden sind.