Alex Rampp

Ideen für produktive Softwareentwickler

Schlagwort: Community

Resümee zur Clean Code Days Konferenz

In der vergangenen Woche war ich zum ersten mal auf den Clean Code Days in München.

Workshoptag

Los ging es am ersten Tag mit einem Workshop zum Thema „Testgetriebene Analyse von Legacy Code“, den ich zusammen mit einem Kollegen hielt. Die Teilnehmer bekamen dabei eine C# Code Basis mit diversen Problemen „vorgesetzt“. Gemeinsam analysierten wir den Code mit Hilfe von Experimenten, die wir als Unit Tests implementierten. Dabei waren natürlich diverse Hürden z. B. durch Abhängigkeiten zu überwinden. Hier zeigten wir den Teilnehmern, wie man sich im sogenannten „Brown Field“ nach und nach ein Sicherheitsnetz schafft, das komplexere Refactorings möglich macht. In einer abschließenden Diskussionsrunde tauschten wir Erfahrungen Tipps & Tricks aus.

Das Feedback der Teilnehmer war durchweg positiv und auch uns machte der Workshop viel Spaß.

Tag 1: Clean Code mit dreihändigen Affen

In seiner Keynote „Von Clean Code zu Clean Software“ stellte Dr. Elmar Jürgens klar, dass sich Qualität nicht nur auf Code beschränkt. Insbesondere die Organisation und Umgebung in der Entwickler arbeiten hat massive Auswirkungen auf die Qualität einer Software. Interessanterweise lassen sich diese Auswirkungen im Code finden, was Jürgens eindrucksvoll an realen Beispielen demonstrierte. Netterweise stehen die durchaus sehenswerten Slides online zu Verfügung.

Remy Loy zeigte anschließend, wie man Clean Code im Bereich funktionale Programmierung erweitern kann. In seinem Vortrag gab er viele Tipps, wie sich die Code Qualität mit funktionalen Erweiterungen verbessern lässt.

Nach einem leckeren Mittagessen kam mein persönlicher Höhepunkt des Tages. Lutz Marquardt und Frank Blendinger präsentierten Clean Code Konzepte in einer ganz neuen Form – als Rollenspiel. Das Publikum schlüpfte dabei in die Rolle eines Programmierers und konnte an entscheidenden Stellen durch Handzeichen den Verlauf der Geschichte beeinflussen. Hierbei begegnete uns ein Ork als unser Chef, ein dreihändiger Affe der sich für Testautomatisierung aussprach sowie ein Staubsauger, der durch einen Bug plötzlich Menschen tötet („Code Reviews können Leben retten!“). Glücklicherweise erschien uns ein Geist namens „Bob“, der uns einen alten Folianten namens „Clean Code“ schenkte. Auch wenn ich dabei wenig neues gelernt habe war dieses Event purer Spaß und macht Lust auf mehr.

In seinem Vortrag „Clean Code for the Front End“ zeigte Mathias Arens, wie moderne Web Frontend Entwicklung funktioniert. Hier konnte ich am Meisten mitnehmen, da ich nicht primär Frontend Entwicklung betreibe, trotzdem aber immer mal wieder damit konfrontiert werde. Mathias zeigte hier viel Erfahrungswissen sowie verbreitete Patterns. Insbesondere die CSS Namenskonvention Block Element Modifier (BEM) erscheint simpel, ist aber sehr mächtig – diese Methodik kommt auf jeden Fall in meinen Werkzeugkasten.

Mike Kaufmann zeigte wie man mit Sonar Cube Kennzahlen zur technischen Schuld berechnen kann. Trotz der durchaus beeindruckenden Präsentation bezweifle ich allerdings, dass man so ein komplexes Thema in ein paar wenigen
Zahlen erfassen kann. Seiner Aussage „Clean Code ist Team Sport“ stimme ich allerdings voll zu.

In einer sehr unterhaltsamen Live Coding Session zeigte uns Roland Golla, wie man mit dem PHP Framework Codeception komplette End-to-End Tests für Webanwendungen implementiert.

Beim anschließenden Feierabendbier erzählte mir Roland über seine Initiative Never Code Alone in der er soziale Einrichtungen mit Software-Entwicklungsprojekten unterstützt und gleichzeitig den Austausch in der Entwicklercommunity fördert.

Tag 2: Clean Code ist mehr als nur Code

Frisch ausgeruht legte ich an diesem Vormittag den Fokus auf Themen, die über das codieren hinausgehen.

Stark war hier die Aussage von Steven Kolbenschlag, dass die Einführung von agilen Vorgehensweisen oft scheitert, wenn die Code Qualität nicht stimmt. Er schloss seinen Vortrag „Wie agil ist ihr Code?“ mit der Aussage, dass die Vorteile des agilen Vorgehens ohne Clean Code Development nicht voll ausgeschöpft werden können.

Francois Lorioux teilte Erfahrungen aus seinem 30-jährigen Berufsleben und zeigte worauf es ankommt, wenn Software über viele Jahr(zehnte) wartbar und erweiterbar sein soll. Neben vielen Tipps und Anekdoten gefiel mir hier der Satz „If you want to kill software, use inheritance“ besonders gut.

Im Vortrag „Erfolgsfaktor Mensch“ zeigten Claudia Simsek-Graf und Christoph Meyer, dass Software letztlich von Menschen gemacht wird und dass Projekte meist an menschlichen Konflikten scheitern statt an technischen Problemen. Die sehr interaktive Session bot viel Raum zum Erfahrungsaustausch und Diskussion. Gerade die Aussage „Clean Code funktioniert nicht im Alleingang“ kann ich aus eigener Erfahrung voll unterschreiben.

Da es ganz ohne Code doch nicht geht hörte ich mir zum Abschluss Gregor Trefs Vortrag „Combinator als funktionales Entwurfsmuster in Java 8“ an. Positiv überraschte mich, dass der Vortrag von Anfang an sehr praxisorientiert war und die oft etwas trockene Theorie der funktionalen Programmierung weggelassen wurde. Am Beispiel Eingabevalidierung zeigte Gregor, wie man mit Hilfe von primitiven Funktionen und Kombinatoren immer komplexere Regeln realisieren kann ohne die Lesbarkeit zu verschlechtern. Neben der Präsentation hat er die Methode auch in einem Blogartikel beschrieben.

Fazit: Gerne wieder

Insgesamt ziehe ich von den Clean Code Days ein sehr positives Fazit. Insbesondere die familiäre Atmosphäre war super – da geht es bei größeren Konferenzen oftmals anonymer zu. Ich hatte viele spannende Gespräche während und lernte viele neue Leute kennen.

Die Räumlichkeiten sowie die Organisation waren toll. Das Essen schmeckte allerdings mal wieder zu gut – was der schlanken Linie nicht gerade förderlich ist ;-).

Ein kleiner Wermutstropfen war lediglich, dass sich relativ viele Vorträge eher am Einsteigerniveau und der bekannten Literatur orientierten. Hier wäre es schön, in Zukunft mehr fortgeschrittene Themen sowie Spezialthemen (z. B. Anwenderberichte über Refactoring in regulierten Bereichen wie Medizintechnik) zu sehen.

Insgesamt waren es drei super Tage in München, die Lust darauf machten sich noch mehr mit dem Thema auseinanderzusetzen. Ich freue mich schon auf eine Wiederholung im nächsten Jahr.

Rückblick auf die Night of Patterns bei den Dodneddern

Am Donnerstag war ich bei der „Night of Patterns“ der .Net User Group in den Räumen der Conplement AG in Nürnberg. Wie zu erwarten ging es um Designpatterns aber auch um Antipatterns. Die beiden Moderatoren Gustin und Alex gestalteten das Thema spannend und kurzweilig.

Einführung

Zunächst definierten die Moderatoren den Begriff „Pattern“ und unterschieden dabei zwischen Architektur-, Designpatterns, Idomen sowie Anti-Patterns. Architektur- und Designpatterns sind Lösungsschablonen für wiederkehrende Probleme. Ein Architekturpattern beschreibt dabei die Struktur einer Anwendung, während ein Designpattern einen bestimmten Teilaspekt beschreibt. Ein gutes Beispiel für Design- und Architekturpatterns sind die berühmten Patterns der Gang of Four. Im Gegensatz zu Patterns beziehen sich Idome auf eine bestimmte Programmiersprache oder Technologie. Ein Beispiel ist das Dispose-Pattern in C#. Ein Antipatten ist dagegen eine Schablone für eine schlechte Lösung. Ziel von Antipatterns ist, Erfahrungen über Fehler auszutauschen.

Patterngallerie

Nach dieser Einführung ging es zum Interaktiven Teil des Abends. Die Teilnehmer wurden dazu aufgefordert, (Anti-)Patterns auf einen Post-It zu schreiben und ans Whiteboard zu hängen

Danach wurden Gruppen gebildet und darauf geachtet, dass der Erfahrungsstand der Mitglieder möglichst unterschiedlich ist. Nun durfte sich jede Gruppe ein (Anti-)Pattern auswählen und in Gruppenarbeit eine Flipchartseite darüber erstellen. Die Struktur war vorgegeben. Neben dem Kontext und einer Beschreibung sollte aufgezeigt werden, welche Konsequenzen der Einsatz des entsprechenden Patterns hat. Zudem sollten sich die Teilnehmer Gedanken machen, wann ein Pattern ungeeignet oder auch ein Antipattern geeignet sein könnte.

Nachdem jedes Team ein Pattern ausgearbeitet hatte, starteten alle Teilnehmer zum „Rundgang durch die Patterngallerie“. Dabei stellte jedes Team sein Pattern innerhalb zwei Minuten vor, anschließend gab es vier Minuten Diskussion. Durch die strikte zeitliche Taktung wurde sichergestellt, dass man sich nicht in Detaildiskussionen verliert.

Nach diesem Rundgang war noch ein wenig Zeit für lockere Diskussionen, Fachsimpeln und Erfahrungsaustausch.

Fazit

Auch wenn das Thema Patterns für mich nicht neu ist konnte ich doch die eine
oder andere Idee mitnehmen. Gerade Diskussionen, wann man ein Anti-Pattern
bewusst doch einsetzen kann sind immer wieder spannend. Zudem hat mir der
Rahmen, wie das Thema rübergebracht wurde sehr gut gefallen. Gerade für ein Community-Event wie bei den Doddneddern genau das richtige.

Ich freue mich schon auf das nächste Treffen am 30. März. Thema ist der ReSharper SDK und wie man damit für den ReSharper Plugins erstellt.

© 2017 Alex Rampp

Theme von Anders NorénHoch ↑