W-JAX 2015: Es geht weiter

In den ersten beiden Blogteilen habe ich mich auf den Agile Day der WJAX 2015 fokussiert. Nun möchte ich auch noch ein paar andere interessante Veranstaltungen der W-JAX vorstellen.

The Journey of a Bank where IT took the lead

Den Anfang machte Henk Kolk mit seiner Keynote „The Journey of a Bank where IT took the Lead“. Der Chief Architect der niederländischen Niederlassung der ING berichtete von der Digitalen Transformation der ING. Gestartet wurde das Ganze in 2009, als die teure, vielversprechende und outgesourct entwickelte Banking-App gelauncht wurde und vom Markt mittelmäßiges bis schlechtes Feedback bekam. Die App sollte dem Kunden alle Bankgeschäfte rund um die Uhr anbieten, um den aktuellen Markbedarf als einer der Ersten aufzugreifen und abzudecken. Aufgrund der vielen Abbrüche und einer unhandlichen Bedienungsführung konnte sich die App jedoch nicht durchsetzen. Ab diesem Zeitpunkt stellte man sich bei der ING die Frage, was schiefgelaufen war und wie man so etwas in der Zukunft verhindern könnte. Die Antwort war die Inhouse-Entwicklung mit agilem Vorgehensmodell. Dazu mussten jedoch intern die passenden Strukturen geschaffen werden. Im Vortrag erläuterte Henk Kolk, wie man nach und nach die IT-Teams formte, schulte und schließlich mit der Fachabteilung zu interdisziplinären Teams zusammenbrachte. Mittlerweile werden in den Niederlanden mehr als 55 % der Verträge über die Mobile Applikation abgeschlossen. Dieser Erfolg ist der restrukturierten IT zu verdanken.

Effektive Code-Reviews

Weiter ging es mit „Effektive Code-Reviews“ von Thorsten Maier. Er zeigte auf, wie Code Reviews helfen können, die Code-Qualität zu verbessern. Der Haken dabei sind natürlich immer die Kosten. Durchschnittlich erhöhen sich diese um 20 % gegenüber den Kosten der Entwicklungsphase ohne Code-Reviews. Diese Kostensteigerung erscheint auf den ersten Blick immens. Wenn man jedoch bedenkt, dass der meiste Aufwand für Software nicht während der Entwicklung, sondern während der anschließenden Wartung anfällt, wird der Brocken schnell relativiert. Betrachtet man nämlich die Kosten für den gesamten Software-Lebenszyklus, kommt man unterm Strich mit Code Reviews günstiger weg. Deshalb rentiert es sich bei lang laufenden Projekten, Code Reviews von Anfang an durchzuführen. Des Weiteren wurden in dem Vortag verschiedene Arten des Code Reviews vorgestellt (nach jedem Feature/Bugfix/Commit) und einige Tools genannt. Als zwei gute Tool-Kombis haben sich bewährt:

  1. der Atlassian Stack: Jira für die Issue-Verwaltung, Bitbucket (früher Stash) für die Pull Requests für den Code Review, Bamboo als Integration Server und Crucible, um den Code Review in den Issue-Workflow einzubinden.
  2. der Eclipse Stack: Jira oder Redmine für die Issue-Verwaltung, Jenkins/Hudson als Integrations-Server und Gerrit für den Code-Review.

Bei beiden kann Git als Repository und Mylyn als Anbindung zwischen der Eclipse IDE und Git verwendet werden.

Meiner Erfahrung nach sind Code Reviews ein mächtiges Werkzeug für den Wissenstransfer innerhalb eines Teams, bei größeren Projekten gerne auch teamübergreifend. Das Review muss dabei zeitnah nach der Codeveränderung erfolgen, damit der Entwickler sich nicht wieder in die Aufgabe hineindenken muss. Eine Toolunterstützung halte ich für essenziell. In kleineren Projekten/Teams (bis zu fünf Entwickler) halte ich die E-Mail für vollkommen ausreichend. Sobald ein Commit vorgenommen wird, wird im Issue-Ticket der Reviewer vermerkt und eine formlose E-Mail mit dem Commit-Text an diesen verschickt. So kann sich der Reviewer die Zeit für den Review reservieren. Bei größeren Projekten sollte man auf Tools zurückgreifen, die sich in den Entwicklungsworkflow leicht einbinden lassen und wenig manuelle Arbeit erfordern. Dies erleichtert die Akzeptanz bei allen Beteiligten. Um die Effizienz der Code-Reviews zu steigern, sollte jeder Entwickler in die Rolle des Reviewers schlüpfen dürfen. Zudem sollte der Review im Dialog mit dem Entwickler durchgeführt werden.

REST-Architekturen erstellen und dokumentieren

Am Mittwoch zeigte Martin Walter in „REST-Architekturen erstellen und dokumentieren“ anhand von Beispielen auf, wie man REST APIs effektiv beschreiben kann. Das größte Problem bei der Dokumentation ist ihre Synchronisierung mit dem aktuellen Code. Viele von uns haben sicherlich bereits Software-Dokus geschrieben und wissen aus Erfahrung, dass es sehr mühselig sein kann, diese aktuell zu halten. Zum Glück gibt es Tools, die uns Entwicklern das Leben vereinfachen. Martin Walter stellte fünf Open Source- und zwei kommerzielle Produkte vor. Ich werde hier auf drei davon kurz eingehen.

  1. ApidocJS: Erzeugt die Dokumentation aus API-Annotationen im Code. Die Generierung erfordert Node.js. Die Dokumentation wird versioniert.
  2. Swagger: Die Dokumentation wird aus einer Json-Datei erstellt, die man zuvor aus seinem Code generiert hat. Durch das Zwischenformat ist Swagger prinzipiell sprachneutral. Das Ergebnis ist eine interaktive Doku. Die Doku ist aktuell noch nicht versionierbar.
  3. Spring REST Docs: Erzeugt die Dokumentation durch statische Codeanalyse. Es ist leicht in den Build-Prozess integrierbar. Laut Martin Walter ist das Tool jedoch in der aktuellen Version noch nicht ausgereift.

 

Abbildung 1: apidocJS

 

Abbildung 2: Spring rest Docs

… und noch viele mehr

Die Tage boten noch viele weitere interessante Vorträge und Keynotes. In „End-to-End-Automatisierung – mehr als Continuous Integration und Continuous Delivery“ ging Jürgen Günter auf die beiden unterschiedlichen Kulturen der Developers (Schnelligkeit, Agilität) und Operators (Stabilität, Steuerung und Kontrolle) ein, die mehr oder weniger zu DevOps verschmelzen, und stellte einen möglichen Continuous Delivery Stack vor.

In „Auf dem Weg zu komplexen und adaptiven Architekturen“ nahm uns Uwe Friedrichsen auf eine Märchenstunde mit. Er fing bei der Geschichte der Märkte an (Industrialisierung à postindustrielle Ära), fuhr fort mit der Geschichte der Organisationen (tayloristische Organisation <-> Beta-Organisationen <-> kybernetische Organisation) und kam schließlich zu den passenden Architekturen für die jeweilige Ära und Organisationsform. Als Beispiel für eine unpassende Architektur nannte er Microservices (postindustrielle Ära + Beta-/kybernetische Organisation) in Verbindung mit einer zentralen relationalen Datenbank (industrielle Ära + tayloristische Organisation).


Links

http://apidocjs.com/

http://swagger.io/

http://petstore.swagger.io/

http://projects.spring.io/spring-restdocs/

http://docs.spring.io/spring-restdocs/docs/current/reference/html5/