Coding Skills spielend leicht verbessern

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:in 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 Musiker:innen. Genau wie diese ihre Fingerübungen machen, kann und sollte man auch als Developer 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 testgetrieben 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, testgetriebene 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: Eine:r bekommt die Maus, eine:r die Tastatur
    • Batting practice: Eine:r schreibt Tests, eine:r fixed sie
    • Timeboxing: Jede:r 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
    • Parallel
    • 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

Unser it-agile Lagerraum

Möchten Sie mehr erfahren?

Tauschen Sie sich mit unseren Expert:innen aus und lassen sich zu Schulungen, Coaching oder Wissensthemen beraten.

 

+ 49 40 4135 848-0    info@it-agile.de    Online Termin buchen

Agile Coaching von it-agile

Kennen Sie eigentlich schon it-agile?

Die Expert:innen zu agiler Arbeit und agilen Methoden

Kund:innen wollen begeistert werden. Mit innovativen Produkten, durch Schnelligkeit, Transparenz und auch Verlässlichkeit. Unsere erfahrenen Agile Coaches sorgen gemeinsam mit Ihren Teams und Führungskräften dafür, auch in komplexer Umgebung Ihre Ziele nicht aus dem Auge zu verlieren und implementieren die richtigen agilen Methoden für nachhaltige Veränderung.

  • Wir integrieren Pragmatismus mit Idealismus
  • Wir befähigen Sie nachhaltig ohne Abhängigkeit von uns
  • Wir erzeugen Kundenfokus mit wirkungsvoller Agilität
agile review Magazin

agile review

Unser Kundenmagazin 

In unserem Magazin stellen wir Artikel rund um agiles Arbeiten für Sie zusammen. Das Spektrum reicht von methodischen Themen wie Scrum und Kanban über Agile Leadership bis hin zu technischen Aspekten wie agilem Testen und flexiblen Architekturen.

  • Als Abo oder Einzelausgabe erhältlich
  • Digital oder Print
  • Einzelne Artikel sofort digital verfügbar

Wissens- und Lesenswertes

Das könnte Sie zu Agiler Arbeit auch interessieren

Agile Teams

Ein Haufen abhängiger agiler Teams ergibt noch kein agiles Unternehmen. Die übergreifenden Themen führen zu extremen Overhead, schlechter Vorhersagbarkeit und langsamer Time-To-Market. Diese Probleme…

Agile Teams

Wir hören immer mal wieder, dass Entwickler:innen Scrum hassen - wegen der vielen Meetings. Was steckt dahinter?

Agile Entwicklung

DORA (DevOps Research and Assessment) ist ein wissenschaftliches Studienprogramm, das unser Kollege Andreas Havenstein zur Weiterentwicklung von Teams angewandt hat.

it-agile Newsletter

Sichern Sie sich regelmäßige Neuigkeiten, Inspiration und Tipps zu agiler Arbeit, Konferenzen, aktuelle und neue Termine für unsere Schulungen sowie vieles mehr.


* Benötigte Angaben