treffen und zu dokumentieren ist aufwändig und mühsam, mit der Folge, dass Entscheidungen oft nur implizit getroffen werden und dann in Vergessenheit geraten, geschweige denn im Lauf der ständigen Weiterentwicklung eingehalten werden. Architecture Fitness Functions dienen dazu, Architekturentscheidungen im besten Fall automatisiert zu überprüfen. So bekommt das Entwicklungsteam jederzeit Feedback, ob die Architektur noch den festgelegten Regeln entspricht. Manche Entscheidungen wie Namenskonventionen lassen sich schon lange über altbekannte Tools wie Checkstyle abtesten. Komplexere Entscheidungen aber lassen sich nicht immer einfach prüfen – oder sie erfordern ein komplexes Metamodell, das aufwändig zu erstellen und zu pflegen ist. Hier kommt ArchUnit ins Spiel. In unserem Talk stellen wir anhand konkreter Fragestellungen vor, wie man mit ArchUnit automatisiert Architekturentscheidungen überprüft und in einen Standard-Testzyklus einbindet. Dazu bringt ArchUnit von Haus aus eine ganze Reihe von Standard- Hilfsmitteln mit. Besser noch: Eigene Architekturregeln lassen sich leicht in Form von Tests definieren und so im automatisierten Build überprüfen. Zugleich sind die Architekturregeln über die Tests dokumentiert. Beispiele: Sind Abhängigkeiten zwischen Komponenten richtig definiert? Sind Strukturen innerhalb einer Komponente richtig modelliert, z.B. als Onion-Architektur? Dieselbe API von ArchUnit kann man aber auch für statische Codeanalyse einsetzen, deren Output nicht in einem Test, sondern als Input in weitere Tools eingeht. Damit lassen sich einfach kleine Helferlein schreiben, um gezielt über statische Code-Analyse Handlungsbedarf identifizieren und analysieren zu können. ArchUnit lässt sich demnach für kleine, mittlere und komplexe Fragestellungen einsetzen. Das skaliert gut und ermöglicht eine leichtgewichtige und automatisierte Absicherung von Architekturentscheidungen. Wir zeigen zahlreiche Beispiele direkt im Code und geben damit einen ausführlichen Überblick über die Benutzung der ArchUnit-API. Abstract https://www.oop-konferenz.de/oop-2024/programm/konferenzprogramm
Schaal ist als Softwarearchitektin bei der Accso - Accelerated Solutions GmbH tätig. Sie arbeitet seit mehr als 20 Jahren in der Softwareentwicklung und ist in Projekten der Individualentwicklung für Kunden verschiedener Branchen unterwegs, technisch überwiegend im Java-Umfeld. [email protected]
An architecture fitness function is any mechanism that provides an objective integrity assessment of some architectural characteristic(s) Neil Ford et al. “Building Evolutionary Architectures” 2nd Edition Name „Fitness Function“ kommt aus dem Gebiet der Genetischen Algorithmen (zur Lösung von Optimierungproblemen, z.B. „Travelling Salesman“). Fitness Functions sichern ab, dass Anforderungen an die Architektur eingehalten werden und die Architektur nicht „degeneriert“. analog Domänen-Tests zum Test der fachlichen Korrektheit einer Anwendung. Funktion := Messen, „wie gut eine Anforderung erfüllt wird“.
der Architektur Über Qualitätsanforderungen finden wir die relevanten Architektur- Charakteristika zur Vermessung. Im besten Fall automatisiert. Scope: „Atomic“: Bewertung eines Charakteristikums „Holistic“: Mehrere Charakteristika in Kombination Benutzer- freundlichkeit Performance Security Verfügbarkeit … Energieeffizienz Execution Qualities (statische) Code-Architektur Wartbarkeit Evolution Qualities … Benutzer- freundlichkeit …
Architektur-Tests? Schnelles Feedback für alle Entwickler:innen automatisiert und/statt (nur) Code-Reviews läuft einfach in jedem Build mit Dokumentiert Architekturentscheidungen, macht sie explizit
Architektur-Tests mit ArchUnit? Schnelles Feedback für alle Entwickler:innen automatisiert und/statt (nur) Code-Reviews läuft einfach in jedem Build mit Dokumentiert Architekturentscheidungen, macht sie explizit Programmieren statt deklarieren – Man arbeitet im gleichen Code, in der gleichen Programmiersprache (Turing-vollständig) Refactoring schließt auch die Tests ein Ausdrucksstarke und typsichere API Schnell erlernbar und einführbar, gut lesbar und wartbar damit mächtiger als Checkstyle, PMD, Findbugs, JDepend, Sonar*, Structure101, jqAssistant
man ArchUnit-Tests? Regeln schreiben Regeln prüfen einen Aspekt der Architektur. Regeln definiert man über ArchRule, bzw. spezifische Subklassen. API vereinfacht das Erstellen der Regeln. Tests ausführen ArchUnit-Tests können als JUnit4- oder JUnit5- Tests geschrieben und ausgeführt werden. Sie können im normalen Build-Zyklus mitlaufen. Wenn die Architektur- prüfung fehlschlägt, wird eine Exception geworfen → Der Test schlägt fehl. Was kann man prüfen? Package Dependency Class Dependency Class and Package Containment Inheritance Annotation Layer Cycle …
1 Check von Namenskonventionen Beispiel 2 Check von Abhängigkeiten Beispiel 3 Sind alle Daos auch JpaRepositories? Sind nur Daos JpaRepositories? https://github.com/accso/static-code-analysis-archunit
4 Zyklen? Check auf erlaubte Abhängigkeiten … zwischen den fachlichen Komponenten … auf Onion- Architektur https://github.com/accso/static-code-analysis-archunit
5 Nutzung von ArchUnit auf der „Braunen Wiese“ Ignorieren von Architekturfehlern Einfrieren von Test-Ergebnissen Einschränken auf Teilmenge von Klassen https://github.com/accso/static-code-analysis-archunit
auf statischer Codeanalyse Byte Code ArchUnit prüft Byte Code, nicht den Source Code ArchUnit baut ein statisches Abhängigkeits- modell auf. Modell ClassFileImporter scannt den Classpath. Einschränkung auf eigene Packages möglich. Mit/ohne Test JavaClass JavaClasses Dependency JavaAccess Abhängigkeiten Aus- und eingehend Vererbung, Interfaces, Generics, Annotationen ArchUnit nutzt diese Informationen: Konstruktoren Feldern Annotationen Typen
Beispiel 3 diesmal mit Fokus auf statischer Code-Analyse Beispiel 6 Finde transitive Abhängigkeiten für eine Klasse. Relevant z.B. für Migrations- planung und -schätzung https://github.com/accso/static-code-analysis-archunit
einsetzen! Leichtgewichtig einführbar Regeln per API sehr einfach zu schreiben. Refactoring möglich (außer Package-Namen als String) Filter über Importer, Ignore, Freeze Wird stetig weiterentwickelt (Beispiel: Type Erasure, Generics) Gute Basis für eigene statische Code-Analyse-Werkzeuge Strings statt Typen bei Klassen, Packages, Wildcards Ungewohnte Wildcard-Notation Semantik von Depend, Access etc. nicht immer intuitiv Architekturtests sind Tests für die (statische) Code-Architektur (nicht mehr, aber auch nicht weniger). Kann andere Tools wie Checkstyle, Sonar & Co ergänzen, in Teilen ersetzen.
ist deine Architektur? Architekturtests! Verhindert Degenerieren der (statischen) Code-Architektur. Pflege und Weiterentwicklung (mit der Architektur) mit sehr vertretbarem Aufwand möglich. „Grün oder Rot?“ Test für unmittelbares Feedback Letztlich nur zwei Mess- Ergebnisse „Wie fit?“ Messung der Anzahl von Architektur-Verletzungen evaluate() Dedizierte Betrachtung von ausgeschlossenen Prüfungen Ignore und Freeze
kristines
portentint
tammyeverts
aleyda
addyosmani
jmmastey
reverentgeek
baasie
bryan
sonatard
ianozsvald
techseoconnect
erikaheidi
