Wie man ein besserer Entwickler wird! – Erfahrungen eines Code Retreats

Print Friendly, PDF & Email

Wer jahrelang Software entwickelt, hat sich in der Regel bewährte Programmierrezepte erarbeitet oder angeeignet. Doch wie entwickelt man sich selbst noch weiter? Die Software Craftsmanship/Clean Code Communities bieten dafür Ansätze. Eine Methode ist ein Code Retreat. Aber wie darf man sich das vorstellen und wird man als Entwickler dadurch besser?

Setup

Neun Uhr morgens, ein paar Häppchen und dann geht’s los. Mein erster Code Retreat. Ich warte mit etwa 20 Entwicklern gespannt in einem Raum mit Laptops, offener IDE und installiertem Testframework (z.B. JUnit) darauf, dass es los geht…

Warum aber sind wir überhaupt hier? Was hat uns motiviert uns einen Tag lang dem Projektalltag zu entziehen und vom Featuredruck eine Auszeit zu nehmen? Für mich war es die Lust besser zu werden. Besser, das heißt schneller einen korrekten, testbaren, wartbaren und performanten Code zu entwickeln, der die Anforderungen erfüllt.
Dazu hilft ein Rückzug um neue Ansätze zu probieren und alte zu hinterfragen, ohne den Druck einer Deadline. Ein Code Retreat ist ein solcher Rückzug, ein Tag und ein Rahmen, der die Entwickler herausfordert.
Grundlage dieses Rahmens ist die testgetriebene Entwicklung (kurz TDD für ‚Test driven development‘). Jeglicher Code soll testgetrieben entwickelt werden. Der produktive Code entsteht “nebenbei“.

Die Rahmenbedingungen für den Code Retreat setzt ein Moderator, ein erfahrener Entwickler, fit in TDD, der selbst bereits mindestens einmal einen Code Retreat besucht hat. Vorbereitet mit einer Flipchart erklärt dieser das Thema und die Vorgehensweise, stellt eine Aufgabe und lädt mit unterschiedlichen Ansätzen ein diese zu lösen und dabei die eigenen etablierten Programmierrezepte zu hinterfragen.

Perspektivenwechsel

Unsere Aufgabe war es, 45 Minuten lang zu zweit an der Simulation ‚Game of Life‘ mit TDD zu programmieren. Anschließend haben wir uns in der großen Runde ausgetauscht. Dann wurde der ganze Code wieder gelöscht. Ja, gelöscht, was gar nicht so leicht war, denn man hatte ja investiert, sich Gedanken gemacht und versucht eine gute Lösung zu finden. Aber es ist wirklich notwendig wieder bei null anzufangen, um im Kopf offen zu werden für einen neuen Fokus.

Insgesamt haben wir uns bei der Problemlösung auf die folgenden 6 Schwerpunkte – nach obigem Schema und in dieser Reihenfolge – konzentriert.

Entwickeln …

  1. mit TDD und Pairprogramming (zum Aufwärmen)
  2. in einer anderen Programmiersprache/IDE
  3. ohne zu Reden (kommuniziert wurde abwechselnd nur schriftlich über Tests und deren Implementierung)
  4. mit einem Check-in alle 2 Minuten mit grünem Test sonst Rollback
  5. ohne if, then, else oder alternativ TDD as if you meant it
  6. nur mit der Tastatur (ohne Maus)

… immer paarweise, immer mit TDD, immer 45 Minuten und immer mit anschließendem Austausch in großer Runde.

Neue Rezepte

Und was konnte man lernen? Eine ganze Menge, für mich waren es unter anderem die folgenden Erkenntnisse:

  • Wie gut die IDEs TDD unterstützen, z.B. wie in IDEA durch Alt+Enter schnell Code aus dem Test heraus für die Code tragende Klasse/Methode generiert werden kann. Sehr schnell, sehr komfortabel.
  • Wie „Fake it till you make it“ die Schreibblockade nimmt und trotzdem nicht die Qualität der Tests mindert (natürlich ist das nur ein Zwischenschritt aber er hilft Hürden zu nehmen)
  • Wie viel langsamer man in neuen Sprachen Code schreibt, aber auch wie mächtig Testframeworks z.B. in Scala schon sind.
  • Wie wichtig es ist, kleine aussagekräftige Tests zu schreiben, gerade wenn man nicht in der Lage ist direkt zu kommunizieren, wie z.B. mit dem Kollegen der den eigenen Code in 5 Jahren warten muss.
  • Wie schwierig es ist kleine Schritte zu machen (nur 2 Minuten bis zum nächsten grünen Test) aber auch wie gut das Gefühl der Sicherheit ist, wenn man auf einem grünen Test aufsetzt.
  • Wie man tatsächlich auch ohne if/then/else programmieren kann (eine schöne Denksportaufgabe).
  • Wie viel manche Dinge schneller und andere langsamer gehen können, wenn man seine Short-Cuts kennt, bzw. nicht kennt.

Sehr berreichernd war auch die Vielfalt der Erfahrungen. Durch die Rückmeldungen meiner Kollegen, die mit anderen Sprachen, IDEs und Denkansätzen arbeiteten, habe ich viele Eindrücke und Ausblicke mitgenommen und es hat Laune gemacht das Gelernte zu vertiefen.

Da der Fokus nicht war die Aufgabe fertig zu bekommen, sondern zu experimentieren, blieb meine Game of Life Simulation jedoch im Code Retreat unvollendet, aber motiviert durch soviel Input, habe ich das gleich im stillen Kämmerlein nachgeholt.

Wo, wie, wann finden Code Retreats statt?

Wer neugierig geworden ist findet zukünftige Termine und Orte bei der Softwerkskammer über Code Retreats in mehreren deutschen Großstädten. Einmal jährlich findet sogar ein Global Day of Code Retreat statt, an dem rund um den Globus 24 Stunden lang (in Summe über alle Zeitzonen) nach dem Code Retreat Schema programmiert wird und sich die Code Retreat Teilnehmer via Skype auch über die Zeitzonen hinweg austauschen.

Lust bekommen auf einen Code Retreat? Nur zu, es lohnt sich und vielleicht trifft man sich ja auf einem.

Danksagung

Mein Dank geht an Jaroslaw Klose unseren Moderator, der uns kompetent durch den Code Retreat führte, und an Eric Lathrop der in Louisville einen Code Retreat organisierte und mir freundlicherweise ein Bild zur Verfügung stellte, das sehr gut das Setting für einen Code Retreat zeigt.

1 Kommentar

  1. Schön beschrieben, wie ein Code-Retreat abläuft. Ich war bisher noch auf keinem – der Artikel macht aber Lust, das Versäumte bald nachzuholen!

    Was mich noch interessieren würde: Welche Erfahrungen konntest du aus dem Code-Retreat in die tägliche Projekt-Praxis übernehmen? Gerade, wenn in deinem Team vielleicht sonst niemand diese Erfahrungen teilt.

Leave a comment