Für den 20.10.2016 hatten diverse Java User Groups aus dem norddeutschen Raum zum Java Forum Nord geladen. Die Konferenz war längst ausverkauft, aber weil ein Kollege abspringen musste, konnte ich einspringen.

Erste neue Erfahrung: zu einer Entwicklerkonferenz ganz entspannt am gleichen Tag mit Bus und U-Bahn anreisen – die „Anreise“ nach Hannover war naturgemäß unkompliziert.

Die Konferenz war vollgepackt mit interessanten Vorträgen – mit vier parallelen Slots plus Workshop war die Entscheidung nicht immer leicht.

Auf jeden Fall war es interessant, mal wieder zu sehen, wie die Softwareentwicklung in anderen Branchen so tickt. Die Assekuranz ist da ja nicht mehr – wie in der Frühzeit der EDV – besonders innovativ unterwegs.

 

Die einzelnen Vorträge, die ich besucht habe:

 

1. Uwe Friedrichsen: Das Leben, die IT und der ganze Rest (Keynote)

Wie von einer Keynote zu erwarten, gab es hier gleich zum Warmwerden den großen Rundumschlag: was so gern als „Digitalisierung“ bezeichnet wird, ist nicht weniger als der Übergang von der Industriegesellschaft zur post-industriellen Welt der dynamischen Märkte, wo auf einmal nicht mehr die Effiziensteigerung bestehender Prozesse das Ziel ist, sondern die radikale Verkürzung von Markteinführungszeiten bzw. Änderungszyklen.

Wenn man das akzeptiert, dann ist klar, dass zum einen das klassische Softwareengineering, das ja quasi die Industrialiserung des Softwareentwicklungsprozesses zum Ziel hat, eigentlich obsolet ist und zum anderen sowohl das klassische Unternehmens-Management, alle hierachische Organisationen und die grundsätzliche Unterscheidung Linie vs. Projekt Konzepte sind, die nicht mehr in die heutige Welt passen.

Alternativen wurde nicht aufgezeigt – aber das wäre für die Keynote wohl auch zuviel verlangt 😉

2. Dr. Carola Lilienthal: Langlebige Softwarearchitekturen – technische Schulden erkennen und abbauen

Eine gute und konzentrierte Darstellung von technischer Schuld und den Mitteln, wie man sie beherrschen kann. Insgesamt ein sehr eloquenter Vortrag mit Ausflügen in die kognitive Psychologie – man nimmt der Dame ab, dass sie versteht, wovon sie spricht.

3. Rabea Gransberger: Automatisierung des Software-Entwicklungsprozesses

Zur Abwechslung ein sehr bodenständiger Vortrag: was bedeutet es denn wirklich für einen Aufwand, diverse Schritte des Entwicklungs- und Verteilungsprozesses zu automatisieren ? Welche Tools bieten sich da an?

Botschaft insgesamt: einfach machen; manches ist vielleicht aufwändiger als gedacht, manches ist vielleicht auch nicht erreichbar, aber insgesamt kann man mit einem überschaubaren Aufwand (besser in Tagen als in Monaten zu messen) schon sehr viel erreichen.

4. Lutz Hühnken: Lagom – Microservices weiter gedacht

Leicht nerdig, aber cool. Der gezeigte Code sah aus, als würde ein Scala-Programmier notgedrungen  Java-Code schreiben – ohne Java 8 geht da überhaupt nichts.

Das Lagom-Framework steht noch am Anfang, kann aber schon viel.

Der Vortrag machte einmal mehr klar, dass zu Microservices eben mehr gehört, als die bestehende Software irgendwo auseinanderzureißen und die Funktionsaufrufe durch RPC-artige REST-APIs zu ersetzen.

Sehr spannend waren auch die Ideen zum Event-Sourcing, was die Art und Weise, wie wir Daten persistent speichern, komplett auf den Kopf stellt.

5. Arne Limburg: Mut zur Fachlichkeit

Hier ging es vor allem darum, dass Fachobjekte beim DDD eben etwas anderes sind als einfache DAOs mit Gettern und Settern. Vielmehr müssen die fachlich möglichen Zustandswechsel explizit gemacht und alle anderen (also die, die ein Objekt in einen ungültigen Zustand versetzen würde) unterbunden werden.

Das alles war an konkreten Beispielen hergeleitet – insgesamt durchaus nachvollziehbar, wenn auch nicht immer ganz bis zum Ende durchgeführt. Aber das ist in 45 Minuten ja auch nicht zu erwarten.

6. Oliver Gierke: DDD & REST – Domain Driven APIs für das Web

Ein echter Augenöffner: wenn man REST-APIs nicht primär als RPC-gestützte CRUD-APIs baut, dann sind die Konzepte von REST und DDD sehr kompatibel: RESTs Resourcen sind nämlich die Aggregates von DDD. Und die fachlichen Zustandswechsel ebendieser Aggregates sollten durch explizite REST-Operationen ausgelöst werden.

Das funktioniert aber nur dann, wenn man das Modell auf den Bounded Context begrenzt – man braucht also beispielsweise i.d.R. kein allgemeines Datenmodell für Personen, sondern ein viel konkreteres für Kunden im Kontext einer Bestellung und ein anderes, ebenfalls sehr konkretes, für Kunden im Kontext einer Auslieferung. Dadurch hat man dann für eine reale Person in den beiden Systemen zwei verschiedene Entitäten, die man aber durch die Einführung eines expliziten Identifikationskennzeichnens (z.B. eine Kundennummer) verknüpfen kann.

Mir scheint hier ein Dilemma zu bestehen: aus hoher Flughöhe betrachtet erkennt man Entitäten (wie Personen, Autos, Pakete oder Versicherungsverträge), die bestimmte Eigenschaften haben, sich entsprechend modellieren und in querschnittliche Verwaltungssystemen speichern lassen. Diese Verwaltungssysteme führen aber zu einer engen Kopplung der verschiedenden Fachsysteme, die alle mit den gleichen Entitäten arbeiten müssen.

Wir haben hier also einen Zielkonflikt: einerseits wollen wir Redundanzfreiheit (Don’t Repeat Yourself), andererseits wollen wir eine lose Kopplung der Fachsysteme (Single Responsiblity Principle). Im Zeitalter der Microservices hat das letztere wohl mehr Bedeutung, so dass man eine gewissen Redundanz in Kauf nimmt (Adieu, kontexloses Datenmodell)…

7. Rabea Gransberger: Code Reviews: Techniken und Tipps

Wieder sehr bodenständig – warum/wann/wie macht man Code-Reviews? Vieles klingt fast trivial, aber die Botschaft kommt rüber: Code-Reviews dienen nicht der Bewertung der Entwickler, sondern einzig und allein der Verbesserung der Qualität. Und zwar nicht nur dadurch, dass der Reviwer Fehler in der Software findet, sondern auch dadurch, dass Reviewer etwas lernt.

 8. Stefan Zörner: Nörgeln ist einfach. Aber was (genau) ist eigentlich Architekturbewertung?

Kurz vor Schluss nochmal Denksport: kann man Architekturen anhand einiger weniger Eigenbschaften als gut oder schlecht bewerten? Wir haben das mittels Stimmkarten getan.

Aber ist so eine Bewertung „nach Bauchgefühl“ zielführend? Gibt es vielleicht systematischere Verfahren?

Wir haben gelernt (falls wir es nicht schon geahnt hatten), dass das Bachgefühlt täuschen kann und dass „Best Practices“ nicht immer zum konkreten Anwendungsfall passen.

Wir haben weiterhin gelernt, dass es qualitative Verfahren gibt, mit denen sich Architekturentscheidungen  schon vor der Implementierung bewerten lassen (diese Verfahren messen die Architektur an den relevanten Vorgaben). Diese kombiniert man dann mit quantitiven Verfahren, die die vorgegebene Architektur mit der Implementierung vergleichen.

Und dann haben wir noch gelernt, dass im Workshop die Entwickler immer die sind, die das Hemd aus der Hose haben 🙂

9. Rüdiger Schnirring: Kommunikation als Impediment

Zum Schluss nochmal eine „Keynote“ – eine satirische und unterhaltsame Auseinandersetzung mit der Kommunikation zwischen Akteuren in IT-Projekten, den Parallelen zu Paarbeziehungen und den Fallstricken der Realwelt.

 

Insgesamt eine absolute Empfehlung – den Termin für das nächste Jahr werde ich mir freihalten.