“Modulare Anwendungen sind nur für größere Projekte gut – sonst lohnt sich der Mehraufwand nicht!”

Meine Meinung zu dieser Kontroverse:

In diesem Fall war es aus meiner Sicht äußert schwer, „mal eben“ zu helfen bzw. sich eine richtige
Meinung zu bilden. Es wurde viel richtig gemacht, zumindest zu Beginn des Projekts. Aufgrund von
Releasedruck wurde es dann immer schwieriger, auf alles gleichzeitig zu achten, da deutlich zu
wenig automatisiert war. Eine Integration war vorhanden, aber automatische Metriken wurden nicht
erzeugt. Auch auf die Testergebnisse wurde irgendwann (das Projekt wurde zwei Monate vor Release
einfach deaktiviert, keiner weiß mehr warum) nicht mehr geachtet.

Auf der anderen Seite wurden dann aber Lasttests vor dem Livegang durchgeführt. Aufgrund der
erkennbaren Lücken und nicht ausbalancierter Automatismen innerhalb der Toolchain sind hier
meiner Meinung nach verschiedene Schritte nötig:

  1. Immer auf der grünen Wiese mit einem neuen Service beginnen. Bei neuen fachlichen
    Services sogar in einem neuen Projekt. Hierüber erkennt man Dependencies direkt, und man
    bekommt Routine im Umgang mit immer wiederkehrenden Dingen wie dem Erstellen einer
    Maven POM. Man erkauft sich Abhängigkeiten bewusst, statt sie „geschenkt“ zu
    bekommen, obwohl gar nicht benötigt. Man erkennt auch die Notwendigkeiten, gewisse
    APIs für andere Services bereit zu stellen. Die ganze Architektur entkoppelt sich dadurch
    (fast) automatisch.
  2. Refactoring muss Bestandteil einer jeden Iteration werden, idealerweise innerhalb der zu
    implementierenden Features.
  3. Werkzeuge wie Sonargraph und Sonar müssen in die Continous-Integration-Zyklen
    integriert werden, um Violations frühzeitig erkennen zu können. Die Ergebnisse der
    Metriken müssen Bestandteil einer Abnahmeprüfung (wie beispielsweise einer „Definition of
    Done“) sein. Pro Werkzeug muss es einen Verantwortlichen geben, der für Pflege und
    Updates Zeit bekommt.
  4. Es muss regelmäßig Schulungen zu Violations und dem angestrebten Architekturmodell
    geben. Dinge, die zu komplex sind, sollten idealerweise automatisiert werden.
  5. Nach jeder Iteration sollte man sich seine technischen Schulden (Technical Debt, Ward
    Cunningham) gegenüber dem Projekt bewusst machen und versuchen, diese geringer zu
    halten, als sie in der vorherigen Iteration war.

Die Fragestellungen des Management waren somit auch recht einfach zu beantworten:

  1. Die REST-Architektur war im Weg, da das Domain-Modell nicht durch die Use-
    Cases iterativ modelliert und entwickelt wurde, sondern große Teile auf der grünen
    Wiese, ohne echte Anforderungen erdacht wurden. Somit waren die REST-Controller vielmehr ein Abbild der fachlichen Domain, anstatt echte Use-Cases zu bearbeiten.
  2. Schwankende Leistungen innerhalb der Entwicklung gab es, da das Team weder explizite
    Refactoring-Zyklen zugestanden bekam, noch die Notwendigkeit dazu sah. Das Team
    erkannte nicht, dass die Komplexität aufgrund der immer enger werdenden Kopplung zunahm. Man scheute den Aufwand, ein allgemeines API heraus zu refactoren. Stattdessen wurde alles „ineinander hineingekleistert“.
  3. Werkzeuge wie Sonargraph sind in der Lage, die Absicherung zu automatisieren. Somit
    muss das Team nicht immer selbst ein Auge darauf haben, das Werkzeug weist einen
    selbstständig darauf hin. Dies ermöglicht es auch, die Aufgabe der Refactorings statisch an
    die geeignetste Person innerhalb des Teams zu vergeben.
  4. Eine Continous Integration war ja bereits vorhanden, somit war es recht einfach, diese um
    die Erzeugung von Sonar-Metriken zu erweitern. Natürlich müssen die Schulungen, was die
    Violations eigentlich genau bedeuten, noch folgen.

Das eigentliche Problem innerhalb dieses Projekts bestand meiner Meinung nach aber in der falsch
verstandenen Wiederverwendbarkeit sowie an der Unkenntnis grundlegender Regeln wie dem Single-Responsible-Principle. Dies sind glücklicherweise einfach zu behebende Dinge 🙂

Meiner Meinung nach sollte es also guter Stil sein, jedes Feature, jeden Service zuerst einmal
komplett losgelöst vom bisherigen Projekt zu entwickeln, um von vornherein immer bewusst über
jede Kopplung und jede Bibliothek nachzudenken.

Diese beiden Tools werden ohnehin nie unabhängig voneinander gebraucht, wozu sollen wir Module vorsehen?

Joachim Arrasz ist als Software- und Systemarchitekt in Karlsruhe bei der synyx GmbH & Co. KG als Leiter der CodeClinic tätig. Darüber hinaus twittert (@arrasz) und bloggt er gerne (http://blog.synyx.de/).
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.