Gerade in größeren Projekten mit mehreren Entwicklern ist es enorm wichtig, den Code so zu strukturieren, dass sich jeder zurechtfindet und klar ist, welche Konventionen gelten. Damit es nicht nur bei Lippenbekenntnissen bleibt, sollten auch diese architekturrelevanten Konventionen automatisiert festgehalten werden. Dieser Beitrag zeigt, dass das genauso einfach sein kann, wie einen simplen JUnit-Tests zu schreiben.

Aber wir haben doch Sonargraph…

Eines der bekanntesten Werkzeuge zur statischen Code- und Architekturanalyse ist Sonargraph-Architect. In diesem mächtigen Werkzeug lassen sich auf Package und Klassen-Ebene Regeln festhalten – sei es beispielsweise die Definition von Schichten oder welche Abhängigkeiten erlaubt sind. Auch die Konventionen bezüglich der Benennung oder anderer Eigenschaften, wie Annotationen und Ableitungshierarchie, lassen sich festhalten. All das wird in dem Werkzeug als DSL oder über die Oberfläche erfasst und kann dann auf ein System automatisiert angewendet werden. Es ist damit sogar möglich, virtuelle Refactorings durchzuführen und diese als Tasks an die Entwickler zu geben.

Sonargraph-Architect ist also ein separates Werkzeug und steht neben dem Code, auf den es angewendet werden soll. Es ist hochspezialisiert auf seinem Gebiet und dementsprechend kostenpflichtig. Das führt normalerweise dazu, dass es auch nur von spezialisierten Rollen meist in Form des oder der Architekten genutzt wird.

Keep it simple!

Das genaue Gegenteil stellt die Open Source-Bibliothek ArchUnit dar. Es hat weniger Features, ist dafür aber deutlich einfacher zugänglich. Mit ArchUnit kann die Architektur von Java-Projekten mittels JUnit-Tests definiert und überprüft werden.

Durch die Fluent-API lassen sich die Regeln einfach erstellen und lesen. Hier in dem Beispiel wird erzwungen, dass alle Klassen im service-Package mit der Annotation MyService versehen sein müssen und der Name mit Service beginnt. So einfach lässt sich festhalten, wie Services abzulegen und zu erkennen sein sollten. Mit ArchUnit lassen sich aber auch komplizierte Regeln darstellen. Der große Vorteil ist, dass zur Erstellung der Regeln kein besonderes, spezielles Know-how gebraucht wird. Damit ist es nicht erforderlich, dass nur der Architekt an diesen Regeln arbeitet. Alle Entwickler sind in der Lage, diskutierte und beschlossene Konventionen selbst festzuhalten. Damit wird für die Entwickler unmittelbar spürbar, welchen Effekt und Nutzen solche Regeln haben. Dem Architekten (sofern die Rolle explizit ausgeprägt ist) bleibt die Aufgabe des Coaches, welcher dem Team hilft, solche Regeln selbst festzuhalten.

Der frühe Vogel…

Wenn man diese Art Tests früh im Projekt aufsetzt, ist es am einfachsten, darüber gewisse Aspekte der Architektur zu steuern und zu kontrollieren. Aber ArchUnit kann außerdem dabei helfen, bestehende Software systematisch zu verbessern und neu zu strukturieren. Allerdings kennen JUnit-Tests natürlich nur schwarz-weiß, entweder der Code erfüllt die Regeln oder eben nicht. Was mache ich also mit den unweigerlichen Verletzungen in meiner Legacy-Software? Es ist unwahrscheinlich, dass diese on-the-fly gleich beseitigt werden können.

ArchUnit lässt sich zu diesem Zweck feingranular steuern und einsetzen. Zum einen können gewisse Regeln nur für Teile der Anwendung gelten. Es können beispielsweise Packages gefiltert werden und verschiedene Test-Sets können zusätzlich in den einzelnen Komponenten und Modulen verteilt sein. Zum anderen bietet ArchUnit über die Fluent-API die Möglichkeit, Ausnahmen zu definieren. Dies ist aber mit Vorsicht zu genießen. Das Ziel muss es sein, nur solche Regeln zu etablieren, die wirklich auch konsequent verfolgt werden können. Ansonsten landet man bei einem komplizierten Regelwerk voller Ausnahmen. Dann folgen die Regeln dem Code und nicht mehr umgekehrt. Es sollte daher für neue Regeln abgeschätzt werden, ob der nötige Refactoring-Bedarf auch zeitnah geleistet werden kann.

Einfach starten

Ihr seht, die Hürden sind gering. Egal ob Neuentwicklung oder Legacy-Software – es gibt keine Ausreden. Abhängigkeiten in Gradle oder Maven pflegen und los geht’s. Viel einfacher lässt sich Architektur im Kleinen nicht managen.

Nutzt ihr ArchUnit schon? Mich interessiert euer Feedback. Kontaktiert mich gerne bei LinkedIn, Anregungen und Fragen sind herzlich willkommen.