Hier geht's zur Aufzeichnung von Stefan Toths Vortrag "Leichtgewichtige Software-Reviews 2.0" auf der JavaLand 2024.
Warum Reviews sinnvoll sind
Als Softwareentwickler gießen wir Domänenkonzepte in Code. Dabei überlegen wir uns eine geeignete Strukturierung, diskutieren die Verwendung bestimmter Sprachfeatures, binden Standard-Libraries ein, nutzen Frameworks, vertrauen auf Basistechnologien und binden bestehende Lösungen an. Durch all diese Aktivitäten formen wir, teilweise implizit, ein Softwaresystem, das gut oder weniger gut zum eigenen Kontext passt. Willst Du ein besonders performantes, sicheres oder wartbares System bauen, solltest du die konzeptionellen Ideen, die hinter den eingesetzten Technologien stehen reflektieren und deren Zusammenspiel verstehen. Diese Betrachtungsebene der Entwicklung bezeichnen wir als "Software-Architektur", die Reflektion dazu als "Reviews".
Warum sollten wir aber reviewen was wir gemacht haben, anstatt gleich die "richtige" Lösung zu bauen? Auch wenn wir uns in der Softwareentwicklung oft Rationalität und fundiertes “Ingenieurstum" wünschen: In der Realität haben wir es mit parallelen Überlegungen von potenziell vielen Entwickler*innen zu tun, die oft mit unklaren oder widersprüchlichen Einflüssen umgehen müssen und ein System entwickeln, das zu komplex ist, um alle Zusammenhänge und Seiteneffekte vorauszusehen. In ihrem berühmten Paper zu "Chaos Engineering" schreiben Casey Rosenthal et. al. [Basiri+2016]:
“Wir sehen sehr schnell, dass ein verteiltes System sinnvoller Größe zu komplex für einen Menschen wird. Es gibt zu viele Systemteile, die sich zu schnell ändern und weiterentwickeln, auf ungeplante und unkoordinierte Weise miteinander interagieren, als dass ein Mensch diese Muster in seinem Kopf behalten könnte.“ [...] „Das Gleiche gilt für andere komplexe Systeme, einschließlich Monolithen (normalerweise mit vielen, oft unbekannten, weiterführenden Abhängigkeiten), die so groß werden, dass kein einzelner Architekt die Auswirkungen einer neuen Funktion auf die gesamte Anwendung verstehen kann.”
Wir entwickeln Software-Systeme erfahrungsbasiert, teilweise intuitiv, anekdotengetrieben, emotional und konsensgesteuert – mit "Bauchgefühl" eben. Wir brauchen uns also gar nicht der Illusion hingeben, Systeme ließen sich "von vornherein" gut designen, ohne Fehler zu machen oder bei der Entwicklung in Sackgassen zu laufen. Alles, was wir tun können, ist häufig und gemeinsam zu reflektieren, um Fehlentwicklungen und sich offenbarende Probleme stetig zu identifizieren und zu beseitigen.
Die Mittel für Reviews sind vielfältig. Mit LASR, dem "Lightweight Approach for Software Reviews" [Toth+2024] gibt es einen zielorientierten Ansatz, der mit wenigen Beteiligten und überschaubarem Zeitaufwand Risiken aufdeckt. Lasst uns etwas genauer hinsehen…
LASR – Ein leichtgewichtiger Ansatz
Der "Lightweight Approach for Software Reviews", kurz LASR, reflektiert Software vor dem Hintergrund zentraler Zielsetzungen. Es ist leicht, Probleme in Softwaresystemen zu finden. Die Frage ist, ob diese Probleme schwerwiegende Konsequenzen haben oder einfach nur "unschön" sind. LASR filtert deshalb zunächst die Top-Ziele im qualitativen Bereich heraus (denke Wartbarkeit, Zuverlässigkeit oder Benutzbarkeit) und versucht dann, Probleme der Lösung mit diesen Zielen in Verbindung zu bringen. Die Probleme werden direkt gesucht, allerdings mit etwas methodischer Unterstützung.
Abbildung 1 zeigt den Ablauf eines LASR-Workshops im Detail. Jeder der vier abgebildeten Schritte ist durch Vorlagen und anderes Material unterstützt, um eine direkte Anwendung zu vereinfachen (Download unter https://www.embarc.de/themen/lasr-reviews/). LASR findet als Workshop von 2 bis 3 Stunden statt – idealerweise mit zwei bis vier Beteiligten aus dem Entwicklungsteam. Alleine kann man LASR auch durchführen, größere Runden (5+ Beteiligte) machen die Methode eher zäh.
Verstehe, was Dich speziell macht
Hätte jede Softwarelösung die gleichen Ziele und die gleichen Rahmenbedingungen, wären wir als Softwareentwickler:innen relativ schnell arbeitslos. Wir könnten das *eine gute System* bauen und es auf funktionaler Seite je nach Bedarf variieren. Die Erfolgskriterien und das Umfeld unserer Systeme sind jedoch immer unterschiedlich. Manchmal brauchen wir wasserdichte Sicherheits-Features, manchmal herausragende Performance oder sehr geringen Ressourcen- und Stromverbrauch. Manchmal macht die Bedienbarkeit den Unterschied, manchmal gibt es nicht mal ein UI.
In der oberen Aktivität arbeitest Du zunächst ein schlankes Mission Statement (1) für dein Softwaresystem heraus. Auf Webseiten von Softwareprodukten finden sich häufig "Claims", die das Produkt beschreiben und von ähnlichen Produkten abgrenzen. Die Chat-Lösung Threema verspricht auf ihre Website beispielsweise "Sichere Kommunikation für Privatanwender", "DSGVO Konformität" oder "Effiziente Administration für Business-Kunden". Diese Claims für das eigene System zu brainstormen hilft die Abgrenzung besser zu verstehen und öffnet die Köpfe für die Identifikation der wichtigsten Zielsetzungen.
Der Bewertungsmaßstab (2) entsteht bei LASR durch die Auswahl von drei bis fünf zentralen Qualitätsmerkmalen. Hierfür bietet LASR 14 Standardziele von Software als Spielkarten (angelehnt an die ISO-Norm für Softwarequalität, aber erweitert). In der sogenannten “Top-5 Challenger”-Methode werden die wichtigsten Qualitätsziele identifiziert und priorisiert. Dieser Schritt ist mit Beteiligung des Product Owners besonders effektiv und dauert nur etwa 20-30 Minuten.
Durchleuchte die Architektur
Nun folgt die eigentliche Analyse der Softwarelösung – der Kern jeder Review- und Bewertungsmethode und typischer Weise recht aufwendig. Einerseits möchte man Risiken und Probleme identifizieren, andererseits müssen die gefundenen Risiken mit den Zielen in Verbindung gebracht werden: Welche Auswirkungen hat das Risiko? Wie groß sind die Auswirkungen und wie dringlich ist eine Bearbeitung?
In LASR verwenden wir zur Identifikation von Risiken und Problemen im Basis-Review (3) einen fundierteren Pre-Mortem-Ansatz [Gray+2010]. Die Pre-Mortem-Methode nimmt den Misserfolg eines Vorhabens, in einer hypothetischen Betrachtung vorweg und ist eine der effektivsten Problem-Identifikations-Methoden. Leider sind ist die Problemsuche sehr offen und die Pre-Mortem Ergebnisse wirken oft wenig überraschend oder beliebig. LASR gibt deshalb konkrete Risikothemen vor und unterstützt eine breite Problemsuche, die Deine üblichen Denkmuster durchbrechen kann. Die gefundenen Probleme werden dann quantifiziert auf den Bewertungsmaßstab übertragen.
Während das Basis-Review erste Probleme sammelt und Lücken identifiziert, macht die Zielorientierte Analyse (4) das Ergebnisbild klarer und macht auch positive Abweichungen sichtbar. Hierfür schärfst du die wichtigsten Zielsetzungen etwas und analysierst anschließend die Software in Bezug auf detailliertere Qualitätsaussagen. Code- und Designaspekte spielen hier eine größere Rolle, bei Bedarf kannst Du auch vorhandene Metrik- und Monitoring-Auswertungen heranziehen.
Anders als bei schwergewichtigeren Methoden fokussiert LASR hier auf kritische oder umstrittene Ziele. Wenn es also z.B. im Wartbarkeitsbereich wenig offene Fragen gibt, oder im Sicherheitsbereich allen klar ist, woran es hakt, musst Du nicht aufwendig in die Tiefe gehen.
Einen etwas tieferen Einstieg in LASR bietet der JavaLand-Talk “Leichtgewichtige Software-Reviews 2.0”, den du hier direkt ansehen kannst.
Alternative Review-Ansätze
Neben LASR gibt es andere bekannte Methoden, um Software von der Zielsetzung her zu beleuchten und grundlegend zu bewerten. Die berühmteste Methode hierfür wäre ATAM – die Architecture Trade-off Analysis Method [Kazman+2000]. ATAM ist schwergewichtiger, in ihrer Beschreibung angestaubt und wirkt etwas zeremoniell. In schwierigeren, politisch aufgeladenen Kontexten oder in Situationen mit großer Fallhöhe sind ATAM-basierte Verfahren aber ein zeitloser Standard. Moderne Interpretationen von ATAM liefern tiefe Erkenntnisse und ermöglichen auch im Konfliktfall ein Weiterkommen.
Andere Methoden betrachten gezielter einzelne Lösungsaspekte (wie die DCAR - Decision Centric Architecture Reviews [Heesch+2014]) oder schließen die Kostenseite in die Überlegungen mit ein (CBAM - Cost-Benefit Analysis Method [Kazman+2002]). Gehst Du von der Architektur- auf die Design- oder Codeebene kannst Du statische Analysen und Metriken nutzen, um Erkenntnisse zu erlangen oder "Hot Spots" erkennen, die bei Wartung, Erweiterung und Veränderung der Software stören. Hast Du ein lauffähiges oder in Betrieb befindliches System, bieten sich außerdem dynamische Analysemöglichkeiten oder der Blick in Monitoring-Dashboards an.
Abbildung 2 zeigt eine (vereinfachte) Entscheidungshilfe, um die passendste Review-Methode herauszufinden. Sie soll vor allem ein Gefühl dafür geben, welche Stärken bekannte Methoden haben, und wo der berühmte "Sweet Spot" liegt. Neben LASR findest Du in der Grafik auch "LASR+" – hierbei handelt es sich um eine erweiterte Form von LASR, die auch Messungen und Code-Analysen beinhaltet und im Buch zu LASR genauer beschrieben ist [Toth+2024]. Sie wird vorrangig verwendet, um die Konfidenz in ein Review-Ergebnis zu erhöhen und ist ein Bindeglied zwischen leichtgewichtigen Ansätzen (Pre Mortem, LASR) und sehr fundierten Methoden (wie ATAM). Wenn Du noch wenig im Review-Bereich gemacht hast, experimentiere in unkomplizierten Umgebungen oder der Kapsel Deines Teams zunächst mit kleineren Methoden. Das ist meist ein guter Startpunkt.
Quellen/Referenzen:
- [Basiri+2016] Ali Basiri, Niosha Behnam, Ruud de Rooij, Lorin Hochstein, Luke Kosewski, Justin Reynolds und Casey Rosenthal: “Chaos engineering”, IEEE Software, Ausgabe 3/2016
- [Toth+2024] Stefan Toth, Stefan Zörner: Software-Systeme reviewen mit dem Lightweight Approach for Software Reviews, E-Book, Leanpub 2023
- [Gray+2010] Dave Gray, Sunni Brown, James Macanufo: "Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers", O'Reilly, 1. Auflage 2010
- [Kazman+2000] Rick Kazman, Mark H. Klein und Paul C. Clements: “ATAM: Method for Architecture Evaluation”, Technical Report CMU/SEI-2000-TR-004, Software Enginee- ring Institute, Carnegie Mellon University 2000
- [Heesch+2014] Uwe van Heesch, Veli-Pekka Eloranta, Paris Avgeriou, Kai Koskimies und Neil Harrison: “Decision-Centric Architecture Reviews”, IEEE Software, Ausgabe 1/2014
- [Kazman+2002] Rick Kazman, Jai Asundi und Mark Klein: “Making Architecture Design Decisions. An Economic Approach”, Technical Report CMU/SEI-2002-TR-035, Software Engineering Institute, Carnegie Mellon University 2002
