Code-Retreat

Retreat, englisch für Rückzug, bezeichnet eine geplante spirituelle Ruhepause oder Rückzug von der gewohnten Umgebung. Weg von unserem Projekt gönnen wir uns einen Tag an dem wir uns ganz und gar auf sauberen Code, gutes Design, TDD und Pair Programming konzentrieren können.

Im Arbeitsalltag nehmen wir uns kaum Zeit, um unsere Fähigkeiten als Softwareentwickler zu verbessern. Ständig sitzt uns der Termin des nächsten Releases im Nacken. Wir nehmen vielleicht hier und da an einer Schulung teil oder arbeiten uns gegebenenfalls in neue Frameworks ein, jedoch arbeiten wir nicht gezielt daran unsere Arbeitsweise zu verbessern oder unser bestehendes Wissen zu vertiefen.

Unter Zeitdruck, fallen wir stets zurück auf Techniken und Methoden, die wir bereits beherrschen, selbst wenn wir wissen, dass es bessere Möglichkeiten gäbe.

Einige Leute bringen an dieser Stelle gerne den Vergleich zu Musikern. Genau wie diese ihre Fingerübungen machen, kann und sollte man auch als Softwareentwickler sein Können trainieren. Statt zu trainieren, geben wir aber jeden Tag ein Konzert.

Code Retreats folgen einigen relativ einfachen Regeln:

 

  • Aufgabenstellung ist Conway's Game of Life
  • In Paaren versucht man das Spiel test-getrieben zu implementieren
  • Das macht man für 45 Minuten. Danach wirft man den geschriebenen Code weg. Keine Backups, kein Commit in ein Repository. Einfach nur löschen.
  • Man nimmt sich ein paar Minuten Zeit, um in der Gruppe darüber zu reflektieren, was man gerade gelernt hat
  • Man fängt wieder von vorne an

Da es eigentlich nicht möglich ist, innerhalb von 45 Minuten fertig zu werden, braucht man gar nicht erst zu versuchen Abkürzungen zu nehmen und kann sich voll und ganz darauf konzentrieren, "sauberen" Code zu schreiben.

Es geht ganz klar nicht darum, die Aufgabenstellung zu lösen, sondern auszuprobieren, wie man anders an die Aufgabenstellung heran gehen könnte als man das bisher gemacht hat. Insbesondere eignet sich das Format auch gerade dazu test-getriebene Entwicklung zu üben. Das Arbeiten in häufig wechselnden Paaren fördert dabei den Informationsaustausch.

Ablauf

Der Ablauf eines Code Retreats hat sich wie folgt eingebürgert.

Sie finden meist samstags statt und werden von einer oder mehreren Firmen gesponsort, die die Räumlichkeiten und Essen bereitstellen. Morgens werden 3 Durchgänge gemacht, dann eine längere Mittagspause und danach noch mal 3 Durchgänge. Danach kann man dann auch gerne noch ein wohlverdientes Bier trinken gehen.

  • 08:00 : Ankunft und Frühstück
  • 08:30 : Einführung durch den Moderator
  • 09:00 : Session #1
  • 09:45 : Retrospektive und Pause
  • 10:00 : Session #2
  • 10:45 : Retrospektive und Pause
  • 11:00 : Session #3
  • 11:45 : Retrospektive und Pause
  • 12:00 : Mittagessen und Networking
  • 13:30 : Session #4
  • 14:15 : Retrospektive und Pause
  • 14:30 : Session #5
  • 15:15 : Retrospektive und Pause
  • 15:30 : Session #6
  • 16:15 : Retrospektive und Pause
  • 16:30 : Abschließende Retrospektive über den Tag, Diskussion
  • 17:00 : Ende (oder auch nicht) 

Experimente

Damit einem nicht langweilig wird, werden häufig in den Sessions am Nachmittag einige Experimente eingebaut. Zum Beispiel:

  • Keine if Statements
  • Keine Schleifen
  • Kurze Methoden (<5 Zeilen, Einzeiler?)
  • Keine primitiven Datentypen
  • TDD as if you meant it
  • Top-Down Design
  • Bottom-Up Design
  • Ohne Maus
  • Tell don't ask - Keine getter und setter
  • funktional, kein Zustand
  • Testmethoden vor bzw. nach dem Schreiben des Tests benennen
  • Pairing games

    • Ping pong: Fix, Fail, Switch
    • Ball & Board: Einer bekommt die Maus, der andere die Tastatur
    • Batting practice: Einer schreibt Tests, der andere fixed sie
    • Timeboxing: Jeder bekommt das Keyboard nur für eine bestimmte Zeit

  • Mache dir bei jedem Schritt klar, welche der folgenden Design Strategien aus Kent Beck's Responsive Design du gerade anwendest

    • Leap
    • Parrallel
    • Stepping Stone
    • Simplification

  • Objekt-Gymnastik (beschrieben in The Thoughtworks Anthology)

    • Nur ein Level Einrückung pro Methode
    • Kein else benutzen
    • Alle primitiven Datentypen und Strings in Objekte verpacken
    • Nur ein Punkt pro Zeile
    • Keine Abkürzungen
    • Behalte alle Dinge klein
    • Keine Klassen mit mehr als zwei Instanzvariablen benutzen
    • Verwende first-class collections
    • Keine getters/setters/properties 

Deutsche Communities auf Twitter