Reviews – aber richtig! Software-Reviews: Systematisch Probleme und Risiken in IT-Systemen finden

Egal, wie erfolgreich oder bewährt Ihre IT-Systeme sind, aufgrund ihrer Größe und Komplexität enthalten sie mit großer Wahrscheinlichkeit einiges an Verbesserungspotenzial. Durch systematische Reviews können Sie (respektive Ihr Entwicklungsteam) dieses Potenzial identifizieren, und dadurch die perfekte Grundlage für systematische Verbesserung schaffen.

Im Artikel stelle ich Ihnen ganzheitliche Reviews vor. Insbesondere ergänze ich damit die klassischen Code-Reviews um eine ganze Reihe wichtiger Perspektiven.

Warum Software-Reviews?

Fangen wir mal mit der Grundsatzfrage an – warum sollen wir denn reviewen, es läuft doch alles …

In meinen über 30 Jahren Berufserfahrung in verschiedenen Branchen habe ich (außer hello-world) noch kein relevant großes IT-System ohne erhebliches Verbesserungspotenzial erlebt. Mal sieht es nicht so schick aus wie die Konkurrenz, mal beschwert sich das Management über schlechte „Time-to-Market“, mal jammern die Entwicklungsteams über veraltete Technologie, oder Test und QS ächzt unter der Last zu vieler Fehler.

Falls Sie an Ihrem System etwas verbessern möchten, empfehle ich Ihnen dringend eine systematische Bestandsaufnahme – ansonsten droht das Risiko von „Verschlimmbesserung“, oder gar die (leider weitverbreitete) Mikroskopfalle.

Vorsicht, Falle!

Wenn wir im Garten immer nur beim Apfelbaum nach Früchten schauen, werden wir leider die Kirschen übersehen, und die leckeren Brombeeren ebenfalls. Falls Sie also nur im Code suchen, werden Sie einige Kategorien von Problemen erst gar nicht finden. Ein paar Beispiele:

• Den Einsatz veralteter oder ungeeigneter Frameworks oder Bibliotheken, oder deren missbräuchliche Verwendung

• Die Nutzung ungeeigneter Hardware

• Das Auftreten von Deadlocks, Performance-Engpässen oder Speicherüberläufen

• Probleme mit fehlerhaften Eingabedaten

• Probleme aufgrund unzureichender Anforderungen

• Probleme aufgrund unzureichender Entwurfs-, Entwicklungs-, Test- oder Inbetriebnahme-Prozesse

Der Begriff „Mikroskopfalle“ bezieht sich auf das feingranulare (i. d. R. statische) Analysieren von Quellcode, also dem niedrigsten Abstraktionsniveau von IT-Systemen. Auf der Ebene von Code können wir die oben genannten Probleme schlicht nicht erkennen. Und selbst mit Clean-Code können wir Deadlocks und Memory-Leaks produzieren 

Rundum-Blick gefragt

Zum Glück können Sie die Mikroskopfalle sehr einfach vermeiden: Der Rundum-Blick, auch genannt „systematische Breitensuche“, besteht aus einer Sammlung verschiedener (möglicher!) Problembereiche, aus denen Sie die für Ihr System zutreffenden Themen auswählen können.

Nachfolgende Tabelle gibt einen Überblick über einige solcher Bereiche, und zählt typische Probleme darin auf:

Bevor Sie jetzt frustriert anmerken, dass es doch viel zu lange dauert, diese Punkte alle zu untersuchen: Das bekommen wir in den Griff, bitte haben Sie noch ein paar Zeilen Geduld mit mir.

Fangen wir doch mal mit der Frage an, wer solche Reviews überhaupt durchführen soll, wo doch ihr Entwicklungsteam ohnehin schon überlastet ist.

Wer soll reviewen?

Grundsätzlich bestehen die zwei Möglichkeiten 1. interne oder 2. externe Reviewer einzusetzen. In nachfolgender Abbildung habe ich jeweils Vor- und Nachteile beider Optionen aufgeführt – und gebe Ihnen den Rat, für einen systematischen Review beide Optionen anzuwenden.

Holen Sie sich 1 bis 2 Personen von außerhalb der betroffenen Stakeholder dazu, und lassen Sie 1 bis 2 Personen aus dem Entwicklungsteam mitarbeiten. Damit gewinnen Sie "best-of-both-worlds". Und zur Klarstellung: „Extern“ bedeutet lediglich „außerhalb der am System beteiligten Stakeholder“ – nicht unbedingt eine Fremdfirma.

Was genau ist Gegenstand?

Betreiben Sie explizites Scoping, d. h. klären Sie sehr genau, welche „Dinge“ zum Review gehören sollen, und welche nicht. Soll neben dem Quellcode beispielsweise auch die Hardware auf den Prüfstand gestellt werden? Die Schnittstellen zu den (externen) Sensoren, die eingesetzte Middleware, der Test- oder Entwicklungsprozess? Oder auch die Anforderungen?

Timeboxed und iterativ reviewen

Jetzt zu Ihrem Schrecken vom vorletzten Absatz – den (zu) vielen möglichen Problemzonen Ihres Systems. Führen Sie Ihren Review in kleinen und festen Zeitrahmen (engl. „timebox“) durch. Beginnen Sie im ersten Schritt beispielsweise mit einem zweistündigen Kick-off-Workshop, in dem eine kleine Gruppe in jeweils 15 bis 30 Minuten zu einigen der in Tabelle 1 genannten Bereichen ergebnisoffen folgende Fragen beantworten:

• Was für Probleme sehen wir in diesem Bereich?

• Welche Auswirkungen haben diese Probleme (z. B. auf Akzeptanz, User, Entwicklungsteam, Evolution des Systems?)

• Wie gravierend sind diese Probleme, auf einer hoch-mittel-niedrig Skala

• Kennen wir Lösungsansätze für diese Probleme?

Es geht in diesem Kick-off um eine initiale Sammlung von Problemen und Problembereichen, nicht um die endgültige Klärung. Die Personen in diesem Kick-off sollten möglichst ein breites Spektrum relevanter Stakeholder repräsentieren, mindestens (!) jedoch die Produktverantwortlichen („Product Owner“), Management, die Hard- und Softwareentwicklung, Test, Support und am besten auch User des Produktes.

Nach einem solchen kompakten Workshop haben Sie einen guten Überblick über Ihre spezifischen Problembereiche, und können daraus ableiten, an welchen Stellen das Review-Team weiter in die Tiefe bohren sollte.

Für diesen Artikel habe ich ein einige typische Problemkategorien mittlerer bis großer IT-Systeme ausgewählt, um Ihnen einige methodische Vorschläge für entsprechende Untersuchungen zu unterbreiten. Das (für Sie kostenfrei verfügbare!) E-Book „Software-Reviews“ ([Reviews-22]) geht deutlich darüber hinaus.

Code-Metriken

Ich gehe davon aus, dass Sie bereits Code-Reviews durchgeführt haben, oder solche (hoffentlich) zu Ihrer normalen Entwicklungspraxis gehören.

Sie können Ihren Quellcode mithilfe von Analysewerkzeugen metrisch untersuchen, und damit einige interessante Problemfelder lokalisieren:

• Stellen mit übermäßig hoher Code-Komplexität. Dazu zählt etwa stark verschachtelter Code (if-then-else Kaskaden, geschachtelte Switch-Statements oä). Als Kern-Metriken nutzen Sie hierzu Pfadkomplexität oder schlichtweg die Einrückungstiefe.

• Übermäßig große Code-Teile, etwa riesig große Klassen, Methoden oder Funktionen.

• Stellen mit vielen Abhängigkeiten. Das kann auf schlechte Kohäsion oder ungünstige Verteilung von Verantwortlichkeiten auf Code-Komponenten hindeuten.

• Abweichungen von Coding-Standards.

• Unzureichende Abdeckung durch automatisierte Unit-Tests.

Komponentenstruktur

Die Komponenten- oder Modulstruktur Ihres Systems zeigt den Aufbau Ihres Quellcodes aus einer Vogelperspektive: Statt einzelner Zeilen oder Klassen sehen Sie größere Einheiten und deren Verbindungen. Eine schöne Analogie aus dem realen Leben: Der Quellcode entspricht dem Grundriss Ihrer Wohnung, die Komponentenstruktur der Landkarte Ihres Wohnortes (bei größeren Systemen vielleicht sogar Ihres Landes).

In der Softwarearchitektur gibt es dafür den Fachbegriff „Bausteinsicht“ (siehe etwa [arc42-S05]). Darin sind insbesondere folgende Fragen relevant für die Identifikation möglicher Probleme:

• Welche und wie viele Abhängigkeiten/Beziehungen gibt es zwischen den Komponenten? Übermäßig viele Abhängigkeiten erschweren Verständnis und Wartbarkeit, das Ziel sollte angemessen lose Kopplung sein.

• Gibt es zwischen den Komponenten zirkuläre Abhängigkeiten? Das sollten Sie vermeiden, denn sie gelten als besonders kritisch bei Erweiterungen oder Änderungen.

• Gibt es besonders große Komponenten, oder solche, die besonders viele Aufgaben oder Verantwortung auf sich konzentrieren?

• Gibt es klare Verantwortlichkeiten von Personen oder Teams zu einzelnen Komponenten? Spiegelt sich die Struktur der Entwicklungsteams in den Komponenten wider?

Im Idealfall enthält Ihre technische Dokumentation ein aktuelles Bild der Bausteinsicht, an dem sich die Stakeholder bei Änderungen und Erweiterungen orientieren können.

Hotspots untersuchen

Eine spezielle Art der Code-Analyse möchte ich Ihnen ans Herz legen: Hotspot-Analyse: Ein Hotspot ist ein Baustein, der häufig geändert wird und gleichzeitig eine hohe Komplexität besitzt (sprich: komplexer, großer oder stark verschachtelter Quellcode).

Die Änderungshäufigkeit lässt sich aus der Versionsverwaltung (wie Git, Subversion oä) erfragen, die Komplexität von Code können Sie automatisiert über statische Analyse messen.

Adam Tornhill hat in seinem Buch [Tornhill] entsprechende Analysewerkzeuge als Open Source veröffentlicht. Folgende Abbildung zeigt eine solche Untersuchung (hier gezeigt anhand der Container-Plattform Docker, ca. 150.000 LoC in ca. 750 Dateien).

Hotspot-Analysen finden besonders riskante Teile eines Systems: Komplexe Stellen besitzen ein sehr hohes Fehler- und Änderungsrisiko, und sind tendenziell auch deutlich aufwendiger in der Wartung. Das kombiniert mit hoher Änderungsfrequenz garantiert nahezu, dass bei diesen Bausteinen schwerwiegende Probleme auftreten werden.

Anforderungen

• Leider findet in der Praxis die Entwicklung häufig nach dem Prinzip „garbage-in, garbage-out“ statt. Ich habe branchenübergreifend immer wieder die folgenden Probleme erlebt:

• Unklarheit: Anforderungen bleiben vage, unpräzise, grob. Das Resultat: Entwicklungsteams implementieren hoch konfigurierbare Systeme und verschieben damit die Entscheidungen über die endgültige Festlegung konkreter Anforderungen auf die Laufzeit.

• Stakeholder, User oder Produktverantwortliche ändern ständig ihre Meinung: Hohe Änderungsrate von Anforderungen, sodass Entwicklungsteams häufig Code ändern oder technische Entscheidungen revidieren müssen.

• Verschiedene Stakeholder fordern widersprüchliche Dinge.

• Anforderungen benötigen innerhalb der Organisation zu lange, bis sie beim Entwicklungsteam landen. Es gibt zu viele beteiligte Personen oder Organisationseinheiten, oder zu langwierige Abstimmungsprozesse.

Resultate effektiv kommunizieren

Fassen Sie die Ergebnisse eines umfassenden Reviews für alle Beteiligten sichtbar zusammen, im Idealfall laden Sie zu einer gemeinsamen Abschlusspräsentation ein.

Achten Sie dabei auf folgende Punkte:

• Zeigen Sie neben den gefundenen Problemen auch die positiven Aspekte Ihres Systems auf, die Sie unbedingt beibehalten sollten. Darüber freuen sich sowohl Entwicklungsteam als auch Management.

• Zu den gefundenen Problemen sollten Sie jeweils ein paar Vorschläge aufnehmen, wie diese Probleme adressiert oder behoben werden könnten.

• Erstellen Sie eine kompakte Zusammenfassung („Management Summary“) der Ergebnisse, mit den Top-3 der Probleme und den passenden Maßnahmen.

• Zeigen Sie kurz auf, wie die Ergebnisse zustande gekommen sind, und wie sie sich belegen lassen.

Nachfolgende finden Sie einen kompakten Gliederungsvorschlag für eine solche Abschlusspräsentation:

1. Eine kurze Management-Summary (maximal eine Seite, siehe Erläuterung oben).

2. Zusammenfassung organisatorischer Aspekte des Reviews:

• Was genau waren die Ziele und Scope des Reviews?

• Wie wurde vorgegangen? Wie viel Zeit wurde (circa) worin investiert?

• Mit wem hat wer worüber gesprochen?

• Welche Aktivitäten waren neben Gesprächen und Interviews Bestandteil des Reviews?

3. Welche Aspekte am System und dessen Entwicklung waren positiv zu bewerten (keep, don’t change)?

4. Eine Zusammenfassung der Probleme und Risiken

• In welchen Kategorien waren Probleme und Risiken zu finden?

• Welche Probleme gab es, beginnend mit den höchsten Prioritäten (also die schlimmsten, gravierendsten Probleme zuerst)?

• Wo drohen Risiken?

• Welche Auswirkungen sind zu erwarten oder sind bereits akut?

5. Zusammenfassung der vorgeschlagenen Maßnahmen

• In welchen strategischen, technischen oder organisatorischen Bereichen empfehlen Sie Maßnahmen?

• Welche unterschiedlichen Optionen gibt es?

Fazit

Mit Reviews können Sie Probleme im System und dessen Umfeld systematisch und zuverlässig identifizieren. Viele Untersuchungen lassen sich ohne den Einsatz teurer oder komplizierter Werkzeuge durchführen.

Suchen Sie in jedem Fall in die Breite, und hüten sich vor der Mikroskopfalle: Viele Probleme lauern außerhalb von Quellcode.

Für Ihre eigenen Reviews wünsche ich Ihnen viel Erfolg.

Quellen

[Reviews-22] Markus Harrer, Christine Koppelt, Gernot Starke, Benjamin Wolf: Software-Reviews. Risiken und Probleme in Software zielsicher identifizieren. E-Book, für Leser und Leserinnen dieses Artikels kostenfrei verfügbar unter https://www.innoq.com/de/books/software-reviews-identifying-risks-and-problems-in-software/ und Deutsch unter https://leanpub.com/software-reviews

[arc42-S05] arc42 – das freie Portal für Softwarearchitektur. Sektion 05 – Bausteinsicht, Erklärung mit Beispielen online unter https://docs.arc42.org/section-5/

[Tornhill] Adam Tornhill; Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs; Pragmatic Bookshelf 2015

 (mbf)

* Dr. Gernot Starke (INNOQ Fellow), Coach, Berater und Trainer für methodische Softwarearchitektur und Software-Engineering. (Mit-)Gründer von arc42.org, Gründer von aim42.org, (Mit-)Gründer des iSAQB e.V.

* Starke war an Architektur und Implementierung mittlerer und großer Systeme für Organisationen in verschiedenen Domänen beteiligt, hauptsächlich im Finanzwesen, in der Automobilindustrie, in der Logistik und in der Telekommunikation. Seit einigen Jahren liegt sein Schwerpunkt auf Verbesserung von Legacy-Systemen sowie Software-Reviews.

* Er hat zahlreiche Bücher über Softwarearchitektur und verwandte Themen geschrieben, veröffentlicht regelmäßig Fachartikel und gibt seine Erfahrungen auf Konferenzen und in Trainings weiter. Starke lebt in Köln.

(ID:48985706)