Zeitgemäße Softwarearchitektur – Teil 1

Zeitgemäße Softwarearchitektur: Der Umgang mit beschränkten Mitteln

Stefan Toth
© Shutterstock/pzAxe

Haben Sie schon einmal erklärt bekommen, wie das mit der Softwarearchitektur richtig funktioniert? Haben Sie schon mal ein Buch gelesen und gedacht: So müssten wir mal arbeiten? Bei mir war beides öfter der Fall, und am Ende hat der Projektalltag alles zunichtegemacht: kein Geld, keine Zeit, die falschen Leute oder zu viel „Legacy“. Arbeit an der Softwarearchitektur findet (leider) selten ideale Voraussetzungen. Eine moderne Disziplin muss deshalb mit der Unvollkommenheit unserer Projekte zurechtkommen. Ein Schlüssel dazu: der Umgang mit beschränkten Mitteln.

Die Zeit von Weihnachtsgebäck liegt schon etwas zurück und trotzdem möchte ich zum Einstieg darüber sprechen. Weihnachten kommt schließlich wieder. Haben Sie sich schon einmal überlegt, was Sie tun müssten, um aus einem ausgerollten Teig, Kekse so exakt auszustechen, dass Sie nur eine einzige Iteration benötigen, um die ganze Keksladung zu produzieren? Sicher eine Planungsphase, wahrscheinlich neue, aufeinander abgestimmte Ausstechformen (Tools), mehr Disziplin bei der Arbeit und einen größeren Backofen. Ganz ehrlich: Ich werde nichts davon im nächsten Advent haben. Ich werde mit den Formen leben, die ich habe, den alten Ofen verwenden, und Planung ist mir zu anstrengend, weil exaktes Ausrollen und Ausstechen sowieso schwer möglich ist. Dann lieber Iterationen.

Serie: Zeitgemäße Softwarearchitektur

Teil 1: Beschränkte Mittel
Teil 2: Förderung von und Umgang mit Überraschungen

In Softwareprojekten geht es mir ähnlich. Kein einziges Projekt, in dem ich bisher tätig war, hat exakt gearbeitet. Keines war 100 Prozent sauber an einer Entwicklungsmethode ausgerichtet. Großartige Architekturlösungen gab es nur auf dem Papier und in der Theorie – in der Realität gab es nur größere und kleinere Baustellen. Für Perfektion fehlen immer Tools, Mitarbeiter, Know-how, Budget oder Zeit. Wir müssen damit leben.
Die große Aufgabe von Softwarearchitektur ist grob gesprochen „das Vermeiden schwerwiegender technischer Fehler“ (manchmal auch positiv ausgedrückt: projektgefährdende, schwer zurückzunehmende technische Fragestellungen richtig beantworten). Es ist fatal zu glauben, wir könnten diese Aufgabe bewältigen, indem wir gut planen und analysieren. Dafür sind unsere heutigen Projekte zu komplex und zu wenig schablonenhaft. Leute aus der Praxis werden es bestätigen: Die wichtigste Fähigkeit im Architekturbereich ist der Umgang mit beschränkten Mitteln und Überraschungen.

Was bedeutet das genau?

Beschränkte Mittel, wie Geld, Zeit oder Kollegen, bedeuten unter anderem, dass wir fokussieren müssen. Unsere Architekturaufwände sollten sich auf die wirklich wichtigen Fragestellungen beschränken, dem Problem angemessen sein. Außerdem müssen wir technische Kompromisse informiert eingehen: Wir nehmen nicht überall die theoretisch beste Lösung, sondern eine funktionierende – dafür müssen wir unsere Rahmenbedingungen kennen und Lösungsalternativen belastbar bewerten können.
Mit Überraschungen erfolgreich umzugehen, bedeutet auch, diese Überraschungen möglichst früh im Projekt zu fördern. Immerhin sind sie dort noch besser (und billiger) handhabbar. Also: Zug zur Umsetzung ist hilfreich. Es hilft auch, wenn Architekturarbeit das „Potenzial zur Überraschung“ explizit als Priorisierungsgröße annimmt – also risikoreiche Architekturanforderungen identifiziert und früher zur Umsetzung führt. Außerdem sollten explizite Konzepte her, um Überraschungen und Probleme einzuordnen und zu bearbeiten.
Tabelle 1 zeigt diese Punkte noch einmal aufgelistet und benennt Konzepte, die in Projekten helfen. Im weiteren Verlauf dieser Artikelserie werde ich diese Konzepte der Reihe nach aufgreifen und beschreiben. Den Anfang machen diesmal die Fokussierung von Architekturaufwand und die Bewertung von Lösungsalternativen. Teil 2 wird auf frühe Überraschungen, priorisierte Architekturanforderungen und den Umgang mit technischen Schulden in der Architekturarbeit eingehen.

Tabelle 1: Aufgaben zeitgemäßer, realistischer Softwarearchitektur

Fokussierung von Architekturaufwand

Eine Architektur entsteht in jedem Softwareprojekt. Automatisch. Sie müssen dafür nichts tun außer zu implementieren. Der Architekturaufwand wäre 0, die Lösung unter Umständen sogar brauchbar. Es gibt jedoch viele Projektkontexte, in denen Sie so scheitern würden, wichtige Qualitätsziele nicht erreichen, oder das Projekt auf Dauer arbeitsunfähig machen würden. Werden Sie sich klar darüber, welche Themen Sie in dieser Hinsicht bedrohen, und kümmern Sie sich vorrangig um diese. Lassen Sie alles andere weg, und Sie erhalten eine perfekte Mischung aus Architekturaufwand und Entwicklungsgeschwindigkeit. Natürlich ist es in der Praxis illusorisch, den Punkt genau zu treffen, aber das Denkkonzept kann helfen.

Das allgemeine Denkkonzept

Stellen Sie sich ein Produktentwicklungsprojekt vor, das auf einem bekannten Technologiestack aufsetzt. Es gibt ein passendes, unternehmensspezifisches Applikationsframework, das einzige Umsetzungsteam hat bereits ähnliche Projekte durchgeführt und kennt die Domäne. Der Projektplan ist realistisch und der Aufwand überschaubar. Dieses Projekt kommt wohl mit weniger Architekturaufwänden aus, als ein großes Projekt für die Umsetzung einer neuartigen Flugsicherungssoftware. Im ersten Projekt ergeben sich wahrscheinlich weniger risikoreiche Fragestellungen. Das Umfeld ist weniger komplex, das zu lösende Problem und der Lösungsweg sind recht gut verstanden. In Projekt zwei sind einige Komplexitätstreiber zu finden – Architekturarbeit wird spannender. Abbildung 1 zeigt, wie sich Architekturaufwände und Komplexitätstreiber die Waage halten sollten. Arbeit an der Softwarearchitektur hat das Ziel, gute Entscheidungen zum richtigen Zeitpunkt zu treffen und das Risiko einer falschen Entscheidung zu minimieren. Zu hohe Aufwände machen Projekte schwerfällig, langsam und aufwändiger als nötig. Erstellen Sie etwa einen Prototypen für eine einfach umzusetzende Anforderung, verzögern Sie die Umsetzung und die damit verbundene Rückmeldung. Ihr Aufwand hat zudem wenig bis keinen Nutzen. Solche „Irrwege“ behindern vor allem in weniger komplexen, dynamischen Projekten und machen sie starrer als nötig. Ganz nebenbei wird Ihnen in den meisten Projekten die vergeudete Zeit bei anderen wichtigen Fragestellungen fehlen.
Auf der anderen Seite führt zu wenig Arbeit an der Softwarearchitektur zu zufälliger Architektur und potenziell zur Verfehlung wichtiger Projektziele. In architektonisch risikoreichen Projekten muss folglich ausreichend fundierte Architekturarbeit geleistet werden. Wichtig ist die richtige Balance, die sich für jedes Projekt anders gestaltet.

Abb. 1: Das richtige Maß für Softwarearchitekturarbeit

Aufmacherbild: The tops of skyscrapers against the sky von Shutterstock / Urheberrecht: pzAxe

[ header = Seite 2: Konkrete Fragestellungen einschätzen ]

Konkrete Fragestellungen einschätzen

Es ist das Eine, einzuschätzen, wie viel Architekturaufwand Ihr Projekt allgemein verdient. Es ist etwas anderes, herauszufinden, wo genau diese Aufwände hinfließen sollten. Wie erkennen Sie an konkreten Fragestellungen, ob Architekturarbeit notwendig ist? Eine Lösung: Lassen Sie sich von den folgenden Fragen leiten (angelehnt an):

• Ist die Entscheidung der Fragestellung später nur schwer zu ändern?
• Ist die Umsetzung der Entscheidung eher teuer?
• Werden sehr hohe, qualitative Anforderungen gestellt (Hochsicherheit, Hochverfügbarkeit, Hochperformanz etc.)?
• Lassen sich die Anforderungen oder Lösungsalternativen nur schwer in Bestehendem abbilden (Istarchitektur, Rahmenbedingungen)?
• Ist die eigene Erfahrung im Lösungsspektrum schwach?

Die Fragen sind weder überschneidungsfrei noch messerscharf formuliert, sie sind aber für sehr unterschiedliche Rahmenbedingungen und Projektumgebungen funktionsfähig. „Schwer änderbar“ beinhaltet einmal mehr, einmal weniger Fragestellungen und was für manche Projekte „teuer“ wäre, ist für andere ein Klacks. Auch die beiden letzten Fragen, die eher Richtung Wissen, Erfahrung und Lösungsidee zielen, setzen keinen bestimmten Rahmen voraus.
Beantworten Sie die Fragen mehrheitlich mit „ja“, haben Sie vermutlich eine architektonisch risikoreiche Fragestellung an der Hand. Gerade die erste Frage ist recht aussagekräftig: Später schwer zu ändernde Entscheidungen betreffen viele Projektmitglieder, haben externe Abhängigkeiten oder beinhalten hohen finanziellen Einsatz. Häufig basieren solche Fragestellungen auf qualitativen Anforderungen, die querschnittlich wirken. Haben Sie eine Fragestellung oder Entscheidung als architekturrelevant erkannt, lohnt sich der Einsatz architektonischer Mittel, um das Risiko einer Fehlentscheidung zu minimieren. Dazu gehören etwa die genauere Analyse nicht funktionaler Anforderungen, die Konzeption und ggf. Modellierung möglicher Lösungen, die Definition von Prinzipien, die Erstellung von Durchstichen und Prototypen oder die breite Vermittlung und Etablierung von Entscheidungen. Andere Fragestellungen können während der Implementierung und im Zusammenspiel mit Test und Auslieferung effizienter beantwortet werden. Typische Kandidaten hierfür sind das genaue Klassendesign, interne Schnittstellen oder Implementierungsalternativen. Rückschläge auf dieser Ebene bedrohen Sie bei beschränkten Mitteln jedoch meist weniger als die eben identifizierten architekturrelevanten Fragestellungen.

Lösungsalternativen bewerten

Abbildung 2 zeigt das „Qualitätsdreieck“ mit einigen wichtigen Attributen der Softwareentwicklung. Sie kennen es wahrscheinlich, trotzdem möchte ich einige Aspekte herausgreifen. Die grundsätzliche Idee des Dreiecks: Es gibt in jedem Projekt einen Kompromiss zwischen hoher Qualität, niedrigen Kosten und Time-to-Market zu lösen. Das Beste, was Sie typischerweise erreichen können, sind zwei dieser drei Eigenschaften (siehe dazu folgendes Buch). Wollen Sie schnell zu einer qualitativ hochwertigen Lösung kommen, müssen Sie viel Geld investieren (etwa viele gute Leute bezahlen, Lösungen zukaufen oder Standardlösungen von Spezialisten anpassen lassen). Wollen Sie eine billige und schnelle Lösung, ist allumfassende Qualität unerreichbar. Machen Sie sich auf jeden Fall bewusst, in welchem konkreten Spannungsfeld sich Ihr Projekt befindet. Ist der Zielkorridor größer, sind Architekturentscheidungen weniger risikoreich und selbst eine „zufällige Architektur“ vielleicht tragfähig. Je enger das Korsett, desto problematischer sind falsch getroffene, grundlegende Technologieentscheidungen. Bewertungsansätze für Ihre Entscheidungen werden wichtiger. Sie schaffen Sicherheit und machen große Rückschläge unwahrscheinlicher. Dabei sollten die Bewertungsaktivitäten Ihre Architekturentscheidungen von zwei Seiten betrachten: Von der Anforderungs(-architekturbewertung) und von der Implementierungsseite (Umsetzungsabgleich).

Abb. 2: Das Qualitätsdreieck mit Beispielen

Architekturbewertung bzw. Reflexion

Die klassische Architekturbewertung (etwa nach ATAM – der Architecture Tradeoff Analysis Method) betrachtet getroffene Entscheidungen und Lösungsvorschläge vor dem Hintergrund qualitativer Anforderungen. Sie nutzt die kollektive Erfahrung der Entwicklungsmannschaft, um Risiken früh zu identifizieren und macht Architekturkompromisse für Stakeholder verständlich. Zentral ist dabei das Konzept von Qualitätsszenarien, das zur genauen Beschreibung von Qualitätsanforderungen und als Bewertungsmaßstab dient (Abb. 3).

Abb. 3: Qualitätsszenarien – Aufbau und generisches Beispiel

Szenarien sind Beispiele für Qualitätsanforderungen und bilden damit eine Basis, auf der sich Entwicklungs- und Kundenseite unterhalten können. Kompromisse zu einschränkenden Rahmenbedingungen können offensichtlich gemacht werden und ganz nebenbei erhalten Entwickler brauchbarere Anforderungen als „Performanz ist wichtig“.
Bereits leichtgewichtige Ausprägungen von fundierten Architekturbewertungsverfahren zeigen sehr positive Effekte. Die grundsätzlichen Fragen sind:

• Was wollten wir in den vergangenen Iterationen umsetzen?
• Welche zentralen Entscheidungen wurden deshalb getroffen?
• Wie wurde das Bild der Gesamtarchitektur verändert?

Abb. 4: Architekturbewertungsworkshops (Reflexion) im Überblick

Abbildung 4 illustriert die Idee etwas detaillierter. Ein Bewertungsworkshop durchwandert das Bild  von oben nach unten. Inputs sind Artefakte und Ideen aus der Architekturarbeit (links) und Anforderungen bzw. Einflüsse (rechts). Als Teilnehmer kommen Entwickler, die Architekturarbeit geleistet haben, teamfremde Entwickler, Architektur- und Betriebsexperten sowie andere wichtige Stakeholder, wie Kunden, in Frage. Der Teilnehmerkreis kann und sollte in größeren Projekten immer wieder durchmischt werden.
Im Workshop wird zunächst ein kurzer Blick auf die Architektur als Ganzes geworfen, bevor der Blick auf die Anforderungsseite und dort vor allem zu Szenarien schwenkt. Beginnend mit dem höchstpriorisierten Szenario startet eine Durchsprache, in der die Architekturansätze und Entscheidungen vorgestellt und reflektiert werden, die von dem Szenario berührt werden. Tabelle 2 zeigt einige Beispielfragen.

Bewertungsfrage Zweck
Wie wurde das Szenario umgesetzt? Liefert relevante Entscheidungen und Ansätze
Sind die vorgestellten Entscheidungen nachvollziehbar und ist der Zusammenhang mit dem Szenario klar? Überprüft die Verständlichkeit und den Fokus der Architekturentscheidung
Sind alle Aspekte des Szenarios abgedeckt? Liefert weitere Entscheidungen, offene Punkte oder Risiken
Welche Ansätze oder Entscheidungen behindern die Erreichung des Szenarios? Die Szenarien hinter diesen Entscheidungen stehen im Kompromiss zu dem besprochenen Szenario
Werden wichtige Qualitätsmerkmale oder zentrale Szenarien von den vorgestellten Entscheidungen negativ beeinflusst? Liefert Kompromisse des aktuellen Szenarios zu anderen Szenarien und Qualitätsmerkmalen; potenziell auch Risiken
Welche Schwierigkeiten könnten bei der Umsetzung, bei der Auslieferung oder im Betrieb auftauchen? Überprüft die Umsetzbarkeit und liefert Risiken und offene Punkte
Sind wichtige Rahmenbedingungen verletzt? Überprüft die Machbarkeit und liefert Risiken

Tabelle 2: Beispielfragen in Bewertungsworkshops

Die Reflexion zur geleisteten Arbeit und den eventuellen Seiteneffekten ist der Kern dieser Praktik. Hier werden wichtige Outputs des Workshops generiert: Risiken, die bei den Entscheidungen entdeckt wurden, Kompromisse zwischen Szenarien, Nichtrisiken (aufgebrachte, aber entkräftete Risiken) und To-dos. Zentrale Ziele sind die Fokussierung von Kommunikation und Architekturarbeit auf die wirklich wichtigen Aspekte des Vorhabens, die Absicherung zentraler Entscheidungen und die Transparenz von Architekturarbeit bis hin zu den fachlichen Stakeholdern des Projekts.

[ header = Seite 3: Umsetzungsabgleich ]

Umsetzungsabgleich

Tests, Messungen und Metriken sind erst mit entwickeltem Programmcode nutzbar, geben allerdings „echtes Feedback“ darüber, was funktioniert und was nicht. Sie sollten versuchen, möglichst schnell auch diese Rückmeldung zu Architekturentscheidungen zu bekommen. Qualitätsmerkmale wie Zuverlässigkeit, Skalierbarkeit oder Sicherheit wirken langfristig und sind erst wirklich spürbar, wenn das System in Betrieb ist. Bis dahin mit Vermutungen zu arbeiten, ist gefährlich und oft auch teuer. Erst mit der Umsetzung im Programmcode haben Sie das zu lösende Problem annähernd vollständig vor Augen: Sie erkennen, wie kompliziert einfache Konzepte werden, welche Daten benötigt werden und wie Ihre Lösungen mit anderen Konzepten Ihrer Software zusammenwirken. Haben Sie wichtige Teile umgesetzt, können Sie mit Tests auch eine erste Idee vom Laufzeitverhalten bekommen.
Die Rückmeldung aus der Implementierung, samt den Erkenntnissen aus Integration und Test erden Architekturentscheidungen und minimieren den Raum für Annahmen und Spekulationen. Tests und automatisiert ausgewertete Metriken stellen außerdem sicher, dass zukünftige Entscheidungen und Implementierungen die erreichte Qualität der Software nicht wieder (deutlich) verschlechtern. Das verspricht weniger Rückschläge im Entwicklungsprozess und macht zeitliche bzw. budgetäre Beschränkungen einfacher erfüllbar.

Architekturtests

Architekturtests stellen eine Herausforderung dar: Anforderungen zu Qualitätseigenschaften sind oft zu grob und lückenhaft, um effektiv Testfälle ableiten zu können – hier helfen jedoch meist Szenarien. Viel problematischer ist die Schwierigkeit, Tests zu Qualitätseigenschaften zu automatisieren. Ohne Automatisierung ist keine günstige Wiederholbarkeit der Tests gegeben und Regressionstests werden teuer.
Bei der Automatisierung von Tests zu qualitativen Eigenschaften des Systems, kann nicht einfach eine Methode mit definierten Ein- und Ausgabeparametern getestet werden. Es sind meist weite Systemteile betroffen, das System muss oft zumindest in Teilen lauffähig sein, Fehlerfälle müssen simuliert werden und einige Tests sind langlaufend. Ein Technologiemix in der Codebasis (etwa mit Java, anderen JVM-Sprachen, XML, geskripteten Inhalten und verschiedenen Applikationsframeworks) ist problematisch. Darüber hinaus sind bestimmte Eigenschaften nur durch Meinungen oder mit Kreativität zu testen – beides ist schwer automatisierbar. Testwerkzeuge werden jedoch immer mächtiger und einige Trends der 2000er-Jahre haben einen guten Rahmen geschaffen, um qualitative Eigenschaften von Systemen zu testen. Relevante Qualitätsaspekte finden sich mindestens in den folgenden Testkategorien:

Integrationstests: Hier interagieren mehrere Komponenten des Systems miteinander, inklusive externer Abhängigkeiten wie Datenbank, Clients, Middleware oder fremder Server. Auch wenn Integrationstests eher funktional ausgerichtet sind, können einige Qualitätsaspekte wie Austauschbarkeit, Konformität, Interoperabilität und Fehlertoleranz getestet werden. Die Werkzeuge hierfür wären typischerweise die xUnit-Familie oder TestNG.
• Bei Akzeptanztests werden Anforderungen in einer Form festgehalten, die automatisierte Tests direkt ermöglicht. Die Anwendung wird teilweise durch das UI angesprochen und als Blackbox behandelt. Auch wenn die Frameworks für Akzeptanztests eher funktionalen Fokus haben, können sie als Rahmen für Tests von qualitativen Aspekten Ihres Systems verwendet werden. Die Stichworte hier wären ATDD (Acceptance Test-driven Development), BDD (Behaviour-driven Development) oder AAT (Agile Acceptance Testing).
Nicht funktionale Tests sind die eigentliche Heimat für Architekturtests. Die bekanntesten Tests betreffen hier Performanztests für Durchsatz, Reaktionszeiten oder Latenz. Daneben gibt es Lasttests, unter anderem für Skalierbarkeit, sowie Tests für Zuverlässigkeit- und Sicherheitsaspekte. Meist kommen in diesem Bereich spezialisierte Testtools und Testsuiten zum Einsatz.

Die drei genannten Testarten benötigen in der Ausführung typischerweise unterschiedlich lang, weshalb sie bei der Automatisierung nicht in einen Topf geworfen werden sollten. Die Integration und Auslieferung der Software wird deshalb oft in so genannte „Stages“ aufgeteilt, die mehrere Testphasen beinhaltet und Ergebnisse so schnell wie möglich an die Entwicklung zurückmeldet.

Metriken

Für bestimmte Qualitätsaspekte ist eine direkte Prüfung durch manuelle oder automatisierte Tests schwierig. Beispielsweise wenn der Aspekt bei der Programmausführung gar nicht spürbar ist – bei der so genannten inneren Qualität ist das der Fall. Sie beinhaltet Qualitätseigenschaften, wie die Änderbarkeit Ihrer Software und, damit zusammenhängend, Themen wie Erweiterbarkeit, Wiederverwendbarkeit, Prüfbarkeit (Testbarkeit) oder Verständlichkeit. Diese Qualitätsmerkmale sind zur Entwicklungszeit spürbar und haben Auswirkungen auf die Produktivität bei der (Weiter-)Entwicklung von Software. In weiterer Folge sind auch Time-to-Market einzelner Features und die Lebensdauer des Systems betroffen. Wegen der schlechten direkten Messbarkeit müssen Sie zur objektiven Prüfung dieser Aspekte auf Qualitätsindikatoren bzw. Metriken zurückgreifen. Für den richtigen Umgang mit Metriken gibt es seit den 1980er-Jahren Modelle und Prozesse. Die pragmatische Essenz daraus lässt sich in drei Schritten beschreiben:

1. Definieren Sie die Ziele, die Sie im Bereich der inneren Qualität haben.
2. Wählen Sie passende Indikatoren für diese Ziele aus.
3. Legen Sie die Aus- und Verwertung der Ergebnisse fest.

Diese drei Aufgaben sind durchaus architekturrelevant, da Ziele in puncto Änderbarkeit meist ganze Systemteile oder das Gesamtsystem betreffen, die entsprechenden Indikatoren allen Entwicklern bekannt sein sollten und die Auswertung transparent und stabil erfolgen muss. Sie schaffen mit Qualitätsindikatoren einen Rahmen für Design- und Entwicklungstätigkeiten, der die Wichtigkeit innerer Qualität in Ihrem System widerspiegelt und eine gemeinsame Richtung gibt.
In vielen Projekten wird auf die ersten beiden der obigen Schritte (Ziele definieren und Indikatoren auswählen) verzichtet. Es werden einfach Standardmetriken aus Werkzeugen übernommen und orange und rote Werte bestraft. Das ist aus mehreren Gründen problematisch:

• Die Verwendung von zu vielen Metriken macht die Auswertung schwieriger und die Ergebnisse schwerer nachvollziehbar.
• Ohne Auswahl konkreter Metriken bleibt der Blick oft bei zusammenfassenden „Metametriken“ hängen. Die sind häufig so kompliziert zusammengesetzt, dass eine sinnvolle Reaktion auf schlechte Metrikwerte schwierig ist.
• Standardeinstellungen zu Regeln und Grenzwerte müssen nicht zu Ihrem Projekt und Ihren Qualitätsansprüchen passen. Generell ist das sogar eher unwahrscheinlich.
• Metriken als Zielvorgabe zu verstehen, ist problematisch, weil Metriken meistens gefälscht, oder positiver ausgedrückt, optimiert werden können, ohne die tatsächliche Codequalität zu steigern.

Der letzte Punkt gilt nicht für alle Metriken. Die meisten sind jedoch so genannte Frühindikatoren, weisen also auf potenzielle Probleme hin, bevor sie direkt messbar sind. Komplexität, Abhängigkeiten, Klassen- oder Paketgröße, Kohäsion oder Testabdeckung können darauf hinweisen, dass Ihr Code in der Wartung und Weiterentwicklung fehleranfällig ist. Sicher sagt das aber nur ein Spätindikator (z. B. die Bugdichte). Mit Frühindikatoren bekommen Sie ein Werkzeug an die Hand, das früheres Gegensteuern ermöglicht und für Architekturzwecke sehr interessant ist – seien Sie sich jedoch bewusst, dass Sie kein perfektes Maß auswählen. Sie können mit Tests 100 Prozent Codeabdeckung erreichen, ohne ein einziges sinnvolles assert-Statement zu schreiben.
Metriktools wie Sonar, Structure101, SonarGraph oder das Eclipse-Metrics-Plug-in können Metrikergebnisse aufbereiten und „reporten“. Oft geht jedoch mehr: Sie können Reports anpassen, eigene Regeln hinterlegen, Warnungen konfigurieren oder auch in den Build eingreifen. Nutzen Sie diese Möglichkeiten! Sie erhalten so schnelles, stetiges Feedback von Codeseite und können architekturelle Änderungen in ihren Auswirkungen verfolgen. Sie sehen etwa effektiv, welche Qualitätseinbußen Sie aufgrund von Performanzoptimierungen hinnehmen müssen und können die entsprechenden Entscheidungen rasch in Frage stellen, falls die Auswirkungen größer sind als vermutet.

Mehr zum Thema

Dieser Artikel basiert auf Stefan Toths Buch „Vorgehensmuster für Softwarearchitektur“, das im Carl Hanser Verlag erschienen ist. Eine Rezension des Buches finden Sie hier auf JAXenter.

Fazit

Im vorliegenden Teil 1 dieser Artikelserie habe ich Praktiken vorgestellt, die beim Umgang mit begrenztem Geld- oder Zeitbudget auf Architekturseite wichtig sind. Die zwei größten Aufgaben sind dabei die Konzentration von Aufwänden (auf wirklich wichtige, weitreichende Entscheidungen) und die Vermeidung von (langen) Irrwegen. Diese Irrwege aufzudecken, ist ein mehrstufiger Prozess. Er beinhaltet leichtgewichtige Architekturbewertungspraktiken, aber auch die Verwendung von Tests und Metriken. So bekommen Sie echtes Feedback und können schneller reagieren bzw. korrigieren.
In Teil 2 der Serie kümmere ich mich um den zweiten großen Aspekt zeitgemäßer Architekturarbeit: Die Förderung von und den Umgang mit Überraschungen.

Geschrieben von
Stefan Toth
Stefan Toth
Stefan Toth arbeitet als Entwickler, Softwarearchitekt und Berater bei der embarc GmbH. Seine Schwerpunkte liegen in der Konzeption und der Bewertung mittlerer bis großer Softwarelösungen sowie der Verbindung dieser Themen zu agilen Vorgehen. Er ist Autor zahlreicher Artikel und des Buchs "Vorgehensmuster für Softwarearchitektur". Kontakt: st@embarc.de
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: