Der erste Frankfurter Entwicklertag – ein Konferenzbericht

Der Karlsruher Entwicklertag hat sich in den letzten Jahren zu einer erfolgreichen Entwicklerkonferenz mit über 800 Besuchern im Jahr 2013 gemausert. Daraus entstand die Idee, so eine Plattform für den regionalen Austausch der Entwicklerszene auch in Frankfurt zu etablieren. Am 19.02.2014 war es dann soweit. Der erste Frankfurter Entwicklertag öffnete seine Pforten und war prompt mit 200 Besuchern bereits im Vorfeld ausgebucht. Auch auf Referentenseite kamen auf die 17 Session-Slots fast 100 Einreichungen. Neben vielen Firmen waren auch Communities wie die Softwerkskammer, diverse Java- und weitere lokale User-Groups zahlreich vertreten.

Agilität

Dass Agilität im Mainstream angekommmen ist, spiegelt sich in vielen Vortragsthemen wider. Es geht nicht mehr um das „Ob“ oder Scrum-Basics, sondern um weiterführende Themen, die konkrete Probleme aus der Praxis aufgreifen. Der Eröffnungsvortrag „Agile Offsharing“ (nein, kein Schreibfehler!) diskutierte Probleme verteilter Teams und wie verteilte Paarprogrammierung dabei helfen kann, aus zwei Teams an verschiedenen Standorten ein verteiltes Team zu machen. Dabei entwickelt sich die Toolunterstützung weiter vom primitiven Desktopsharing weg hin zu spezialisierteren Tools, die analog zu Google Docs für jeden der beiden Partner einen eigenen Cursor anbieten und so paralleles Tippen ermöglichen.

Agilität funktioniert oft gut im Kleinen, bereitet aber häufig noch Probleme bei der Skalierung auf große Organisationen. Haagen Buchwald führte uns mit dem Vortrag „Agility Path“ in das gleichnamige Framework vom Scrum-Vater Ken Schwaber ein. Der zentrale Erfolgsfaktor besteht demzufolge darin, die agilen Werte und Prinzipien auch auf den höheren Ebenen der Organisation zu verankern. Der Referent von „Productivity 3.0“ präsentierte zudem ein Framework, das das Problem lokaler Pseudo-Optima in agilen Teams adressiert. Bausteine sind hier ebenso eine agile Skalierung auf Unternehmensebene, Agilität auch auf nicht-IT Arbeitskontexte zu übertragen und mit „lean“-Ansätzen auf Effektivität und nicht Effizienz hin zu optimieren.

Wieder näher am Entwickler erzählte Jens Schauder mit viel Humor von seinen Erfahrungen, die er bei der Einführung von Software-Craftmanship-Themen in „Legacy-Teams“ gesammelt hat. Es reicht dabei nicht aus, dem Team neue Regeln zu verordnen. Um nachhaltige Veränderung im Team zu bewirken, müssen die Mitglieder die zu erreichenden Ziele sowohl verstehen als auch dazu motiviert werden, diese zu verfolgen.

Testdesign

Agile Projekte mit ihren kurzen Releasezyklen kommen nicht ohne automatisierte Tests aus, zumindest, wenn sie langfristig gute Qualität liefern sollen. Dabei entsteht viel Testcode, der bei schlechtem Design schnell selbst zum Problem werden kann. Test-Design-Probleme und deren Lösungen brachte uns der Vortrag „Test Code Design Pattern“ nahe. Die große Überraschung dabei: Winfried Schwarzmann von SAP illustrierte die Muster mit Codebeispielen in ABAP! Was mal wieder zeigt: Man kann in jeder Sprache schlechten wie sauberen Code schreiben.

Bei der Erzeugung von Testdaten, die sehr variabel oder komplex geschachtelt sind, helfen die von Martin Klose vorgestellten „Test Data Builder“. Mittels Fluent-API lassen sich solche Testdaten sehr gut lesbar komponieren.

Ín meinem Vortrag „Integration Test Hell“ zeigte ich, warum integrative Tests teuer in Erstellung und Wartung sind und deshalb gemäß der Testpyramide sparsam eingesetzt werden sollten. Einsparpotential bietet hier v.a. die Dekomposition integrativer Tests, die zu viele verschiedene Aspekte auf einmal testen. Gerade das Testen von Logik lohnt sich in Richtung isolierter Tests zu drücken. Die Referenten von „ATDD mit stabilen UI-Tests“ knüpften daran nahtlos an und plädierten dafür, Akzeptanztests wenn möglich frei von GUI- oder gar technischen Begriffen zu beschreiben. GUI-Tests selbst sollten technische Details hinter Abstraktionen wie Workflow-Objects, Page-Objects oder Page-Fragments verstecken.

Architektur

Big Data ist nicht erst seit den NSA-Skandalen in aller Munde. Ein Referent demonstrierte z.B., wie Hadoops skalierbarer Map-Reduce-Ansatz auch die Analyse sehr großer Datenmengen ermöglicht. Aber auch die Anforderung extrem geringer Latenzzeit wird immer wichtiger und entscheidet z.B. im Wertpapierhandel oft über Gewinn oder Verlust. Florian Baumert zeigte uns, welche Konzepte beim Programmieren man dazu besonders beachten muss. Ein Vortrag über Reaktive Programmierung schlug in dieselbe Kerbe. Das eigentlich alte Paradigma gewinnt nicht erst seit dem Reactive Manifesto im letzten Jahr rapide an Bedeutung, denn es adressiert die Anforderungen Skalierbarkeit, Fehlertoleranz und geringe Latenz, die heute relevanter sind denn je. Die Zutaten: ereignisgetriebenes „message passing“, asynchrone IO und Datenflussorientierung.

Wer prozeduralen Service- oder Controllercode durch reichhaltige und komplexe Domänenobjekte im Sinne eines Domain Driven Design ersetzen will, hat mit relationaler Datenbank und ORM seine liebe Qual. Die Referenten von „Event Sourcing in der Praxis“ verordnen in diesem Fall eine Event-Sourcing-Architektur, die den Strom aller eingehenden Nachrichten persistiert. Vergleichbar mit einem Datenbank-Log werden nicht der eigentliche Zustand, sondern nur die Änderungen geschrieben. Das Ganze fügt sich gut in eine „reaktive“ Landschaft und unterstützt außerdem bei Skalierbarkeit und Performance. Alleinstellungsmerkmale sind zudem die lückenlose Nachstellbarkeit von Produktionsfehlern aus der Vergangenheit und eine Historie zum Nulltarif, die Anforderung eines Audit-Logs gleich miterfüllt.

Und sonst so…

Thorsten Pfannebecker zeigte, wie eine DSL auf XText-Basis zur Generierung von CRUD-Anwendungen eingesetzt werden kann. Außerdem gab es eine Session im unterhaltsamen Format „Pecha Kucha“. Hier kommen gleiche mehrere Referenten in kurzer Abfolge auf die Bühne. Aber der Referent muss sich kurz fassen: Er hat nur 20 Folien à 20 Sekunden lang Zeit!

Mit dem „Craftsman Swap“ stellte Nicole Rauch, Mit-Initiatorin der Softwerkskammer, eine Art „Walz“ für unsere Entwicklerzunft vor. Dabei tauschen zwei Entwickler unterschiedlicher Firmen temporär ihre Teams. So können sie vom jeweils anderen Team neue Ansätze lernen.

Uncle Bob’s Keynote

Als Höhepunkt für die abschließende Keynote „Expecting Professionalism“ konnten die Organisatoren Robert C. Martin alias „Uncle Bob“ gewinnen: kodierendes Urgestein, seit über 40 Jahren in der professionellen Softwareentwicklung, Autor unzähliger Bücher, Artikel und Konferenzbeiträge und v.a. Gallionsfigur der Software-Craftsmanship-Bewegung. Selbst Entwickler, die ihn nicht kennen, haben vermutlich schon einmal von seinen SOLID-Prinzipien oder der Craftsmanship-Bibel „Clean Code“ gehört.

Uncle Bob schmunzelt über unser codecentric T-Shirt „Clean Code – Dirty Mind“

Der Saal ist noch einmal bis zum Anschlag gefüllt; man ist gespannt auf den großen Namen. Und natürlich: Uncle Bob enttäuscht nicht. Er bringt den Saal zum Lachen, kann gut reden und vor allem Geschichten erzählen: So umgibt uns Software heute bereits von allen Seiten. Doch unsere Branche spart an Qualität: „We ship shit“! So zeigt etwa das Beispiel eines Autos, das aufgrund eines Softwarefehlers beim Bremsen beschleunigte, welche Risiken uns als tickende Zeitbomben drohen. Um diese zu beherrschen, setzen etablierte Berufe auf bewährte Maßnahmen zur Qualitätssicherung. Zentrales Prinzip dabei: Redundanz. Beispiel Vier-Augen-Prinzip. Beispiel doppelte Buchhaltung. Die Summen auf Soll- und Habenseite müssen gleich sein. Damit sichert sich der Buchhalter gegen Fehler ab.

Doch so etwas gibt es auch bei uns: Reviews. Pair Programming. Automatisierte Tests. Wie bei der doppelten Buchführung müssen Test- und Produktiv-Code die gleichen Werte ergeben. Wir haben die Werkzeuge, wir müssen sie nur einsetzen. In diesem Sinne: Be professional and don’t ship shit!