Downloaden Sie, um offline zu lesen
Hochgeladen vonRamon Anger
Coderetreat Vorlage
Das Dokument beschreibt ein Coderetreat, geleitet von Ramon Anger, bei dem Entwickler ihre Fähigkeiten durch wiederholtes Pair Programming und Test-Driven Development (TDD) verbessern sollen. Es umfasst verschiedene Sessions, die auf Experimente und Designfokus abzielen, um den Teilnehmern zu helfen, aus ihrer Komfortzone auszubrechen und gemeinsam an Code zu arbeiten. Das Ziel ist es, nicht nur ein Projekt zu vollenden, sondern auch Spaß zu haben und effektive Praktiken zu erlernen.
![Brunner[1]](https://cdn.slidesharecdn.com/ss_thumbnails/brunner1-141127092629-conversion-gate02-thumbnail.jpg?width=640&height=640&fit=bounds)
Coderetreat Vorlage
- 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ätmü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 Session1 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 Warumimmer 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 – BeiFragen 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 – Wiegut 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: RainerSturm / 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