Vorlage für Coderetreat mit Beispiel Sessions

1. CODERETREAT
Ramon Anger
Bildquelle: Echino / pixelio.de

2. Facilitator
Ramon Anger
• Technischer Architekt und
Agiler Coach bei Capgemini
• Berufserfahrung seit 1997 bei
debis Systemhaus, T-Systems,
TomTom, Materna und Capgemini
• Diplominformatiker (FH),
Master of Computer Science,
Doktorand
• Schneeberg (Erzgebirge)

3. Mythen über Entwickler
• Arbeiten gern allein
• Verlassen nie ihre Komfortzone
• Fokussieren sich nur auf die tägliche Arbeit
• Vernachlässigen Tests
• Haben keine Zeit, Dinge auszuprobieren
• Sind nicht bereit, neue Praktiken zu erlernen
• Denken nicht über Design nach
• Konzentrieren sich darauf, Dinge abzuschließen
• Neigen zu Over-Engineering
• Refaktorisieren nie
Bildquelle: Lisa Spreckelmeyer / pixelio.de

4. In der Realität müssen Entwickler ihre
Fähigkeiten verbessern
• Was bedeutet Praxis für einen Entwickler?
1. Ausprobieren
2. Feedback einholen/geben
3. Wiederholen
• Wieder und wieder und wieder … ganz ohne Druck.
• Aufgaben nicht um jeden Preis abschließen, sondern
verstehen und meistern.
Bildquelle: uschi dreiucker / pixelio.de

5. Coderetreat heißt
• Lernen durch Pair Programming
• Verlassen der Komfortzone
• Ohne Druck der täglichen Arbeit
• Experimentieren
• Neue Praktiken erlernen
• Über Design nachdenken
• Dinge einfach gestalten
• Entwickeln, wenn notwendig
• Refaktorisieren
• Perfekten Code schreiben
Bildquelle: Echino / pixelio.de

6. Coderetreat heißt
• 1 Tag entwickeln
• 6 X 45 Minuten Sessions
• Pair Programming
• Test Driven Development
• Neue Partner in jeder Session
• Verschiedene Bedingungen in jeder Session
• Code löschen
• Jede Sprache mit Testframework ist erlaubt
• Spaß haben
Bildquelle: Echino / pixelio.de

7. Coderetreat Ablauf
Session 1 10 – 11 Uhr
Session 2 11 – 12 Uhr
Session 3 12 – 13 Uhr
Mittagspause 13 – 14 Uhr
Session 4 14 – 15 Uhr
Session 5 15 – 16 Uhr
Session 6 16 – 17 Uhr
Retrospektive 17 – 17.30 Uhr
Bildquelle: Karl-Heinz Laube / pixelio.de

8. Session Ablauf
Warum immer wieder
wiederholen?
• Der Code ist nicht wichtig.
Fokussiere auf den
Schwerpunkt der einzelnen
Sessions
• Wichtig ist, über das Design
nachzudenken
• Konzentriere dich auf TDD
und benenne die Testfälle
richtig
45 Minuten Coding
10 Minuten
Retrospektive
5 Minuten Pause
Bildquelle: Karl-Heinz Laube / pixelio.de

9. Pair Programming
• Warum im Paar entwickeln?
• gemeinsam am Code arbeiten
• beide sollen gleichermaßen lernen
• gut kommunizieren
• weniger Fehler
• kleinere Programme
• disziplinierteres Arbeiten
• Pilot & Navigator
Pilot: Mouse & Tastatur
• Navigator: Vorgehen & Tipps
• Wechsel der Rollen nach jeder Methode
Bildquelle: gabriele Planthaber / pixelio.de

10. Coderetreat Regeln – Test Driven Design
“TDD doesn't drive good design. TDD
gives you immediate feedback about
what is likely to be bad design. If a
test is hard to write, if a test is
non-deterministic, if a test is slow,
then something is wrong with the
design.”
Kent Beck
• Schreibe nur neuen Code, wenn ein
automatisierter Test fehlgeschlagen
ist
• Beseitige Duplikate
Bildquelle: https://commons.wikimedia.org/wiki/File:Living_Crash_Test_Dummies_2.jpeg

11. Coderetreat Regeln – Einfaches Design
Das Team passt das Design der
Lösung exakt an die beabsichtigte
Funktionalität des Systems an.
1.Alle Tests sind erfolgreich
2.Es gibt keine Duplikate im Code
3.Code tut, was er ausdrückt
4.So wenig Code wie möglich
In dieser Reihenfolge.
Bildquelle: Rainer Sturm / pixelio.de

12. Session Regeln – Neue Partner in jeder
Session
• Warum sollen die Paare tauschen?
• voneinander lernen – neue Sicht- und Arbeitsweisen
und Lösungswege
• mit veränderten, ungewohnten Rahmenbedingungen
umgehen lernen
• aufeinander einstellen
Bildquelle: Matthias Preisinger / pixelio.de

13. Session Regeln - Code löschen
• Warum soll ich den Code löschen?
• Es geht um dich, aber Du bist nicht dein Code
• Du sollst Erfahrung sammeln, nicht die Aufgabe
abschließen
• Versuche langsam zu arbeiten und dich darauf zu
konzentrieren, besser zu werden
Bildquelle: Dirk Kruse / pixelio.de

14. Coderetreat – Historie
• Die Idee wurde auf der CodeMash Conference 2009 das erste Mal verbreitet.
• Idee zum Coderetreat kam von
• Gary Bernhardt
• Patrick Welsh
• Nayan Hajratwala
• Corey Haines
• Fokus
• Wiederholbar
• Intensiver ganzer Tag
• Grundlagen der Programmierung praktizieren

15. Game of Life
• Game of Life ist ein zellulärer Automat
• der 1970 vom Mathematiker John Conway entwickelt wurde.
• Game of Life wird ohne Spieler gespielt.
• Man erzeugt einen initialen Zustand
• und beobachtet, wie er sich entwickelt.

16. Game of Life - Realität
• Die Realität des Game of Life ist ein unendlich großes zweidimensionales Feld
quadratischer Zellen. Jede Zelle hat zwei mögliche Zustände – tot oder lebendig.

17. Game of Life – Regeln
• In jeder Generation interagiert jede Zelle nach den folgenden drei Regeln mit
ihren acht Nachbarzellen.

18. Game of Life – Regel eins
• Eine tote Zelle mit genau drei lebendigen Nachbarn wird lebendig.

19. Game of Life – Regel zwei
• Eine lebendige Zelle mit zwei oder drei lebendigen Nachbarn bleibt in der
nächsten Generation lebendig

20. Game of Life – Regel drei
• In allen anderen Situationen stirbt die Zelle an Einsamkeit oder Einengung.

21. Game of Life – Regeln
• Eine lebendige Zelle mit zwei oder drei lebendigen Nachbarn bleibt in der
nächsten Generation lebendig
• Eine tote Zelle mit genau drei lebendigen Nachbarn wird lebendig.
• In allen anderen Situationen stirbt die Zelle an Einsamkeit oder Einengung.

22. Game of Life - Hintergrund
• Game of Life ist ein Beispiel für veränderndes Verhalten.
• Das Verhalten des Systems als Ganzes kann nur mit einem Blick auf das Verhalten
einzelner Zellen des Systems nicht vorhergesagt werden.
Quelle: http://en.wikipedia.org/wiki/File:Gospers_glider_gun.gif

23. Coderetreat – Ziel
• Das Ziel eines Coderetreat ist es nicht, das Game of Life
vollständig zu implementieren, sondern die mit den
Sessions verbundenen Praktiken so gut und so einfach
wie möglich umzusetzen …
• … und Spaß haben
Bildquelle: Dirk Kruse / pixelio.de

24. Coderetreat – Bei Fragen
bitte fragen
Bildquelle: http://farm5.staticflickr.com/4125/5159595678_7ff93e58b3_z.jpg

25. Session 1 – Warm-up Session
– Conways Game of Life
• kennenlernen, verstehen und ausprobieren
• Spiel und Regeln kennenlernen
• TDD, Pair Programming und einfaches Design praktizieren
Bildquelle: NicoLeHe / pixelio.de

26. Retrospektive – Wie gut ist die erste
Session gelaufen?
• Wie gut ist das Hineindenken in das Game of Life gelungen?
• Wie leicht ist die Nutzung von TDD gefallen?
• Wie leicht ist es, zuerst den Testfall und dann den Code zu schreiben?
• Welchen Eindruck hat Pair Programming hinterlassen?
• Wie leicht fällt es, einfaches Design zu nutzen?
• Wie effektiv war die erste Session?
• Wie einfach war es, verständlichen Code zu schreiben?
• Was hätte besser/einfacher sein können?
• Was soll in der zweiten Session anders laufen?
Bildquelle: http://commons.wikimedia.org/wiki/File:Bugs_January_2007-1.jpg

27. Session 2 – Keine Methode hat einen
Rückgabewert
• Keine der verwendeten Methoden darf einen Rückgabewert haben
• Testfälle müssen den inneren Zustand einer Klasse prüfen
• Diese Praktik ist ein Anti-Pattern für Objektorientierte Programmierung
• Sie soll Teilnehmern bewusst machen, dass diese Vorgehensweise die
Testbarkeit von Code behindert
Bildquelle: Rainer Sturm / pixelio.de

28. Session 3 – Evil muted Coder
• Der erste Kollege schreibt einen Test
• Der zweite Kollege schreibt Code, der den Test gerade so erfüllt
• Der erste Kollege passt den Test so an, dass der zweite den Code verbessern
muss …
• Wechselspiel so lange, bis der Testfall gut genug ist, dass er wirklich die
erwartete Funktionalität testet
• Viele Tests in der Realität testen nichts
• Die Session soll verdeutlichen, wie schwer es ist, gute, aussagekräftige Tests
zu schreiben
Bildquelle: Rainer Sturm / pixelio.de

29. Mittagspause
Bildquelle: Rainer Sturm / pixelio.de

30. Session 4 – Spielfeld mit Grenze
• Conways Game of Life geht von einem zwei-dimensionalen Spielfeld ohne
Abgrenzung aus
• In dieser Praktik werden Grenzen und das Verhalten der Zellen an diesen
Grenzen berücksichtigt
• Die Begrenzung des Spielfelds führt zu einem veränderten Verhalten des
Systems und einer damit verbundenen veränderten Testmethodik
Bildquelle: Marc Holzapfel / pixelio.de

31. Session 5 – Statusbasiertes Testen
• Mit Fokus auf einzelne Objekte oder Methoden wird geprüft, ob
angenommene Eingangsparameter zu erwarteten Ausgangsparametern
führen
• Unit-Tests werden häufig statusbasiert durchgeführt und vernachlässigen den
übergreifenden Zusammenhang des Codes
• Mit dieser Praktik sollen den Teilnehmern die Grenzen dieses Ansatzes
bewusst gemacht werden
Bildquelle: Dieter Schütz / pixelio.de

32. Session 6 – Interaktionsbasiertes Testen
• Fokus ist Interaktion von Objekten miteinander
• Die Granularität der Tests ist gröber als beim Statusbasierten Testen und
kann als eine einfache Form des Integrationstests interpretiert werden
• Der Fokus liegt weniger auf der einzelnen Methode
• Unit-Tests werden für Integrations- bzw. Akzeptanztests verwendet
Bildquelle: Karl-Heinz Laube / pixelio.de

33. Retrospektive / Abschluss
• Was hast du heute gelernt?
• Was hat dich heute überrascht?
• Was wirst du ab morgen anders/besser machen?
Bildquelle: wobigrafie / pixelio.de