Coderetreat Vorlage

CODERETREATRamon Anger

Bildquelle: Echino / pixelio.de

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)

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

In der Realität müssen Entwickler ihre Fähigkeiten verbessern

• Was bedeutet Praxis für einen Entwickler?

1. Ausprobieren2. Feedback einholen/geben3. 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

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

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

Coderetreat Ablauf

Session 2 11 – 12 Uhr

Session 3 12 – 13 Uhr

Mittagspause 13 – 14 Uhr

Session 4 14 – 15 Uhr

Session 5 15 – 16 Uhr

Retrospektive 17 – 17.30 Uhr

Session 6 16 – 17 Uhr

Session 1 10 – 11 Uhr

Bildquelle: Karl-Heinz Laube / pixelio.de

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

5 Minuten Pause

10 Minuten Retrospektive

Bildquelle: Karl-Heinz Laube / pixelio.de

Pair Programming

• Warum im Paar entwickeln?

• gemeinsam am Code arbeiten• beide sollen gleichermaßen lernen• gut kommunizieren

• weniger Fehler• kleinere Programme• disziplinierteres Arbeiten

• Pilot & NavigatorPilot: Mouse & Tastatur

• Navigator: Vorgehen & Tipps

• Wechsel der Rollen nach jeder Methode

Bildquelle: gabriele Planthaber / pixelio.de

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

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 erfolgreich2.Es gibt keine Duplikate im Code3.Code tut, was er ausdrückt4.So wenig Code wie möglich

In dieser Reihenfolge.

Bildquelle: Rainer Sturm / pixelio.de

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

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

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

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.

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.

Game of Life – Regeln

• In jeder Generation interagiert jede Zelle nach den folgenden drei Regeln mit ihren acht Nachbarzellen.

Game of Life – Regel eins

• Eine tote Zelle mit genau drei lebendigen Nachbarn wird lebendig.

Game of Life – Regel zwei

• Eine lebendige Zelle mit zwei oder drei lebendigen Nachbarn bleibt in der nächsten Generation lebendig

Game of Life – Regel drei

• In allen anderen Situationen stirbt die Zelle an Einsamkeit oder Einengung.

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.

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

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

Coderetreat – Bei Fragen bitte fragen

Bildquelle: http://farm5.staticflickr.com/4125/5159595678_7ff93e58b3_z.jpg

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

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

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

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

Mittagspause

Bildquelle: Rainer Sturm / pixelio.de

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

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

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

Retrospektive / Abschluss

• Was hast du heute gelernt?

• Was hat dich heute überrascht?

• Was wirst du ab morgen anders/besser machen?

Bildquelle: wobigrafie / pixelio.de