Der Fahnder – Teil 3

Knigge für Softwarearchitekten: Fahndungsergebnisse

Gernot Starke, Peter Hruschka

©Shutterstock.com/Dabarti CGI

In den letzten beiden Folgen haben wir den Fahnder vorgestellt, der nach Architektur- oder Codesünden und ähnlichen Missetaten in bestehenden Systemen sucht (siehe Teil 1 „Der Fahnder“ und Teil 2 „Spuren verfolgen“). Die Fahnder suchten in den letzten Folgen nach technischen Schulden, Risiken und anderen Sünden, und zwar durch Opfer- und Zeugenvernehmung sowie Bestandsaufnahmen im Code und der Dokumentation. Sie überprüften ihre Funde durch Kreuzverhöre und schlugen für die wirklichen Sünden im Code Maßnahmen vor. Im dritten Teil diskutieren wir, wie Fahnder mit den Ergebnissen ihrer Arbeit umgehen sollten.

Was geschieht mit den Fahndungsergebnissen?

Sie haben als Softwarefahnder unter Umständen eine Menge an Indizien aufgespürt, Aussagen erhalten und Beweise aufgesammelt. Im Fernsehkrimi bringen Sie alles zurück ins Kommissariat zu der großen Wandtafel. Dort heften Sie diese Fakten einfach an und bringen sie grafisch mit Strichen in Verbindung (in der Hoffnung, dass die SOKO dann anhand dieses Überblicks weitere Schritte und Maßnahmen beschließen kann, die zur Aufklärung des Verbrechens führen).
Während Sie als Fahnder noch nach Ursachen und Zusammenhängen suchen, können Sie für erkannte Softwaresünden ebenso ein semantisches Netz bzw. eine Concept-Map aufbauen, wofür es einige (teils kostenfreie) Tools gibt. Ordnen Sie identifizierte Risikobereiche, anfällige Codeteile, Bausteine mit zu harten Abhängigkeiten im Überblick an und diskutieren Sie daran die dringendsten Maßnahmen.

Langfristig besser: Der Standardarchitekturschrank – lose gefüllt

Nach erfolgreicher Klärung eines Falls bleibt auch den Fahndern im Krimi nichts erspart: Sie müssen einen sauberen Abschlussbericht vorlegen, damit sie selbst, aber auch Kollegen aus anderen Kommissariaten geordnet darauf zugreifen können. Das macht meistens weniger Spaß als die eigentliche Fahndungsarbeit, gehört bei nachhaltig angelegter Entwicklungsarbeit aber dazu – auch für Softwarefahnder. Im Grunde ist das einfach und schmerzfrei:
Stellen Sie sich einmal kurz vor, Sie müssen nicht auf der grünen Wiese mit der Dokumentation Ihrer Architektur beginnen, sondern Sie hätten eine halbwegs ordentliche Dokumentation des zu modifizierenden Systems. Dann könnten Sie alle Erkenntnisse über Risiken und Schwachstellen natürlich als Annotationen an die richtige Stelle dieser Doku anhängen. In der Projektrealität ist eine solche Doku über Altsysteme jedoch (noch) relativ selten. Trotzdem hilft uns diese Vorstellung einer idealen Doku weiter.
Wir haben Ihnen in der ersten und zweiten Staffel des „Knigge“ schon mehrfach vorgeschlagen, Ihre Architekturdoku projektübergreifend zu standardisieren, z. B. in unserem Knigge-Buch im Kapitel über die „Kommunikatorin“.
Für die Evolution von Softwaresystemen schlagen wir vor, dass Sie von dieser Dokustruktur zunächst nur das Gliederungsschema übernehmen. Sozusagen einen leeren Schrank mit vielen (noch freien) Fächern.

Die Deltadokumentation

Der (leere) Schrank hat bereits die Fächer für die Informationen vorbereitet, die Sie über Ihre Architektur wissen sollten. Es gibt ein Fach für Qualitätsziele, ein Fach für die Softwarebausteine und deren Zusammenspiel, ein Fach für die Infrastruktur, auf der die Bausteine laufen, ein Fach für Laufzeitszenarien usw.
Greifen wir beispielhaft eine Erkenntnis des Fahnders heraus. Er hat festgestellt, dass die Performanz eines Geschäftsprozesses viel zu wünschen übrig lässt. Also skizziert er ein Laufzeitszenario, das das Zusammenspiel der beteiligten Bausteine zeigt, und markiert rot die Bausteine, die für die schlechte Performanz hauptverantwortlich sind. Genau die – und nicht alle anderen – kann man jetzt genauer unter die Lupe nehmen und Tuningmaßnahmen durchführen. Das Ergebnis landet im dafür vorgesehenen Fach im Schrank. Ein Fach ist nun bereits teilweise gefüllt.
Vielleicht haben Ihre Tatorterkenntnisse ergeben, dass das System unter dem „Copy-Paste-Loose“-Effekt leidet. Sie haben – historisch bedingt – fünf Subsysteme, die ähnliche Funktionalität erfüllen, aber nicht mit einer geeigneten Abstraktion programmiert sind, sondern einfach durch Kopieren und Ändern – was die Wartbarkeit wesentlich aufwändiger macht. Nehmen Sie sich diesen Ausschnitt des Designs zur Brust und führen Sie geeignetes Refactoring durch. Die resultierenden, geänderten Bausteine stehen ab sofort im richtigen Fach des Schranks bereit.
Wenn der Fahnder festgestellt hat, dass eine Schnittstelle den neuen Anforderungen nicht mehr gewachsen ist (zu wenig Flexibilität, fehlende Ausnahmebehandlung, ein zu komplexes Protokoll, …), dann konzentrieren Sie sich bei der Nachdokumentation nur auf die Bausteine, die an der Schnittstelle beteiligt sind.
Deltadokumentation heißt, punktuell neu zu designen oder anzupassen, statt systematisch die wesentlichen Strukturen Ihrer Software aufzuzeigen, aber diese punktuellen Erkenntnisse strukturiert im richtigen Schrankfach aufzubewahren. Sollte an diesem Teil der Software wieder etwas unangenehm auffallen, dann sparen Sie zukünftig das Sourcecode-Reengineering und können sich auf korrekte (Teil-)Dokumentation verlassen.

Deltadokumentation braucht etwas Geduld. Wenn Sie zehn Prozent eines Systems anpacken, dann müssen Sie ohnehin zirka zwanzig Prozent davon verstehen (das Umfeld Ihrer Problemstellen). Wenigstens die zwanzig Prozent können Sie anständig dokumentieren. Die anderen achtzig Prozent der Architektur sind dann nicht besser und nicht schlechter als vorher. Aber nach vier oder fünf Iterationen…

Fazit

Sparen Sie beim Festhalten der Ergebnisse, seien Sie ruhig „strukturiert faul“. Eine angemessene Dokumentation der Architektur ist nur ein Nebenziel bei der Evolution von Systemen. Ein „Standard-Architektur-Doku-Schrank“ hilft, Fakten genau dort vorzufinden, wo man sie vermutet. Akzeptieren Sie, dass große Teile des Schranks lange Zeit (oder immer) leer bleiben. Je länger Sie an dem System weiterarbeiten (ändern, ergänzen, erneuern, …), desto hilfreicher (und wertvoller) wird Ihre Dokumentation werden.

Videotipp: Knigge für Softwarearchitekten gibt es auch als Video auf JAX TV. Wir sehen uns!

Aufmacherbild: Large rows of grey file cabinets. Wall of cabinets with one drawer open. von Shutterstock / Urheberrecht: Dabarti CGI

Geschrieben von
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: