Alex Rampp

Ideenschmiede

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.

Tipps für eine aussagekräftige Versionshistorie

Wenn ich (z. B. in einem neuen Projekt) auf einer bestehenden Code Basis aufbauen soll, wandert mein Blick meist sehr schnell in die Commit-Historie des Versionskontrollsystems. Ich möchte mir damit einen Überblick verschaffen wann welche Features eingebaut wurden, wer an der Code Basis gearbeitet hat und warum gewisse Änderungen vorgenommen wurden.

Leider findet man immer wieder Historien, die so oder so ähnlich aussehen:

bff324d fix bug
a2fd532 first try
765a88f next try
dd876b2 add feature

Mit solchen Commit Messages lässt sich wenig anfangen. Dieser Artikel gibt einige einfache Tipps, die helfen zu einer aussagekräftigen Historie, die einen echten Mehrwert liefert, zu kommen.

Erwartungen an eine gute Historie

Eine gute Historie erzählt eine Geschichte. Nämlich die Geschichte, wie die Software entstanden ist. Sie gibt einen Überblick wann welche Features eingebaut und wann welche Bugs gefixt wurden. Hat man einen Fehler, so lässt sich mit einer guten Historie nachvollziehen, wann und unter welchen Umständen dieser Fehler entstanden. Dadurch kann man lernen, solche Fehler künftig zu vermeiden. Eine gute Historie enthält zudem Informationen warum gewisse Änderungen vorgenommen wurden. Hier kann man auch auf Tickets in Issue Trackern oder Anforderungen verweisen.

Wie man zu einer aussagekräftigen Historie kommt

Die folgenden Beispiele basieren auf dem Versionskontrollsystem git. Sie lassen sich aber auch auf andere Systeme übertragen.

Verständliche Commit Messages

Eine verständliche Commit Message beantwortet folgende Fragen:

  • Warum ist die Änderung nötig?
  • Was trägt diese Änderung zur zu implementierenden Anforderung aus?
  • Welche Seiteneffekte hat diese Änderung?

Zudem sollte man gewisse Formatierungsregeln einhalten. Die wichtigsten Regeln sind:

  • Separiere die Überschrift vom Textkörper mit einer Leerzeile
  • Limitiere die Überschrift auf 50 Zeichen
  • Zeilenlänge des Textkörpers sollte nicht länger als 72 Zeichen sein

Diese Regeln sind im Git Umfeld etabliert und viele Tools bauen darauf auf. Hält man sich daran, kann jeder die Historie einwandfrei lesen und durchsuchen.

Hier ein Beispiel für eine aussagekräftige und dennoch kurze Commit-Message

tcp: tcp_probe: use spin_lock_bh()

tcp_rcv_established() can now run in process context.

We need to disable BH while acquiring tcp probe spinlock,
or risk a deadlock.

Fixes: 5413d1b ("net: do not block BH while processing socket backlog")
Signed-off-by: Eric Dumazet 
Reported-by: Ricardo Nabinger Sanchez 
Signed-off-by: David S. Miller 

Quelle: Linux Kernel, Commit e70ac17

Atomare Commits

Es gibt Entwickler, die committen erst wenn ein Feature komplett „fertig“ ist. Dadurch entstehen meist sehr große Commits. Diese Commits haben verschiedene Probleme:

  • Sie sind schwer zu lesen, weil sie meist viele verschiedene Änderungen enthalten.
  • Einzelne Änderungen können nicht einzeln referenziert werden (z. B. beim Cherry Picking)
  • Da große Commits viele Änderungen enthalten, müssten auch die Commit Messages entsprechend lang sein. Meist wird aber darauf aus Bequemlichkeit verzichtet, hier alle Änderungen aufzuführen.

Ein atomarer Commit dagegen ist in sich abgeschlossen und liefert einen Mehrwert für die zu lösende Aufgabe. Wird ein Feature in mehreren atomaren Commits entwickelt so ist viel besser nachvollziehbar, wie ein Feature (oder auch ein Bug) entstanden ist. Code Reviews gestalten sich einfache und Techniken wie Cherry Picking oder Bisecting können sinnvoll angewendet werden.

Single Purpose Branches

Fängt man ein neues Feature, Bugfix, Refactoring o.ä. an, so ist es sinnvoll zunächst einen neuen Branch zu erstellen. Das hat den Vorteil, dass man auf einer stabilen Basis arbeitet. Würden alle Entwickler auf dem master-Branch arbeiten, wäre die Wahrscheinlichkeit sich in die „Quere“ zu kommen recht hoch.

Diese Entwicklungsbranches sollten kurzlebig und auf ein Thema beschränkt sein. Dadurch ist die Wahrscheinlichkeit von Merge-Konflikten gering und die neuen Funktionen stehen schnell allen Entwicklern zur Verfügung. Diverse Git Tools zeigen Branches grafisch an, wodurch schön nachvollziehbar ist, was wann entwickelt und gemerged wurde.

History neu schreiben

Gerade bei schwierigen Refactorings arbeite ich oft mit sehr kleinen („sub-atomaren“) Commits. Dabei kann es durchaus vorkommen, dass der Code bei bestimmten Versionsständen nicht einmal kompiliert. Solche Versionen möchte man natürlich nicht veröffentlichen. Sie helfen aber, eine große Aufgabe (z. B. Refactoring einer zentralen Komponente) handhabbar zu machen.

Möchte man die Änderung nun anderen Entwicklern zur Verfügung stellen, ist es ratsam, die Historie „glatt zuziehen“ sodass keine nicht-funktionierenden Versionsstände existieren und oben genannte Punkte eingehalten sind.

Dazu bietet Git mehrere Möglichkeiten:

  • Mit git commit --amend kann man den letzten Commit schnell und einfach ändern
  • Mit git merge --squash <feature branch> fasst man alle commits von „<feature branch>“ zu einem einzigen zusammen.
  • Mit git cherry-pick <commit> kann man einzelne Commits auf einen Branch anwenden.
  • Mit git rebase -i HEAD~3 lassen sich die letzten drei Commits nachbearbeiten. Durch den Parameter -i wird interaktives Rebasing gestartet. Mit Hilfe der folgenden Dialoge lassen sich Commits ändern, zusammenfassen, splitten, neu sortieren oder löschen.

Einen detaillierteren Überblick über die Möglichkeiten, die Historie zu bearbeiten findet man hier.

Fazit

Es ist durchaus sinnvoll der Historie eine gewisse Beachtung zu schenken. Auch wenn zu Projektbeginn meist alles klein und übersichtlich ist, ist es auf lange Sicht sinnvoll sich von Anfang an um eine aussagekräftige Historie zu kümmern. Wie in diesem Artikel gezeigt, reichen dazu ein paar einfache Regeln. Der Software-Archäologe, der sich die Code Basis in zehn Jahren anschaut wird es einem sicher danken.

In 30 Tagen Zeichnen lernen – ein Rückblick

Mit dem Januar endete auch meine Herausforderung „30 Gesichter in 30 Tagen zeichnen“. Ich habe vorher noch nie ernsthaft gezeichnet und bin auch nicht mit einem großen Talent in dieser Richtung gesegnet. Durch diese Herausforderung wollte ich einfach mal wissen, was man innerhalb von 30 Tagen lernen kann, wenn man einfach beharrlich dran bleibt.

Was habe ich gemacht?

Insgesamt wurden im Januar 25 Bilder von mir gezeichnet und hier auf dem Blog veröffentlicht. Die meisten Bilder wurden zudem auf meinem Twitter sowie meinem Instagram Account veröffentlicht. Gerade in den Social Media Kanälen bekam ich viele Likes und nette Kommentare was sehr motivierend wirkte.

Ziel dieser Herausforderung war, die Grundlagen des Zeichnens zu leren da ich zuvor noch nie ernsthaft gezeichnet habe. Warum ich zeichnen lernen will? Einfach weil es faszinierend ist und mich begeistert.

Was habe ich gelernt?

Gelernt habe ich dabei vor allem, dass man die Grundlagen des Zeichnens unabhängig von Talent lernen kann. Es erfordert lediglich Geduld, sowie die Beharrlichkeit nicht gleich beim ersten Misserfolg aufzugeben. Allerdings fiel mir nach den ersten Erfolgen schnell auf, dass es bis zu einem guten Porträt ein sehr weiter (aber nicht unerreichbarer) Weg ist.

Des Weiteren war es eine schöne Erfahrung, etwas „einfach mal zu machen“. Ich habe meist viele Ideen und denke in der Regel so lange darüber nach, bis ich einen Grund finde es doch nicht zu machen. Auf diese Erfahrung werde ich in Zukunft bauen und Sachen schneller anpacken.

Mit der Zeit fiel mir auf, dass ich meine Umgebung anders wahrnehme. Ich achte automatisch viel mehr auf Formen, Perspektiven, Licht und Schatten. Das ist vor allem bei meinem anderen Hobby, der Fotografie, ein großer Vorteil. Durchs Zeichnen werde ich zu einem besseren Fotografen.

Fazit & Ausblick

Meist machte mir die Zeichenchallenge rießen Spaß. Einfach am Abend nach der Arbeit nochmal hinsetzen und etwas kreatives Schaffen ist eine tolle Sache. Manchmal wars auch hart und am Schluss verlor ich doch ein wenig die Lust.

Vor allem die Beschränkung auf Gesichter war ein Hinderniss. Mir fiel mit der Zeit immer mehr auf, dass ich an den Grundlagen arbeiten muss. Deshalb zeichnete ich gerade in der zweiten Hälfte hauptsächlich Details (Mund, Nase, Ohren, Augen). Hierbei konnte ich mich voll und ganz auf eine Sache konzentrieren.

Als nächsten Schritt werde ich komplett zu den Grundlagen zurückkehren. Insbesondere am Perspektivischen Zeichnen und an Schattierungstechniken muss ich arbeiten. Des Weiteren möchte ich in Zukunft das Zeichnen per Stylus und Tablet ausprobieren.

Abschließend kann man sagen, dass diese Zeichenchallenge eine echte Herausforderung war, die mich ein gutes Stück weiter gebracht hat. Zudem habe ich dadurch ein neues, wunderschönes Hobby entdeckt.

Ein realistisches Ohr zeichnen Teil 2

Der zweite Versuch, ein realistisches Ohr zu zeichnen ist wesentlich besser gelungen:

Bleistiftzeichnung eines Ohrs

Dieser Post ist Teil einer Challenge „30 Gesichter in 30 Tagen zeichnen“.

Ein realistisches Ohr zeichnen

Heute habe ich mich an einem Tutorial zum Zeichnen eines realistischen Ohrs versucht. Gelinde gesagt, ist da noch viel Luft nach oben:

Bleistiftzeichnung eines menschlichen Ohrs

Die Grundformen habe ich eigentlich ganz gut erfasst. Das Problem ist, dass die Konturen zu hart sind und die Schattierungen überhaupt nicht passen. Auf der Website des „Ohrentutorials“ befindet sich ein ausführliches Tutorial zum Thema Schattierungen. Ich denke, das sollte ich demnächst durcharbeiten.

Dieser Post ist Teil einer Challenge „30 Gesichter in 30 Tagen zeichnen“.

Mondsüchtig

Dieser Post ist Teil einer Challenge „30 Gesichter in 30 Tagen zeichnen“.

So langsam wird die Zeichenchallenge echt hart. Mir fehlen derzeit einfach die Ideen. Heute habe ich einfach mal drauflos gezeichnet. Dabei kam eine Art „Maskengesicht“ raus. Ich weiß selbst nicht was ich davon halten soll, aber der Gesichtsausdruck gefällt mir:


Dieser Post ist Teil einer Challenge „30 Gesichter in 30 Tagen zeichnen“.

Auge

Heute habe ich nur sehr wenig Zeit,deshalb gibt es nur eine kurze Skizze eines Auges,die in einer wackelnden S-Bahn gezeichnet wurde.

Bleistiftzeichnung eines Auges
Dieser Post ist Teil einer Challenge „30 Gesichter in 30 Tagen zeichnen“.

Mund im Seitenprofil

Gestern wurden Nasen geübt, heute ist das Organ unterhalb der Nase dran.

Bleistiftzeichnung von zwei Mündern im Seitenprofil

Dieser Post ist Teil einer Challenge „30 Gesichter in 30 Tagen zeichnen“.

« Ältere Beiträge

© 2017 Alex Rampp

Theme von Anders NorénHoch ↑