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