The Art of Software Reviews: Probleme und Risiken zielsicher identifizieren
<html> <header class=„article-header“><h1 class=„articleheading“>The Art of Software Reviews: Probleme und Risiken zielsicher identifizieren</h1><div class=„publish-info“> Gernot Starke</div></header><figure class=„aufmacherbild“><img src=„https://heise.cloudimg.io/width/700/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/0/2/0/2/5/6/artofreview-55c53aeff2a3441d.jpeg“ srcset=„https://heise.cloudimg.io/width/700/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/0/2/0/2/5/6/artofreview-55c53aeff2a3441d.jpeg 700w, https://heise.cloudimg.io/width/1050/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/0/2/0/2/5/6/artofreview-55c53aeff2a3441d.jpeg 1050w, https://heise.cloudimg.io/width/1497/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/0/2/0/2/5/6/artofreview-55c53aeff2a3441d.jpeg 1497w“ alt=„“ class=„img-responsive“ referrerpolicy=„no-referrer“ /></figure><p><strong>Auch in erfolgreichen Softwaresystemen lauern praktisch immer Probleme. Durch systematische Reviews können Teams diese Probleme zielgerichtet identifizieren.</strong></p><p>Getreu dem Bonmot „Besser geht immer“ leidet praktisch jede Software an Problemen kleiner oder großer Natur: Vielleicht läuft sie zu langsam, stürzt manchmal ab oder sieht weniger schön aus als das System der Konkurrenz. Häufig beschwert sich das Business lautstark darüber, dass neue Features viel zu lange dauern – neudeutsch: die Time-to-Market ist zu schlecht. Abgesehen von hello-world lässt sich überall noch so manches verbessern.</p><p>Wer dieses Verbesserungspotenzial seines Systems heben möchte, sollte auf jeden Fall zuerst ein explizites, konkretes und spezifisches Verständnis der vorhandenen Probleme erarbeiten. Dabei lässt sich aus der Medizin lernen: Dort steht vor den Therapievorschlägen zuerst eine gründliche Diagnose (Untersuchung). Ohne ein solches Review, wie die Untersuchung in der IT-Branche heißt, droht Verschlimmbesserung.</p><p>Der Artikel stellt die Breitensuche als den zentralen Ansatz methodischer Software-Reviews vor und beleuchtet einige der wesentlichen Untersuchungsansätze.</p><h3 class=„subheading“ id=„nav_fünf_phasen_0“>Fünf Phasen</h3><p>Schematisch sollten Reviews immer in fünf Phasen stattfinden:</p><ol class=„rtelist rtelist–ordered“><li>Vor Beginn sollten Teams mit den Auftraggebern oder Systemverantwortlichen die Zielsetzung sowie den Scope klären. Dazu legen sie gemeinsam fest, welchen zeitlichen Umfang das Review haben sollte. Mit diesen Personen definiert man auch das konkrete Vorgehen: Welche Interviews und Analysen braucht es zu welchem Zeitpunkt und mit welcher Beteiligung?</li><li>In einem Kick-off erläutern die Verantwortlichen dieses Vorgehen allen beteiligten Personen. Gleichzeitig können sie dieses Treffen für erste Gespräche über das System und dessen Stärken und Schwächen nutzen.</li><li>Nun folgen gezielte Interviews mit Beteiligten aus verschiedenen Bereichen.</li><li>Nach diesen Gesprächen bieten sich nach Bedarf weitere Analyseschritte an, in denen man gezielt auf die Suche nach Problemen und Risiken bestimmter Kategorien geht. Analysen und die Interviews von Schritt 3 können sich abwechseln: Die Ergebnisse von Interviews können bestimmte Analysen notwendig machen und umgekehrt.</li><li>Schließlich arbeitet man die Ergebnisse, Schlussfolgerungen und Empfehlungen auf und stellt diese den Beteiligten vor.</li></ol><figure class=„a-inline-image a-u-inline“><div><figcaption class=„a-caption“>Review-Ablauf (Abb. 1)</figcaption></div></figure><h3 class=„subheading“ id=„nav_wer_führt1“>Wer führt Reviews durch?</h3><p>Vor dem Review sollte überdacht werden, welche Personen überhaupt für ein Review in Frage kommen. Grundsätzlich können das die Beteiligten an der Entwicklung sein, alternativ auch Außenstehende („Externe“). Abbildung 2 stellt einige Vor- und Nachteile der beiden Varianten gegenüber – mit dem Fazit, für Reviews interne und externe Beteiligte zu mischen – so bekommt man ein „best of both worlds“: Sie schließen Befangenheit und Betriebsblindheit aus und kommen zeiteffektiv und inhaltlich fundiert zu konkreten Resultaten.</p><figure class=„a-inline-image a-u-inline“><div><figcaption class=„a-caption“>Interne versus externe Reviewer (Abb. 2)</figcaption></div></figure><p>Erfolgreiche Reviews beginnen mit einer klaren Formulierung von Zielen, die das Review erreichen soll. Solche Ziele sollten Projektverantwortliche mit den Auftraggebern des Reviews gemeinsam erarbeiten. Sie sollten fragen, was jemanden überhaupt zu einem Review motiviert oder welche Probleme es ausgelöst hat. Diese Ziele sollte man schriftlich festhalten – sonst geraten sie allzu schnell in Vergessenheit.</p><p>Neben den Zielen müssen die Beteiligten den Betrachtungsgegenstand des Reviews klären. Was genau sollen sie untersuchen? Eine Formulierung wie „das System X“ könnten verschiedene Personen unterschiedlich auslegen, daher legen sie gemeinsam mit den Auftraggebern fest, was genau sie untersuchen sollen. Typische Punkte dabei könnten sein:</p><ol class=„rtelist rtelist–ordered“><li>die Architektur, der strukturelle Aufbau des Systems aus Komponenten und deren Schnittstellen</li><li>eingesetzte Technologien sowie technische Konzepte des Systems</li><li>die Implementierung, also den Quellcode</li><li>der Betrieb des Systems in dessen Infrastruktur oder Zielumgebung</li><li>die Entwicklung beziehungsweise die Entwicklungsprozesse, beispielsweise Anforderungsklärung, Koordination von Entwicklungsaufgaben, Test und Qualitätssicherung, Konfigurations- und Versionsmanagement, Deployment, Rollout sowie Änderungsmanagement und Bugfixing</li></ol><header class=„a-boxheader“ data-collapse-trigger=„“>iX Developer – Moderne Softwarearchitektur</header><div class=„a-boxtarget a-boxcontent a-inline-textboxcontent“ data-collapse-target=„“><figure class=„a-inline-textboximage-container“><img alt=„“ src=„https://heise.cloudimg.io/width/421/q50.png-lossy-50.webp-lossy-50.foil1/_www-heise-de_/imgs/18/3/0/2/0/2/5/6/cover-sonderheft-69f98c34a829eedf.jpg“ srcset=„https://heise.cloudimg.io/width/842/q30.png-lossy-30.webp-lossy-30.foil1/_www-heise-de_/imgs/18/3/0/2/0/2/5/6/cover-sonderheft-69f98c34a829eedf.jpg 2x“ class=„c1“ referrerpolicy=„no-referrer“ /></figure><div class=„a-inline-textboxcontent-container“><p>Dieser Artikel stammt aus dem Sonderheft „iX Developer – Moderne Softwarearchitektur“. Es bildet auf 148 Seiten einen Querschnitt zu wichtigen Themen zeitgemäßer Softwarearchitektur. <a href=„https://shop.heise.de/ix-developer-moderne-softwarearchitektur-2020/Print“ rel=„external noopener“ target=„_blank“><strong>Einen Überblick bekommen Interessierte hier [1]</strong></a>. Die gedruckte Ausgabe kosten 14,90 Euro, die PDF-Ausgabe 12,99 Euro.</p></div></div><p>Die Beteiligten sollten in diesem Vorgespräch dafür sorgen, dass Scope und Ziele zusammenpassen. Ebenso klären sie, welche Personen mitarbeiten. Das gilt auch für die Mitwirkung der Auftraggeber sowie Termine.</p><h3 class=„subheading“ id=„nav_wie_lange2“>Wie lange?</h3><p>Aufwand oder Dauer eines Reviews hängen primär von den Zielen, dem Scope und der Größe des betrachteten Systems ab. Der Autor hat Reviews zwischen zwei und 60 Personentagen (kurz: PT) durchgeführt. In zwei bis vier PT können Teams einen Überblick gewinnen und eine Art „Bericht zur Lage der Nation“ abgeben, ohne dabei viel Code zu sehen. Für große Systeme inklusive Betrachtung von Quellcode sowie organisatorischen Aspekten steigt der Aufwand für Reviews entsprechend an. Im Rahmen von 10 bis15 PT lassen sich schon recht viele Aspekte beleuchten und eine Menge Interviews führen. Falls sich das nach viel Aufwand anhört: Für Systeme mit 10 Personenjahren Entwicklungsaufwand (also ca. 2300 PT) bedeuten 10 PT ja gerade mal 0,4 Prozent des Gesamtaufwandes. Im Vergleich: Inspektionskosten beim PKW liegen bei knapp einem Prozent des Kaufpreises pro Jahr.</p><p>Teams sollten von ihrem Zeitbudget mindestens 20 Prozent für die Vorbereitung und Kommunikation ihrer Ergebnisse kalkulieren. Oftmals kommen nach einer Abschlusspräsentation noch eine Menge Fragen und Änderungswünsche auf das Review-Team zu.</p><h3 class=„subheading“ id=„nav_kick_off_3“>Kick-off</h3><p>Es empfiehlt sich, alle Beteiligten zu einem kurzen Kick-off-Workshop einzuladen, auf dem die Ziele und der Scope des Reviews sowie die Vorgehensweise kommuniziert werden, zusammen mit Meilensteinen und dem Zieltermin. Das spart bei den eigentlichen Interviews viel Zeit und beugt einer unproduktiven Gerüchteküche vor. Das schließt die Fach-/Produktseite, das Entwicklungsteam, Test/QS, Betrieb sowie gegebenenfalls Nutzer ein. Jedes Kick-off verdient eine individuelle Agenda, aber ein paar Themen gehören in jedem Fall dazu:</p><ul class=„rtelist rtelist–unordered“><li>Fachlich/organisatorisch verantwortliche Personen sollten den wirtschaftlichen oder fachlichen Zweck des Systems in Kurzform darstellen.</li><li>Technisch versierte Personen (etwa: Architekten, Entwicklungsleitung) sollten die Architektur des Systems beziehungsweise wesentliche Subsysteme und fundamentale technische Entscheidungen aufzeigen.</li><li>Jemand sollte das Entwicklungsvorgehen skizzieren, von Anforderungen über Implementierung/Test, Build, Deployment und Release.</li></ul><p>In dieser Runde lässt sich eine erste qualitative Analyse des Systems durchführen, also Probleme bezüglich konkreter Qualitätsanforderungen suchen.</p><h3 class=„subheading“ id=„nav_kern_der_sache_4“>Kern der Sache</h3><p>Zentrale Aufgabe üblicher Reviews ist die Suche nach Problemen, und die finden sich an ganz unterschiedlichen Stellen – auch jenseits vom reinen Quellcode. Tabelle 1 zeigt einige typische Bereiche, in denen man bei der Suche fündig wird.</p><section class=„a-inline-table“><table class=„a-inline-tabletable“><tbody><tr><td class=„heise-table-subtitle c2“>Bereich</td><td class=„heise-table-subtitle c2“>Was zu untersuchen ist</td></tr><tr><td class=„c3“>Architektur</td><td class=„c3“>interne Struktur & Modularisierung (Komponenten, Subsysteme), interne Schnittstellen & Abhängigkeiten, Kopplung, Kohäsion, Konsistenz („Homogenität“)</td></tr><tr><td class=„c3“>Code</td><td class=„c3“>Strukturierung, Komplexität, Änderungshäufigkeit, Verständlichkeit, Kopplung, Einheitlichkeit</td></tr><tr><td class=„c3“>Technologie</td><td class=„c3“>Eingesetzte Basistechnologie, 3rd-Party-Produkte/-Frameworks</td></tr><tr><td class=„c3“>Qualität</td><td class=„c3“>Erreichung von Qualitätsanforderungen, etwa bezüglich Performance, Änderbarkeit, Robustheit, Benutzbarkeit, Betreibbarkeit</td></tr><tr><td class=„c3“>Kontext</td><td class=„c3“>Externe Schnittstellen, externe Datenquellen und -senken, Benutzerrollen</td></tr><tr><td class=„c3“>Infrastruktur</td><td class=„c3“>Verwendete Hardware/Infrastruktur, Prozessoren, Netzwerke, Speichermedien, Topologie</td></tr><tr><td class=„c3“>Daten</td><td class=„c3“>Datenstrukturen, Datenbanken, Datenbanksysteme, Korrektheit und Volatilität von Daten, Verteilung/Replikation, Backup</td></tr><tr><td class=„c3“>Laufzeitverhalten</td><td class=„c3“>Laufzeit- und Speicherverhalten, allgemeine Ressourcennutzung, Bottlenecks</td></tr><tr><td class=„c3“>Entwicklungsprozess</td><td class=„c3“>Der Weg von Anforderungen zur laufenden Umsetzung, Requirements- und Change-Management, Entwicklung, Test, Build, Deployment, Versionsmanagement</td></tr><tr><td class=„c3“>Dokumentation</td><td class=„c3“>Das ungeliebte Thema vieler Entwicklungsteams. Zu viel oder zu wenig Dokumentation, Aktualität/Korrektheit und Akzeptanz, Auffindbarkeit, Konsistenz</td></tr><tr><td class=„c3“>Management</td><td class=„c3“>Umgang mit Zeit und Budget, Ressourcenplanung, Organisation der gesamten Entwicklung</td></tr></tbody></table></section><p>Die Beteiligten sollten bei Reviews stets in der Breite suchen. Das heißt, sie stellen möglichst zu allen der in Tabelle 1 aufgeführten Themen Fragen. Die Erfahrung aus Dutzenden von Reviews zeigt, dass gravierende Probleme in Systemen definitiv nicht auf Code und Kopplung beschränkt sind, sondern dass manchmal die wirklich schlimmen Dinge an ganz anderen Stellen lauern. Ständig wechselnde Prioritäten bei Anforderungen sowie den Zwang zur Nutzung veralteter Datenstrukturen oder Datenbanken seien hier als Beispiele aufgeführt.</p><p>Es gibt neben dem Entwicklungsteam noch eine Reihe weiterer Personen oder Organisationen, die Auskünfte über das System und seine Eigenschaften respektive Probleme geben können. Diese kennen Stärken und Schwächen aus erster Hand, erleben Probleme und profitieren von Stärken – das sind für einen Review wertvolle Informationen.</p><p>Da das Review als Breitensuche durchgeführt wird, sollte auch die Auswahl der Interviewpartner in die Breite gehen. Hier sollte man beispielsweise mit folgenden Gruppen sprechen:</p><ul class=„rtelist rtelist–unordered“><li>Nutzer</li><li>fachlich Verantwortliche (etwa: Vertreter der Fachbereiche)</li><li>technisch Verantwortliche (etwa: Architekten)</li><li>Auftraggeber, Management</li><li>Beteiligte aus dem Entwicklungsteam. Bei größeren Systemen mit mehreren großen Subsystemen oder Komponenten eine Mischung aus mehreren Teams</li><li>Test/Qualitätssicherung, falls nicht Teil des Entwicklungsteams</li><li>Personen aus Infrastruktur und/oder Betrieb</li><li>Projekt- und Produkt-Manager</li><li>in agilen Organisationen: Product Owner, Scrum Master oder Agile Coach</li></ul><p>Es empfiehlt sich, in Interviews offene Fragen zu stellen, die ganze Sätze als Antworten erfordern, und Ja- beziehungsweise Nein-Fragen zu vermeiden. Ratsam ist auch, nach Problemen, Schwierigkeiten und besonders aufwendigen oder langwierigen Aktivitäten im Zusammenhang mit dem System zu fragen, genauso wie nach Dingen oder Aspekten, die Personen unbedingt beibehalten möchten.</p><p>Schließlich empfiehlt der Autor, auch nach denkbaren Abhilfen der genannten Probleme zu fragen, um die Kreativität der Interviewpartner herauszufordern:</p><ul class=„rtelist rtelist–unordered“><li>Was würden diese tun, wenn sie eine Woche lang die gesamte Entwicklung beliebig steuern dürften?</li><li>Was wären die Top-3-Änderungen am System, dem Entwicklungsprozess oder der Organisation, wenn sie das bestimmen dürften?</li></ul><p>Zum Abschluss eines Interviews ist hilfreich, sich zu erkundigen, welche Fragen vermisst wurden. Das gibt den interviewten Personen die Gelegenheit, noch ganz andere Themen anzusprechen.</p><p>Interviews sollte man am besten zu zweit führen. Wenn ein Duo im Wechsel fragt und mitschreibt, dann kann sich die fragende Person besser auf Gestik, Mimik und Verhalten der anderen konzentrieren und ist nicht ständig durch Mitschreiben abgelenkt. Man sollte Bemerkungen markieren, die weitere Analysen oder Nachprüfungen erfordern, und sich bei Bedarf weitere Ansprechpersonen nennen lassen, die mehr Informationen zu bestimmten Themen haben. Die Interviews sollten auf 60 bis 90 Minuten begrenzt sein, und bei Bedarf sollte man lieber Folgetermine vereinbaren. Zwischen zwei solcher Interviews sollten Interviewer für sich selbst 15 Minuten Pause einplanen, damit sie kurz reflektieren, ihre Notizen kennzeichnen und sich für das nachfolgende Interview mental sammeln können.</p><h3 class=„subheading“ id=„nav_externe5“>Externe Schnittstellen</h3><p>Reviewer sollten die Außenwelt des Systems analysieren, also dessen externe Schnittstellen. Dazu ist erst mal sicherzustellen, dass sie überhaupt sämtliche Außenschnittstellen kennen – gerade in Business-Informationssystemen können das oft mehrere Dutzende sein. <a href=„https://docs.arc42.org/section-3/“ rel=„external noopener“ target=„_blank“><strong>Ein Kontextdiagramm mag hier helfen [2]</strong></a> – und falls es keines gibt, gibt es schon einen hilfreichen Verbesserungsvorschlag.</p><p>Welche dieser externen Schnittstellen verursachen im laufenden Betrieb Probleme? Hier sind möglicherweise die Verantwortlichen der Nachbarsysteme zu befragen, weil das System ja eventuell bei anderen Probleme verursacht. Wie schaut es mit eventuellen Service-Level Agreements dieser Schnittstellen bezüglich Verletzungen aus? Externen Schnittstellen im laufenden Betrieb „auf die Finger“ zu schauen, funktioniert über die Untersuchung von Logfiles oder Monitoring nach Auffälligkeiten. Letztlich gilt es, die Implementierung externer Schnittstellen durch gezielte Code-Reviews zu überprüfen.</p><p>Besonderes Augenmerk benötigen solche externen Schnittstellen, deren Nutzung direkte Kosten verursacht (etwa: Aufrufe kostenpflichtiger Dienste) oder deren Definition oder Spezifikation sich häufig ändert.</p><h3 class=„subheading“ id=„nav_qualität_im6“>Qualität im Griff?</h3><p>Reviewer sollten untersuchen, inwieweit das System seine Qualitätsanforderungen erfüllt oder welche Qualitätseigenschaften nicht angemessen erreicht werden. Offensichtlich müssen sie dazu erst mal die Qualitätsanforderungen genau kennen: In vielen Jahren Review-Praxis hat der Autor nur wenige Systeme erlebt, bei denen es eine halbwegs aktuelle Übersicht davon gab. Meist war die spezifischen Qualitätsanforderungen im Rahmen des Reviews erst aufzuarbeiten.</p><p>Zum Glück gibt es dafür im Software- und Requirements Engineering etablierte Methoden, beispielsweise <a href=„https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=5177“ rel=„external noopener“ target=„_blank“><strong>ATAM [3]</strong></a>, die sich in Reviews in vereinfachter Form anwenden lassen. Zur Beschreibung von Qualitätsanforderungen verwendet der Autor sogenannte Szenarien (s. Abb. 3). Sie beschreiben in Umgangssprache, wie das System sich bei bestimmten Ereignissen verhalten soll. Falls das zu abstrakt klingt – in Tabelle 2 finden sich einige Beispiele.</p><figure class=„a-inline-image a-u-inline“><div><figcaption class=„a-caption“>Szenarien erklären Qualitätsanforderungen (Abb. 3)</figcaption></div></figure><section class=„a-inline-table“><table class=„a-inline-tabletable“><tbody><tr><td class=„heise-table-subtitle c2“>Eigenschaft</td><td class=„heise-table-subtitle c2“>Auslöser</td><td class=„heise-table-subtitle c2“>Reaktion</td></tr><tr><td class=„c3“>Performance</td><td class=„c3“>Nutzer fordert den Monatsreport der Kostenstelle xyz an.</td><td class=„c3“>Das System erzeugt den Report innerhalb von 3 Sekunden.<br /> </td></tr><tr><td class=„c3“>Performance</td><td class=„c3“>Produktsuche mit Standardkriterien (Artikelbezeichnung/-nummer)<br /> </td><td class=„c3“>Dauert maximal 500 ms bis zur Anzeige der ersten 5 Treffer<br /> </td></tr><tr><td class=„c3“>Robustheit, Fehlertoleranz</td><td class=„c3“>Das externe System xyz antwortet mehr als 3 Sekunden lang nicht mehr.<br /> </td><td class=„c3“>Das System meldet diesen Fehler innerhalb von 30 Sekunden an den „Administrator vom Dienst“.<br /> </td></tr><tr><td class=„c3“>Flexibilität, Änderbarkeit</td><td class=„c3“>Der Fachbereich fordert eine Änderung des xyz-Tarifs im System.</td><td class=„c3“>Diese Änderung lässt sich innerhalb von 4 Stunden im System umsetzen.</td></tr></tbody></table></section><p>Mit solchen konkreten Qualitätsanforderungen gestaltet sich die Analyse relativ einfach: Gemeinsam mit Architekten oder dem Entwicklungsteam untersuchen Reviewer, ob das System oder dessen Architektur die definierten Szenarien (= Qualitätsanforderungen) erfüllen kann. Hierzu sollte man sich die zugehörigen Architekturentscheidungen und -ansätze erläutern lassen. Hier hilft, gemeinsam mit den Beteiligten aus dem Entwicklungsteam diese Szenarien in Form von Walkthroughs durchzuspielen, möglichst detailliert und feingranular. Und es ist herauszufinden, wie die Bausteine des Systems zum Erreichen dieses Szenarios zusammenspielen und welche Entwurfsentscheidungen das jeweilige Szenario unterstützen. Dabei kann man sich einen Eindruck verschaffen, wie sicher sich die jeweiligen Qualitätsanforderungen erreichen lassen.</p><p>Aus Erfahrung bekommen Reviewer bereits in den Interviews viele Hinweise, welche Qualitätseigenschaften im System die meisten Probleme bereiten, sodass die detaillierte Analyse im Grunde die Bestätigung (oder Widerlegung) der geäußerten Defizite darstellt.</p><h3 class=„subheading“ id=„nav_architektur7“>Architektur prüfen</h3><p>Bevor der Artikel auf Details zu diesem wichtigen Aspekt von Reviews eingeht, eine kurze Zusammenfassung, was unter dem Begriff „Softwarearchitektur“ zu verstehen und was demzufolge unter der Rubrik Architektur zu untersuchen ist. Es geht um folgende Aspekte:</p><ul class=„rtelist rtelist–unordered“><li>interne Struktur des Systems: die Modularisierung, den Schnitt des Systems, die Zerlegung in Subsysteme oder Komponenten. Idealerweise entspricht dieser Schnitt der fachlichen Struktur, neudeutsch der Domänenstruktur. Hierzu zählt auch das große Thema der internen Schnittstellen.</li><li><a href=„https://docs.arc42.org/section-8/“ rel=„external noopener“ target=„_blank“><strong>querschnittliche Konzepte [4]</strong></a>: Vorgaben zu Themen, die übergreifenden Charakter besitzen und sicherstellen, dass die Implementierung des Systems passenden Regeln folgt. Beispiele sind Aufbau und Gestaltung von Benutzungsschnittstellen (UI), Mechanismen zur Persistenz, Monitoring/Logging, Integration von Fremdsystemen.</li></ul><p>Über die Prüfung der internen Struktur gibt es ganze Bücher [1] – kurz gefasst müssen Architekten dazu intensiv in den Code schauen (oder für ganz Mutige: Der hoffentlich vorhandenen Dokumentation glauben – wovon dringend abzuraten ist). Vermutlich ist der Code eines Systems jedoch so umfangreich, dass man für das Review lieber ein Analysewerkzeug (wie Sonargraph, Structure-101, ReSharper, Sotograph oder Lattix), einsetzt, dass aus dem Code eine Übersicht von Komponenten und deren Abhängigkeiten erzeugen kann. Die Abbildungen 4 und 5 zeigen zwei Beispiele solcher Analysen. Architekten bleibt die anspruchsvolle Aufgabe, diese grafischen Darstellungen zu interpretieren: Sind diese Komponentenstruktur respektive diese Abhängigkeiten angemessen für das System? Wo besteht zu enge Kopplung, und stellt die wirklich ein Problem dar?</p><figure class=„a-inline-image a-u-inline“><div><figcaption class=„a-caption“>SotoArc-Analyse von Paketstrukturen (Abb. 4)</figcaption></div><p class=„a-captionsource“>(Bild: Hello2Morrow)</p></figure><figure class=„a-inline-image a-u-inline“><div><figcaption class=„a-caption“>Sotograph-Analyse von infoglue (Abb. 5)</figcaption></div><p class=„a-captionsource“>(Bild: Carola Lilienthal)</p></figure><h3 class=„subheading“ id=„nav_code_reviews_8“>Code-Reviews</h3><p>Mit der Analyse der Softwarearchitektur rein auf Grundlage des vorhandenen Quellcodes ist es leider nicht getan. Es ist ein Irrglaube, dass alle Informationen im Code stehen. Das klingt zunächst kontraintuitiv. Was sollte wichtiger sein als Quellcode? Nachfolgend finden sich ein paar (mögliche) Gründe, warum andere Dinge noch wichtiger sein könnten:</p><ul class=„rtelist rtelist–unordered“><li>Möglicherweise hat man eine hervorragend strukturierte, nach allen Regeln der Kunst durchgeführte Implementierung einer äußerst schlechten Idee vor sich, zum Beispiel weil es für den gleichen Einsatzzweck bessere, fertige Komponenten gibt.</li><li>Vielleicht würde der ein oder andere problematische oder vielleicht sogar besonders elegante Teil der Software gar nicht benötigt, wenn man eine technische Anforderung hinterfragen würde.</li><li>Manchmal befindet sich ein großer Teil der wichtigen Information nicht in „klassischem“ Quellcode, sondern in Konfigurationsdateien oder „Glue-Code“, der auf den ersten Blick gar nicht ins Auge fällt.</li><li>Vielleicht ist die Laufzeitarchitektur des Systems äußerst elegant, führt aber zu enormen Herausforderungen im Entwicklungsprozess – oder andersherum.</li><li>Unter Umständen spielt die Aufteilung in verschiedene Teilkomponenten in einem verteilten System eine viel größere Rolle als die Implementierung der einzelnen Systeme.</li><li>Vielleicht entstehen Probleme durch eine suboptimale Aufteilung zwischen Hardware- und Softwarekomponenten (besonders bei Embedded-Systemen) oder durch eine verbesserungswürdige Verwendung von Standardsoftware.</li></ul><p>Die genannten Fälle unterscheiden sich sehr, und das ist ein spannender Aspekt von Reviews: Man muss sich in das System hineindenken und es aus unterschiedlichen Perspektiven hinterfragen. Es gibt leider kein Standardrezept, und auch die mächtigen Analysewerkzeuge können nur einen Teil der möglichen Probleme aufdecken.</p><p>Dennoch sollte Reviewer Code analysieren, weil sie damit eine Reihe gravierender Probleme finden können: schwer verständliche Teile, verursacht durch übermäßige Größe oder komplizierte Implementierung, Abweichungen von Code-Konventionen oder schlicht handwerklich schlecht implementierte Teile. Es gibt Code, der verschwenderisch mit CPU oder Speicher umgeht, Stellen ohne automatisierte Tests oder Passagen, die von den vereinbarten Architekturkonzepten abweichen.</p><p>Viele solcher Probleme lassen sich mit statischer Codeanalyse herausfinden. SonarQube, TeamScale, ReSharper oder Checkstyle seien hier als Beispiele für Tools genannt. Zu achten ist bei solchen statischen Analysen besonders auf negative Ausreißer bei Codekomplexität (etwa: zyklomatische Komplexität) oder Kopplung. Ganz wesentlich bleibt bei Code-Reviews allerdings die menschliche Expertise und Einschätzung.</p><h3 class=„subheading“ id=„nav_hotspot_analyse_9“>Hotspot-Analyse</h3><p>Eine besonders hilfreiche Art der Code-Analyse sollten Reviewer auf jeden Fall durchführen – die Hotspot-Analyse: Ein Hotspot ist ein Baustein, der häufig geändert wird und gleichzeitig eine hohe innere Komplexität besitzt. Die Änderungshäufigkeit lässt sich aus der Versionsverwaltung, Git, Subversion und Co. abfragen, die Komplexität von Code relativ einfach über statische Analysen messen. Adam Tornhill hat in seinem Buch [2] entsprechende Analysewerkzeuge als Open Source veröffentlicht. Ein Beispiel solcher Hotspot-Analysen zeigt Abbildung 6.</p><p>Hotspot-Analysen finden hochgradig riskante Teile eines Systems: Komplexe Stellen besitzen ein sehr hohes Fehler- und Änderungsrisiko, und sind tendenziell auch viel aufwändiger in der Wartung. Das kombiniert mit hoher Änderungsfrequenz ist fast schon eine Garantie, dass bei diesen Bausteinen gravierende Probleme auftreten werden!</p><figure class=„a-inline-image a-u-inline“><div><figcaption class=„a-caption“>Beispiel für eine Hotspot-Analyse (Abb. 6)</figcaption></div></figure><h3 class=„subheading“ id=„nav_anwendungsdaten_10“>Anwendungsdaten</h3><p>Die zuverlässige Speicherung und Bereitstellung von Daten gehören für die meisten Anwendungen zu den Kernaufgaben. Die Daten einer Anwendung leben oft länger als der Quellcode. Quellcode lässt sich vergleichsweise einfach erweitern, refaktorieren oder auf eine neue Framework-Version anpassen, Bugfixes lassen sich meist relativ einfach deployen, fehlerhafte oder verlorene Daten dagegen nur schwer und aufwendig reparieren. Änderungen an den Strukturen eines produktiven Datenbestands sind oftmals zeitintensiv und erfordern sorgfältige Planung. Fehler in der Datenmodellierung werden Teams entsprechend länger verfolgen. Auch der Wechsel einer Datenbank ist teuer und zeitintensiv. Ein Wechsel von MySQL zu PostgreSQL ist aufwendig, weil alle datenbankspezifischen Funktionen zu finden und zu ersetzen sind. Ein Wechsel von MongoDB auf MySQL noch aufwendiger, weil er einen kompletten Wechsel des Datenmodells und des Schemamanagements erfordert. Im Rahmen des Reviews ist es die Aufgabe herauszufinden, ob die Auswahl der datenspeichernden Systeme, die Modellierung der Daten und ihre Übermittlung, Transformation und Qualität den Erfordernissen der jeweiligen Anwendung entspricht.</p><p>Deswegen sollte man sich zuerst einen Überblick über alle datenspeichernden Komponenten sowie der dazu eingesetzten Software verschaffen. Passen die verwendeten Datenmodelle und -strukturen noch zur aktuellen Domäne? Oder werden die aktuellen Business-Daten in irgendwelche historischen Strukturen „gequetscht“? Werden Daten redundant gehalten oder häufig synchronisiert? Gibt es Integrationsdatenbanken – die heute eher als Anti-Pattern gelten? Gibt es Problemen mit Antwortzeiten bei Abfragen? Laufen manche Anfragen extrem lange oder extrem häufig?</p><h3 class=„subheading“ id=„nav_garbage_in11“>Garbage-in …</h3><p>Danach gilt es, den Blick vom Code respektive der Technik hin zu den Entwicklungsprozessen, und dabei konkret auf die Anforderungen zu werfen: Gibt es für das System ein vernünftiges, angemessenes Requirements Engineering – oder purzeln Change-Requests rein zufällig auf das Entwicklungsteam? Gibt es einen ordentlich gepflegten Backlog, der den Namen auch verdient?</p><p>Auf Basis mangelhafter Anforderungen mit ständig wechselnden Prioritäten können auch hervorragende Entwicklungsteams keine gute Software produzieren – eben „garbage in, garbage out“. Typische Schwierigkeiten mit Anforderungsprozessen sind etwa folgende:</p><ul class=„rtelist rtelist–unordered“><li>Unklarheit über das Gewollte: Anforderungen bleiben vage, unpräzise, grob. Das Resultat: Entwicklungsteams implementieren stark konfigurierbare Systeme und verschieben damit die Entscheidungen über die konkrete Bedeutung von Anforderungen auf die Laufzeit.</li><li>Die Involvierten wollen dauernd etwas anderes: Hohe Volatilität in Anforderungen, sodass Entwicklungsteams häufig umbauen müssen.Verschiedene Stakeholder fordern widersprüchliche Dinge: Das können verschiedene Anforderungen an Daten, Validierungs- oder Geschäftsregeln bis hin zu unterschiedlichen Algorithmen sein.</li><li>Anforderungen benötigen innerhalb der gesamten Organisation zu lange, bis sie beim Entwicklungsteam landen. Es gibt zu viele beteiligte Personen, zu viele Gremien oder zu viele Abstimmungsprozesse.</li></ul><h3 class=„subheading“ id=„nav_layer_8_probleme_12“>Layer-8-Probleme</h3><p>Sicherlich hat jedes Team schon mal Abstimmungs- oder Kommunikationsprobleme durchlitten – und solche können gravierende Auswirkungen auf die betroffenen Systeme haben. Im Rahmen der Reviews sollte man auch die betroffenen Arbeitsprozesse und die (Team-)Kommunikation untersuchen: Wo gibt es Know-how-Flaschenhälse? Ist die Entscheidungskompetenz angemessen verteilt? Gibt es ausreichend Feedback zwischen den Beteiligten? Gibt es genügend Freiraum und genügend Festlegungen? Reviewer sollten innerhalb von Entwicklungsprozessen nach Aufgaben suchen, an denen ungebührlich viele Personen beteiligt sind, die unangemessen lange dauern oder mit denen Stakeholder sonstige Probleme berichten.</p><p>Alle arbeiten unter Zeit- und/oder Budgetdruck – das allein kann erst mal nicht als „Ursache aller Probleme“ gelten. Allerdings können Organisationen beziehungsweise Entwicklungsteams diesen Druck leicht übertreiben. Deswegen ist der Blick auf Entwurfs- und Testprozesse, Build/Release und Deployment, aber auch organisatorische und betriebliche Themen wichtig. Sind Agilität und DevOps wirklich umgesetzt, oder bleibt es beim Lippenbekenntnis? Gibt es automatisierte Tests, und finden diese überhaupt relevante Fehler?</p><p>Bis hierhin wurde schon in vielen Ecken des Systems nach Problemen gesucht – aber Probleme sind ungeheuer erfinderisch und verstecken sich auch an anderen Stellen: Bisher hat der Artikel zum Beispiel die technische Infrastruktur respektive Hardware ausgeklammert, das Monitoring/Logging oder auch das leidige Thema Dokumentation. Zu Beginn hatte der Autor die Breitensuche ins Spiel gebracht – nun ist zu entscheiden, ob man bereits in ausreichender Breite gesucht hat oder ob es für das konkrete System noch weitere Analysen geben sollte. <a href=„https://leanpub.com/software-reviews“ rel=„external noopener“ target=„_blank“><strong>Im Buch des Autors und einigen seiner Kollegen [5]</strong></a> finden sich noch ein paar Vorschläge.</p><h3 class=„subheading“ id=„nav_resultate13“>Resultate kommunizieren</h3><p>Am Ende eines Reviews steht normalerweise ein Abschlussbericht, der in einer Präsentation den beteiligten Personen vorgestellt wird. Das möglicherweise wichtigste Resultat des gesamten Reviews ist dabei eine kompakte Zusammenfassung („Management Summary“). Sie sollte maximal drei Handlungsempfehlungen mitsamt Herleitungen darlegen und erst zum Schluss verfasst werden, wenn die Resultate feststehen.</p><p>Neben der Zusammenfassung sollte die Präsentation Erklärungen enthalten, wie die Ergebnisse zustande gekommen sind und wie sie sich belegen lassen. Es empfiehlt sich, die gefundenen Probleme in drei Kategorien einzuteilen: schlimm (hohe Mehrkosten oder starke Verzögerungen), mittel (Kosten oder Verzögerungen) und störend. Entsprechend dieser Prioritäten sollte man Verbesserungs- oder Abhilfemaßnahmen vorschlagen. Vergessen sollten Reviewer auch nicht, das Gute ausdrücklich zu benennen, das sie vorgefunden haben: gute Entscheidungen, gute Strukturen, gute Prozesse – darüber freuen sich Auftraggeber und das Entwicklungsteam.</p><header class=„a-boxheader“ data-collapse-trigger=„“>Rezept für die Abschlusspräsentation</header><div class=„a-boxtarget a-boxcontent a-inline-textboxcontent a-inline-textboxcontent-container“ data-collapse-target=„“><p>Gemäß dem nachfolgenden Vorschlag können Reviewer ihre Abschlusspräsentation oder ihren Abschlussbericht aufbauen.</p><ol class=„boxtitel“><li>Eine kurze, sehr prägnante Management-Summary (Hinweise dazu im Text).</li><li>Zusammenfassung organisatorischer Aspekte des Reviews:<ul><li>Was genau waren die Ziele und Scope des Reviews?</li><li>Welche Beschränkungen gibt es?</li><li>Wie wurde vorgegangen? Wie viel Zeit wurde (circa) worin investiert?</li><li>Mit wem hat wer worüber gesprochen, inklusive Daten und Dauer?</li><li>Welche Aktivitäten waren neben Gesprächen und Interviews Bestandteil des Reviews?</li></ul></li><li>Welche Aspekte am System und dessen Entwicklung waren positiv zu bewerten (keep, don't change)?</li><li>Eine Zusammenfassung der Probleme und Risiken, Top-down beschreiben<ul><li>In welchen Kategorien waren Probleme und Risiken zu finden?</li><li>Welche Probleme gab es, beginnend mit den höchsten Prioritäten (also die schlimmsten, gravierendsten Probleme zuerst)?</li><li>Wo drohen Risiken?</li><li>Welche Auswirkungen sind zu erwarten oder sind bereits akut?</li></ul></li><li>Zusammenfassung der vorgeschlagenen Maßnahmen (optional)<ul><li>In welchen strategischen, technischen oder organisatorischen Bereichen sind Maßnahmen zu empfehlen?</li><li>Welche unterschiedlichen Optionen gibt es?</li></ul></li></ol></div><h3 class=„subheading“ id=„nav_fazit_14“>Fazit</h3><p>Mit Reviews lassen sich Probleme im System und dessen Umfeld systematisch und zuverlässig identifizieren. Das benötigt zwar etwas Zeit, birgt aber sehr hohes Nutzenpotenzial. Die gute Nachricht: Die meisten Analysen lassen sich ohne den Einsatz teurer oder komplizierter Werkzeuge durchführen – mit Hirn, Erfahrung und Motivation. Hauptsache, man sucht in der Breite.</p><p><em>Gernot Starke</em></p><p><em>ist INNOQ Fellow. Er verbessert und entwickelt Softwarearchitekturen. Außerdem ist er Mitgründer und Betreiber der <a href=„http://aim42.github.io/“ rel=„external noopener“ target=„_blank“><strong>„Architecture Improvement Method“ aim42 [6]</strong></a>, des Architekturportals arc42, sowie aktives Mitglied im iSAQB e.V. Teile dieses Artikels basieren auf dem Buch „<a href=„https://leanpub.com/software-reviews“ rel=„external noopener“ target=„_blank“><strong>Software-Reviews [7]</strong></a>“, das Starke zusammen mit Markus Harrer, Christine Koppelt und Benjamin Wolf verfasst hat.</em></p><h5 id=„nav_literatur_15“>Literatur</h5><ol class=„rtelist rtelist–ordered“><li>Carola Lilienthal; Langlebige Softwarearchitekturen; dpunkt.verlag 2020 (3. Aufl.)</li><li>Adam Tornhill; Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs; Pragmatic Bookshelf 2015</li></ol><p>() </p><hr /><p><strong>URL dieses Artikels:</strong><br /><small><code>https://www.heise.de/-4990332</code></small></p><p><strong>Links in diesem Artikel:</strong><br /><small><code><strong>[1]</strong> https://shop.heise.de/ix-developer-moderne-softwarearchitektur-2020/Print</code></small><br /><small><code><strong>[2]</strong> https://docs.arc42.org/section-3/</code></small><br /><small><code><strong>[3]</strong> https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=5177</code></small><br /><small><code><strong>[4]</strong> https://docs.arc42.org/section-8/</code></small><br /><small><code><strong>[5]</strong> https://leanpub.com/software-reviews</code></small><br /><small><code><strong>[6]</strong> http://aim42.github.io/</code></small><br /><small><code><strong>[7]</strong> https://leanpub.com/software-reviews</code></small><br /><small><code><strong>[8]</strong> mailto:ane@heise.de</code></small><br /></p><p class=„printversioncopyright“><em>Copyright © 2020 Heise Medien</em></p> </html>
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International