Der fünfte und letzte Tag dauerte nur bis Mittags, war ohne Herstellerausstellung, dafür nochmals mit 3 Slots für knackige Talks. Auf zwei davon möchte ich folgend eingehen.
Think of time as events
Der erste Talk startete mit der Aussage Think of time as events. Das Problem, dass dieser aufgriff, ist wohl den meisten von uns bekannt; Sachen vor sich herschieben und sich durch diverse Störfaktoren von der wirklichen Arbeit ablenken lassen.
Auch wenn es nur kurze Störungen sind, die sich immer wieder in unsere tägliche Arbeit einschleichen, führen diese zu einer gewissen Ineffizienz. Man kann sich das Gehirn wie ein Workbench und ein Archiv vorstellen, wobei der Zugriff auf den Workbench sehr schnell vonstatten geht, etwas aus dem Archiv holen jedoch mit viel mehr Aufwand verbunden ist und etwas bestehendem auf dem Workbench Platz machen muss. Dass es neben der üblichen Variante Last In First Out (alles sofort abarbeiten, z.B. jedes Mail) und Follow The Plan (ein sturer Arbeitsplan erstellen und sich selber einbunkern und durch nichts stören lassen) auch ein iterativer Ansatz gibt, stellte uns Staffan Nöteberg mit der Methodik Pomodoro vor.
Diese baut darauf auf, dass der Mensch immer nach antrainierten Rhythmen funktioniert. Wenn wir es uns z.B. angewöhnt haben, immer um 9 Uhr ein Snack zu essen, es jedoch an einem Tag auslassen, kommt unweigerlich ein Hungergefühl auf. So sagt diese Methodik, dass Arbeiten erfasst und auf einer ToDo Liste nach Priorität geordnet notiert werden sollen. Danach wird in 25 Minuten (= ein Pomodoro) Schritten diese Tasks abgearbeitet. Während diesen 25 Minuten lässt man sich durch nichts ablenken und arbeitet fokussiert an einem Task. Nach diesen 25 Minuten hat man 3-5 Minuten, um sich zu erholen und darf sich nicht dem Task widmen, d.h. in dieser Zeit kann man Kaffee holen, kurz Lüften etc. Danach wird wieder am Task weitergearbeitet oder, wenn dieser abgeschlossen ist, der nächste gestartet. Wird der Task durch etwas Kleines gestört, wird dies in der ToDo Liste notiert, wobei zwischen internen Störungen (ich habe kurz meine Mails gecheckt) und externen Störungen (jemand hat mich etwas gefragt) unterschieden wird. Gibt es eine grössere Störung, wird der angefangene Pomodoro abgebrochen und ein neuer 25 Minuten Task muss gestartet werden. Auf der ToDo Liste wird notiert, für welchen Task wie viele Pomodoros verwendet wurden. Am Abend erfolgt die Auswertung der Taskliste mit der Idee, am nächsten Tag durch die Analyse der aufgetretenen Störungen effizienter zu sein.
Dies ist ein kurzer Abriss dieser Methodik, sicherlich behandelt sie ein bekanntes Problem, ob sich diese so bei uns im lebendigen, teamorientierten Umfeld 1:1 umsetzen liesse, ist eine andere Frage. Oftmals würde alleine schon etwas mehr Selbstdisziplin reichen. ;)
Bye Bye Boilerplate
Setter, Getter, Konstruktoren etc. sehen oftmals gleich aus und enthalten keinerlei Applikationslogik. Sicherlich unterstützen die gängigen IDE’s den Entwickler durch automatische Generation des Codes, die Lesbarkeit dessen nimmt dabei jedoch nicht zu. Die Eliminierung dieses sogenanntennnn Boilerplate Code hat sich das Opensource Framework Lombok zum Ziel gesetzt. Über ein Set von Annotationen und dazugehöriger Library sorgt Lombok dafür, dass diese Methoden direkt beim Kompilieren erstellt werden. Zurzeit wird einzig Eclipse über ein Plugin als IDE unterstützt, wobei auch in dieser Features wie z.B. das von der IDE unterstützte Refactoring von Bean Properties noch fehlen.
Um etwas konkret zu werden, möchte ich die beiden meiner Ansicht nach interessantesten Annotationen erwähnen. Die Annotation @data auf der Klasse generiert sämtliche Getter und Setter sowie den Konstruktor; ebenfalls werden automatisch equals/hashCode und toString mit Bezug auf die Felder generiert. Das Bean enthält nur noch die Felddefinitionen, der Code wird sofort viel lesebarer. @cleanup, annotiert auf einer Initialisierung einer Ressource, sorgt dafür, dass diese auf jeden Fall sauber geschlossen wird. Dies macht die Schliessung der Ressource im finally Block obsolet.
Nicht nur die Initiative dieses Projekt zeigt, dass ein Need für mehr Lesbarkeit und Einfachheit des Codes in Java vorhanden ist. Es wurde auch davon gemunkelt, dass die Features von Lombok in kommenden Javaversion enthalten sein könnten, was sicherlich für den eingeschlagenen Weg dieses Projekts spricht.
Over and end
Und schon war die devoxx wieder Vergangenheit, rund 2500 Besucher zählte die diesjährige Veranstaltung. Für mich war es der erste Besuch einer Veranstaltung dieser Art, ich war sehr beeindruckt von der Qualität der Speakers und der Organisation im Allgemeinen.
Nicht nur gab mir diese Veranstaltung einen guten Einblick in neue Technologien und Methodiken, die es weiterhin zu beobachten gilt, auch konnte ich sehr von den Aussagen und Best Practices von Leuten mit sehr viel Software Engineering Erfahrung profitieren.
