Wednesday, February 9, 2011

Code Retreat - was ist das?

Labels: ,
Edit: es hat sich viel getan. Code Retreats finden mittlerweile ziemlich häufig statt. Auf der Seite der Softwerkskammer findet man mehr dazu. Die Veranstaltungen sind immer kostenlos und es lohnt sich auf jeden Fall, mal teil zu nehmen.


Vor kurzem habe ich an einem Code Retreat teilgenommen (Leo gibt für "retreat" u.a. Klausurtagung, was das ganze einigermaßen trifft) und war davon sehr angetan. Ich plane gerade, selbst einen solchen Event zu organisieren und im Zuge dessen lohnt es sich einmal ein paar erklärende Worte auf deutsch zu schreiben.

Ich bediene mich dabei sehr ausgiebig bei dem was Corey Haines und andere schon zu diesem Thema geschrieben haben. Am Ende dieses Artikels verweise ich auch noch auf einige weiterführende englische Seiten.

Was ist das Problem?

Im normalen Arbeitsalltag wird kaum Zeit darauf verwendet, seine Fähigkeiten zu verbessern. Man nimmt vielleicht hier und da an Schulungen teil oder arbeitet sich gegebenenfalls in neue Frameworks ein. Aber wir arbeiten nicht gezielt daran unsere Arbeitsweisen zu verbessern oder unser bestehendes Know-How zu vertiefen.

Und wenn wir dann unter Zeitdruck stehen, fallen wir zurück auf die Techniken, die wir beherrschen, auch wenn wir wissen, dass es bessere Möglichkeiten gibt. Das klassische Beispiel hier sind Software-Tests. Es ist nahe liegend, dass ein Projekt mit hoher Testabdeckung mehr Sicherheit beim hinzufügen von Änderungen bringt. Damit aber sowohl die eigentliche Testabdeckung, als auch das Durchführen von Änderungen mit einem vertretbaren Aufwand erreicht werden können, braucht es einiges an Erfahrung und Übung. Und wenn man diese Erfahrung nicht hat und der nächste wichtige Termin naht, ist es dann doch einfacher, die Tests zu ignorieren und direkt drauf los zu programmieren.

Einige Leute bringen an dieser Stelle auch gerne den Vergleich zu Musikern. Genau wie diese ihre Fingerübungen machen, kann man auch als Entwickler sein Können trainieren. Statt dessen geben wir aber jeden Tag ein Konzert. Das hat natürlich auch seinen Wert und man wird auch nicht vermeiden können sich hier und da zu verbessern. Man kann sich wahrscheinlich auch eine ganze Weile diesem Trott hingeben. Aber irgendwann nimmt einem die Eintönigkeit dann doch die Freude an der Arbeit.

An dieser Stelle kann man auch gleich einen Strich ziehen. Wer mit seinem Können zufrieden ist und sich damit wohlfühlt, sollte wohl nicht weiter lesen. Zufriedenheit ist schwer genug zu erreichen. Lernen sollte freiwillig und aus eigenem Interesse passieren.

Was kann man tun?

Wenn man sich bewusst die Zeit nimmt, gibt es eine Menge Dinge die man tun kann. Eine gute Möglichkeit, die vor kurzem in der GOOS-Mailingliste erwähnt wurde ist, sich gelegentlich einfach mal eine halbe Stunde Zeit zu nehmen, bestehenden Code zu verbessern. Dies sollten wirklich nur kleine Änderungen sein und man sollte sich an seine Zeitvorgabe halten. Ist man nach dieser Zeit nicht mit dem Ergebnis zufrieden, verwirft man seine Änderungen. Da dies ja primär als Weiterbildung zu sehen ist, sollte man gar nicht davon ausgehen wirklich Code zu committen. Und wenn dann doch eine Verbesserung dabei heraus kommt, umso besser!

Mehr und mehr finden sich auch Code Katas im Netz. Hier werden überschaubare Aufgabenstellungen wieder und wieder gelöst, um in ähnlichen Alltagssituationen praktisch reflexartig darauf reagieren zu können. Diese sind sowohl ein guter Weg selber zu üben, als auch interessant anzuschauen. Es gibt eine ganze Reihe von Leuten, die freundlicherweise ihre Lösungen im Netz bereit stellen, zum Teil auch als Screencasts. (http://codingkata.org/ http://www.katacasts.com/ http://codersdojo.org [Link aus dem Kommentar hinzugefügt]) Gerade für Einblicke in neue Programmiersprachen sind konkrete, bekannte Beispiele sehr hilfreich.

Überhaupt ist natürlich die Zusammenarbeit mit anderen wahrscheinlich die beste Möglichkeit, neue Dinge zu lernen.

Darüber hinaus gibt es natürlich auch noch andere Dinge. Unter anderem halt Code Retreats, sonst würde ich ja nicht diesen Artikel schreiben.

Was sind jetzt also Code Retreats?

Code Retreats folgen einigen relativ einfachen Regeln:
  • Aufgabenstellung ist Conways Spiel des Lebens
  • Mittels pair-programming und, nach Möglichkeit, test-getrieben, versucht man das Spiel zu implementieren
  • Das macht man für 45 Minuten. Danach wirft man den geschriebenen Code weg. Keine Backups, kein committen in ein Repository. Einfach nur löschen
  • Man nimmt sich ein paar Minuten Zeit, um in der Gruppe darüber zu reden, was man gelernt hat
  • Man fängt wieder von vorne an (6-7 mal)
Da es eigentlich nicht möglich ist, innerhalb von 45 Minuten fertig zu werden, braucht man gar nicht erst zu versuchen, Abkürzungen zu nehmen und kann sich nur darauf konzentrieren, "perfekten" Code zu schreiben. Es macht auch nichts, für einen Durchlauf eine komplett neue Herangehensweise auszuprobieren (z.B. keine else-Blöcke, keine primitives, nur Funktionen/keine Objekte, keine Methoden mit mehr als zwei Zeilen, ...). Egal was man probiert, man riskiert im Durchschnitt nur 22,5 Minuten.

Es geht ganz klar nicht darum, die Aufgabenstellung zu lösen, sondern auszuprobieren, wie man anders an die Aufgabenstellung heran gehen kann. Insbesondere eignet sich das Format auch gerade dazu test-getriebenes Entwickeln zu üben.

Für mich war außerdem auch sehr interessant zu sehen, dass der entstandene Code nur einen Teil des Produkts der 45 Minuten ausmachte. Das entstandene Wissen über die konkrete Problemstellung brachte jeden neuen Durchgang deutlich näher an das Ziel als den Vorherigen.

Weiterführendes

Posted by Daniel Temme at 15:06