Innere Werte, Teil 7: ArchitekturgerĂĽche
Jeder kennt die sogenannten Code Smells, unangenehme GerĂĽche, die bei erkranktem Code auftreten. Aber auch Softwarearchitekten kennen Smells. Architecture Smells weisen auf Infektionsherde im Entwurf hin.
- Dr. Michael Stal
Jeder kennt die sogenannten Code Smells, unangenehme GerĂĽche, die bei erkranktem Code auftreten. Aber auch Softwarearchitekten kennen Smells. Architecture Smells weisen auf Infektionsherde im Entwurf hin.
Man nehme ein Architekturanalysewerkzeug und analysiere die eigene Architektur. Das erste, was Architekten dann häufig zu Gesicht bekommen, sind Abhängigkeitszyklen. Die sind deshalb schlecht, weil beim Testen einer Komponente im Zyklus immer alle anderen Komponenten im gleichen Zyklus zu berücksichtigen sind. Das Gleiche gilt natürlich auch für Änderungen.
Halten wir fest: Abhängigkeitszyklus => schlechtes Design!
Oder betrachten wir unnötige Abstraktionsebenen, die man besser wegoptimieren sollte. In einer Software für Warenlager wurde zum Beispiel neben der Abstraktion für Warenspeicherung namens AbstractStorage (mit Methoden für Hinzufügen und Entfernen von Waren) auch eine weitere für den Transport von Waren bereitgestellt. Nach intensiverer Retrospektive fällte das Team die Entscheidung, die zusätzliche Abstraktion AbstractTransportation wieder zu eliminieren. Schließlich lassen sich Fließbänder oder ein Transportwagen auch als AbstractStorage interpretieren.
Auch hier gilt: unnötige Abstraktion => schlechtes Design dank selbstinduzierter Komplexität!
GegenmaĂźnahmen einleiten
Wenn wir also gewisse Smells in der Architektur bemerken, sollten wir die Architektur mit passenden Gegenmitteln behandeln. Diese Smells betreffen die interne Qualität der Architektur. Soll eine Architektur Nachhaltigkeit aufweisen, müssen Architekten solche Architecture Smells frühzeitig erkennen und beseitigen. Ansonsten ist ein frühes Verfallsdatum des Systems vorprogrammiert.
Bekannte GerĂĽche
Auch Konzepte aus der Informatik wie Kohäsion, Kopplung, Fan-in/Fan-out erweisen sich als wichtige Indikatoren bzw. Smells für Architekturprobleme.
Potenzielle Smells kennen erfahrene Softwarearchitekten aus ihrer langjährigen Praxis. Und teilweise lassen sich Code Smells auch als Architecture Smells einsetzen. Etwa bei der Integration von Subklassenmethoden in Elternklassen oder der Extraktion einer Schnittstelle. Weitere Smells findet man auch in den Weiten des Internets.
Beispiele:
- Dupliziertes Design
- Globaler Zustand
- XXL-Schnittstellen, Klassen, Methoden
- Unklare Verantwortlichkeiten
- Unverständliche Architektur(-teile)
- Fokus auf Zentralisierung, etwa Hub & Spoke
- Verwendung eigener Lösungen statt bewährter Best Practices
- Sehr generischer Entwurf
- Asymmetrien
- Anhängigkeitszykeln
- Unnötige Abhängigkeiten
- Implizite Bestandteile
- Schlechte Aufteilung der Funktionalität
- Ignorieren von Entwurfsvorgaben, etwa bei Layers
- Fehlende konzeptionelle Integrität
- Leere Catch-Blöcke
- Nutzung von Checked Exceptions in Java
Einige dieser Problemzonen lassen sich durch Metriken bzw. Visualisierungswerkzeuge aufspĂĽren. Andere entdeckt man ĂĽber Design Reviews.
Vorbeugen ist besser als Heilen
Für den Gesundheitscheck gibt es, wie eingangs erwähnt, Architekturwerkzeuge. Aber auch anhand der Architekturmodelle lassen sich schon erste Diagnosen gewinnen. Um bei der Gesundheitsmetapher zu bleiben: Vorbeugen ist besser als Heilen.
Jetzt haben wir zwar die potenziellen Probleme aufgespürt. Wie aber können wir sie eliminieren? In einem meiner zukünftigen Postings werde ich architektonisches Refactoring thematisieren. ()
