© GreenFlash/Shutterstock.com
Brückenbauer in der Open-Source-Welt – Teil 4

Architektur validieren


Schulung durch Reviews ist völlig ineffizient, doch das optimale Expertenteam hat man auch nicht immer zur Hand. Fallen grundsätzliche Mängel am Design des Codes erst in der Review auf, ist das Kind schon in den Brunnen gefallen: Der Code muss gegebenenfalls aufwendig refaktoriert werden und der gleiche Fehler wurde in der Zwischenzeit bereits mehrfach wiederholt.

Schlimmstenfalls ist das Antipattern bereits zur Vorlage für viele andere Entwickler im Team geworden. Wenn dann die Experten im Team zum Flaschenhals werden und mit den Reviews nicht nachkommen, erodiert die Architektur und es geht bergab mit der Codequalität. Wie schafft man hier Abhilfe?

Was man braucht, ist eine sofortige Codereview, doch von einer vollständigen Instantreview ist die KI noch meilenweit entfernt. Daher muss man zwischen den einfachen (Anti-)Patterns und dem manuellen Review durch einen menschlichen Experten trennen. Einfache Patterns kann man automatisch erkennen und damit kann das Feedback sehr schnell zum Entwickler gelangen – im besten Fall bereits in der IDE während der Programmierung. Die Architektur und Programmierrichtlinien in devonfw sind sehr genau definiert [1] und daher perfekt für eine automatische Validierung. Hierzu gibt es bereits ausgereifte Werkzeuge, die lediglich konfiguriert werden müssen. Jedoch sind diese fast alle kommerziell, und wenn in devonfw fast alles standardisiert ist, warum soll man dann überhaupt noch etwas konfigurieren müssen?

sonar-devon4j-plugin

Bei statischer Codeanalyse und Open Source sind wir schnell bei SonarQube, das sich in diesem Bereich etabliert hat. Daher haben wir uns auch bei devonfw entschieden, das sonar-devon4j-plugin [2] zu entwickeln, mit dem SonarQube zusätzlich die Architektur- und Programmierrichtlinien automatisch überprüfen kann. Das Plug-in ist im SonarQube Marketplace verfügbar, womit Installation und Updates mit einem Klick als Admin im Web-UI erledigt sind.

Die Abbildung der Architektur auf die Java-Package-Struktur erlaubt es, einfach festzustellen, zu welcher Komponente, welchem Layer und welchem Scope sie gehört. Somit müssen wir nur noch für jede referenzierte Klasse die Eigenschaften vergleichen, um ungewollte Abhängigkeiten aufzudecken. Jedem sollte klar sein, dass man von der Persistenz (z. B. aus einem DAO oder Repository) nicht auf einen Anwendungsfall zugreift, sondern nur umgekehrt. Ein REST Service sollte einen Anwendungsfall aufrufen und nicht daran vorbei direkt auf die Persistenz zugreifen. Genau...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang