Knigge für Softwarearchitekten

Die Kommunikatorin

Peter Hruschka und Gernot Starke

In den letzten Folgen hatten wir begonnen, Sie mit dem Lehrplan des iSAQB e.V. [1] bekannt zu machen. Eine wichtige Aufgabe auf Ihrem Weg zum produktiven Architekt ist ein solides Verständnis, wie Sie Architekturen und Architekturentscheidungen sinnvoll „weitergeben“ – sowohl mündlich wie schriftlich. Der iSAQB-e.V.-Lehrplan widmet dieser Aufgabe ein eigenes Kapitel namens „Beschreibung und Kommunikation“


src=“http://entwickler.com/develop/zonen/magazine/onlineartikel/pspic/picture_file/30/hruschka_k5003c01286edb.jpg?1342423058″ hspace=“10″ vspace=“5″ alt=““>

First talk, then write

Die Überschrift, erst reden dann schreiben, ist ein Erfolgsmuster, zitiert aus [2]. Als geschickte Architektin treffen Sie Ihre Entscheidungen nicht alleine im Elfenbeinturm. Sie stellen sich mit Ihren sachkundigen Entwicklern ans White Board, Stift in einer Hand, Schwamm in der anderen, und diskutieren Alternativen durch. Wenn Sie dann zu einem zufriedenstellenden Ergebnis gekommen sind, ist es an der Zeit, dieses schriftlich festzuhalten. In erster Näherung reicht oft auch abfotografieren und an die richtige Stelle in Ihr Dokument hängen.

Dokumentieren ist schriftliches Kommunizieren

Nur Tafel oder Pinnwand reichen für viele Projekte nicht aus. Sie brauchen eine Dokumentation Ihrer Softwarearchitektur auch für Kollegen, die bei der Diskussion am White Board nicht dabei waren und vor allem auch für diejenigen, die sich Jahre nach Ihnen zwecks Pflege und Weiterentwicklung mit der Software auseinandersetzen müssen. Dokumentation sollte für Leser optimiert sein, nicht für den Ersteller! Denken Sie immer daran, wie vielen Personen Sie Reengineering von Quellcode ersparen, wenn Sie gerade wieder über den Aufwand der Dokumentation fluchen.

Schmerzfreie Dokumentation

Ein paar Stilregeln helfen, die Dokumentation schmerzfrei(er) zu überstehen:

  • Wir fordern Sie explizit dazu auf, strukturiert faul zu sein. Schreiben Sie nicht den ganzen Quellcode in UML ab, sondern zeichnen und erläutern Sie die Struktur im Großen. Lieber weniger, dafür aber akkurat und korrekt. Sie wissen schon: Wenn Sie zweimal in der Dokumentation etwas finden, was nicht mit dem Code übereinstimmt, dann schlagen Sie diese kein drittes Mal auf.
  • Auf jeden Fall: redundanzfrei! DRY – Don’t repeat yourself – heißt das Merkwort. Es ist selten schmerzfrei, wenn Sie ein und dieselbe Schnittstelle an drei Stellen beschrieben haben. Wir garantieren Ihnen, dass Sie bei einer Änderung nicht mehr alle Stellen finden und ausbessern.
  • Lieber standardisierte (UML-)Diagramme als persönlich erfundene Grafiksymbole. Die meisten Tools erlauben Ihnen heute die Nutzung von Farbe, Schatten, Hervorhebungen, Annotationen. Damit werden Ihre Diagramme auch managementtauglich. Zu den heute so häufig anzutreffenden Kraftpunkt-Architekturen (engl: Powerpoint Architecture) hat der Untersuchungsausschuss der NASA nach dem Shuttleunglück Folgendes festgehalten [3]: „The Board views the endemic use of PowerPoint briefing slides instead of technical papers as an illustration of the problematic methods of technical communication at NASA.“ Leider sind selbst erfundene Symbole ohne erläuternde Legende nicht nur ein Problem der Praxis, sondern auch in vielen Büchern über Architektur als abschreckende Beispiele enthalten. Obwohl sie lange nach Einführung des UML-Standards verfasst wurden.
  • Und die beste Stilregel zum Schluss: Ihre Architekturdokumentation muss nicht vor der Implementierung fertig sein. Aber auch nicht erst nach Abnahme des Systems. Idealerweise erstellen Sie Dokumentation projektbegleitend. Das sichert Gültigkeit und Korrektheit erstellter Dokumente und erspart zusätzlichen Aufwand.
Geschrieben von
Peter Hruschka und Gernot Starke
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.