deesaster.org

In jedem größeren Software-Projekt besitzt die Software eine bestimmte Architektur. In der Regel sollte diese strukturiert und gut dokumentiert sein. Da Dokumentation aber nicht gerade zu der Lieblingsbeschäftigung von Entwicklern zählt, krankt es des Öfteren daran. Das Buch „Software-Architekturen dokumentieren und kommunizieren“ von Stefan Zörner soll zeigen, wie man die Software-Architektur festhalten kann.

Inhalt

Inhaltlich orientiert sich das Buch „Software-Architekturen dokumentieren und kommunizieren“ teilweise an der Dokumentationsvorlage arc42. Diese Vorlage, entwickelt von Gernot Starke (der auch das Geleitwort zum Buch verfasst hat) und Peter Hruschka, ist unter einer Creative-Commons-Lizenz frei verfügbar und für jeden nutzbar.

Stefan Zörner beschreibt in seinem Buch aber viel mehr als die Dokumentation mit arc42, dies nimmt im Vergleich sogar nur einen kleinen Teil ein. Wichtig sind ihm vor allem Fragen wie „Was dokumentiere ich? Für wen dokumentiere ich? Und wie ich finde das Dokumentierte wieder?“ Auch wenn diese Fragen nicht generell und erst recht nicht leicht zu beantworten sind, gibt sich der Autor sichtlich Mühe, dem Leser Denkanstöße in diese Richtung zu geben.

Bei der Dokumentation geht er dann auch verstärkt auf wichtige, zu beschreibende Aspekte einer Software ein. Darunter z. B. die Randbedingungen, Qualitätsmerkmale („non-functional requirements“) oder Architekturentscheidungen. All dies sollte festgehalten werden, damit man auch später noch klar nachvollziehen kann, wieso die Software so strukturiert ist, wie sie vorliegt.

Zielgruppe

Auch wenn man meinen könnte, dass das Buch nur eine kleine Zielgruppe hat, so sollte doch eigentlich jeder Software-Entwickler wissen, wie er die Struktur seiner Software dokumentieren und anderen vermitteln kann. Sicherlich ist es in einem Ein-Mann-Projekt übertrieben, mit arc42 an die Dokumentation zu gehen, aber die meisten Programmierer können bestätigen, dass sie ohne Dokumentation (und sei es nur in Form von Kommentaren) den eigenen Quellcode nach einem halben Jahr nicht mehr komplett verstehen. Demnach richtet sich das Buch an eine große Gruppe, sowohl im Business- als auch im Privat-Bereich.

Für seine Vorträge und das Buch hat er sogar eine eigene Schach-Engine DokChess geschrieben, die unter Open-Source-Lizenz verfügbar ist. Dieser Software widmet er anschaulich im Buch auf 34 Seiten eine komplette Beispieldokumentation, sodass jeder Leser ein echtes und anschauliches Beispiel für gute Dokumentation vorliegen hat.

Durch Übungsaufgaben versucht Stefan Zörner auch gleich zum Mitmachen anzuregen. Dies ist sehr fordernd, weil man die Architektur des real existierenden Squeezebox Medienservers dokumentieren soll. Hier sollte man also schon etwas Zeit mitbringen. Auch wenn die ersten Übungsaufgaben noch recht einfach zu handhaben sind, wird es zum Ende immer anspruchsvoller. Gut ist, dass man dem Autor seine Lösungen per E-Mail zuschicken kann und er dazu Rückmeldung gibt und seine Musterlösung zuschickt.

Fazit

Das Wichtigste, was Stefan Zörner wohl als geeigneten Autor für so ein Thema ausmacht, ist sein Erfahrungsschatz. Als ehemaliger Trainer und Berater bei oose und nun bei embarc hat er regen Kundenkontakt. Privat arbeitet er beim Apache-Projekt mit und hat so auch einen Einblick in andere Organisationsformen.

Das Buch liest sich daher aufgrund kleiner Anekdoten und Zitate sehr locker und flüssig. Darüber hinaus bauen die Kapitel nicht aufeinander auf, sondern können auch je nach aktuellem Wunsch gezielt bei einem Problem gelesen werden. Sinnvoll ist es aber, wenn man jedes Kapitel zumindest überfliegt.

Sehr gut haben mir vor allem die Kapitel 8 „Lightfäden für das Vorgehen zur Dokumentation“ und Kapitel 10 „Stolpersteine der Architekturdokumentation“ gefallen. In Kapitel 8 geht es darum, wie man sinnvoll dokumentiert. Vor allem die Aussage, dass ein Bild (UML-Diagramm) manchmal nicht mehr als tausend Worte sagt, ist bei mir hängengeblieben. In Kapitel 10 geht es um fiese Dokumentationsfallen, etwas, was Stefan Zörner schon auf der OOP 2012 vorgetragen hat, wo ich ihn auch kennenlernte.

PS: Ich weiß nicht, wieso ich die Rezension nicht eher hier veröffentlicht habe. Das Buch hatte ich bereits im März 2013 fertig gelesen.