Frankfurter Entwicklertag 2017: Erfahrungsbericht

Posted by in Konferenz

Ich war am 16./17.02 beim Frankfurter Entwicklertag unterwegs. Die Konferenz wurde zum vierten Mal an der Goethe Universität Frankfurt veranstaltet und glänzte für mich durch sehr interessante Vorträge. Insgesamt war es wieder professionell organisiert und die Betreuung der Sprecher war super. Mein Vortrag lief dadurch auch stressfrei.

Tag 1 – Conference Day

Nach der Begrüßung ging es mit einem kurzen Talk von John Fletcher los: Entwicklertag in der Praxis. John berichtete über die Ideen, die er aus dem Entwicklertag 2016 mitgenommen hatte und wie er sie umgesetzt hat. Dabei waren neben erfolgreichen Dingen wie der ATSA (Aggressive Task Self Assignation) Award oder der Einsatz eines Benachrichtigungstools für Abhängigkeiten (VersionEye) auch Experimente verteten, die nicht so erfolgreich waren. Darunter der Versuch Dokumentation durch Fragen im Wiki zu erreichen oder der Einsatz eines lauten Gongs, falls etwas bereit ist zum Testen.

Als nächstes gab es einen Appetitanreger von Alexander Schwartz mit
Build- und Delivery-Pipelines als Code mit Jenkins. Er hat an einem kleinen Spielprojekt vorgestellt, wie man Pipelines in Jenkins mit dem Pipeline Plugin in einem Jenkinsfile pflegt. Dadurch kann auch das Buildfile versioniert werden. Die Definition einer Pipeline wird dadurch einfacher. Noch dazu gibt es allerlei nette Sachen, wie automatische Branch-Entdeckung und eine schicke Darstellung der Pipeline.

Einen in vieler Hinsicht pragmatischen Vortrag hielt Christian Fischer mit
Agile Code Reviews – Vom 4-Augen-Prinzip zum Qualitätskatalysator. Es war eigentlich alles dabei, was man so über Code-Reviews wissen sollte. Besonders wichtig fand ich die Vor- und Nachteile, die die verschiedenen Ansätze bieten: Precommit hat das Problem der Sichtbarkeit (Code kann nur auf Entwicklerrechner gereviewt werden), aber verschmutzt das Repository nicht. Postcommit kann dazu führen, dass eventuell gar kein Review stattfindet. Bei Pull-Requests gibt es wieder das Problem der Sichtbarkeit, aber es wird nur valider Code ins Repository gelesen. Bei kleineren Dingen reicht seiner Meinung nach auch „über die Schulter gucken“ aus. Für alles Andere ist eine werkzeuggestützte Vorgehensweise sinnvoll, bei der die üblichen Regeln berücksichtigt werden sollten: 60-90 Minuten maximale Reviewzeit, immer ca. 200 LOC in einer Sitzung und der Code sollte schon automatisch formatiert worden sein, um Ablenkungen zu vermeiden.

Als bekennender Clean Coder war es spannend Stefan Lieser einmal live zu erleben. Er hat für mich nicht viel Neues erzählt in seinem Vortrag Wandelbarkeit wieder herstellen – Refactoring von C# Legacy Code. Das jedoch auf höchst anschauliche Weise und mit Witz und Verstand. Zum Ende hat er noch die Mikado-Methode vorgestellt, mit der komplexe Refactorings gut geplant werden können (Passendes Video dazu).

Tag 1 – Nachmittag

Nach der Mittagspause gings weiter mit Henning Schwentner und
Domain-Driven Design – Basis für Microservices und Anwenderglück. Henning ist auf jeden Fall ein unterhaltsamer Redner. Die Kernidee seines Vortrages ist, die Domäne in verschiedene Modelle aufzuspalten und diese fachliche Spaltung zu nutzen, um daraus Untersysteme (Microservices: „Sonst wird der Talk ja nicht angenommen“ Anm: So oder so ähnlich war das Zitat 😉 ) zu bauen.

Anne-Christine Karpf berichtete anschließend über
Automatisierte Software-Qualitätsmessung – Erfahrungsbericht aus einem agilen Entwicklungsteam. Sehr spannend zu sehen war, welche Metriken in einen Qualitätsindex aufgenommen wurden: Die zyklomatische Komplexität, durchschnittliche Anzahl der Abhängigkeiten, Anzahl der Compilerwarnungen, Testabdeckung, Anzahl der Klassen mit mehr als 20 Methoden und Anzahl der Methoden mit Länge über 15 Zeilen. Diese wurden sowohl während eines Sprint mit Sonar gemessen und dann an jedem Sprintende aufbereitet vorgestellt. Dadurch schafft man Bewusstsein für die Qualität im ganzen Team.

Mit viel Charme hat Sven Amann in seinem Vortrag
TDD ist für Träumer, nicht für Praktiker, oder? dargelegt, was TDD ist und was nicht. Außerdem ging es darum, ob TDD tot ist und wie man es am besten anwendet. Fazit: TDD alleine reicht nicht aus, sondern man sollte sein Gehirn auch einschalten und darüber nachdenken was man gerade tut.

Tag 2 – Tutorial Day

Am sogenannten Tutorial Day habe ich mir am Vormittag mit Angular 2 die Finger heiß gecoded. Besprochen wurden die grundlegensten Dinge, immer im Zusammenspiel mit der Angular-CLI, die einem zum Beispiel Komponenten generieren lässt. Im Laufe des Tutorials wurde auch klar, dass das gesamte Ökosystem um Angular 2 sehr ausgereift ist und praktisch keine Wünsche offen lässt. Nach der Initialisierung mit der CLI kann auch sofort losgelegt werden. Dabei sind Komponenten modular aufgebaut: In eigenen Dateien liegen CSS/HTML/Code. Das ist zwar gut gedacht, aber immer wieder kam es vor, dass man sich in seinem Workspace verirrte. Für mich als TypeScript-Liebhaber war der Umgang mit dem eigentlichen Code eine wahre Freude. Klar wurde dann aber spätestens bei der Einführung von Routen, dass das Framework seine ganz eigene Komplexität mit sich bringt und nicht einfach mal so eingesetzt werden kann. Vielen Dank Philipp Burgmer.

Am Nachmittag habe ich das Real World Architecture Kata von Patrick Baumgartner besucht. Dort haben wir eine Bank modelliert. Zuerst einfach so und dann mit Hilfe des C4-Modells. Insgesamt gab es 3 Durchgänge mit unterschiedlichen Anforderungen und einer anschließenden Bewertung. Es ging nicht darum der perfekte Architekt zu werden. Viel wichtiger war der richtige Einsatz von Abstraktionsleveln und Techniken zur Visualisierung. Am Ende waren sich alle einig, dass man damit viel effizienter kommunizieren kann.

Fazit

Der Frankfurter Entwicklertag war für mich super organisiert mit spannenden Vorträgen und zwei exzellenten Tutorials. Man merkt auch an den Teilnehmern, dass es eine Entwicklerkonferenz ist. So kann man sich wunderbar in den vielen Pausen austauschen, die von der Länge her ideal sind!