„Wie läuft eigentlich ein Clean Code Development Training ab?“ werden wir immer mal wieder gefragt. Dann versuchen wir zu beschreiben, wie wir mit Übungen und Diskussion und am Flipchart arbeiten.
Clean Code Development braucht hands-on experience, als Trainingsteilnehmer muss man „es“ getan haben. Und zwar nicht zu knapp, in vielen Wiederholungen. Immerhin gilt es, alte Gewohnheiten abzulegen, die fast schon automatisiert in den Fingerspitzen stecken.
Aber auch wenn es um Clean Code geht, dreht sich das Training nicht nur ums Codieren. Damit ließe sich der Code gar nicht genügend sauber gestalten. Wer erst beim Codieren an Clean Code denkt, denkt zu spät daran.
Deshalb müssen wir viel Reden. Clean Code ist das Ergebnis von Diskussion im Team. Auch das will geübt werden. Nein, insbesondere das will geübt werden. Denn „im Reden“ sind Softwareentwickler gewöhnlich nicht so gut. Oder allgemeiner: Im Nachdenken über Lösungen vor dem Codieren sind sie nicht so geübt, vor allem im kollektiven Nachdenken.
Das tut aber Not. Denn wenn am Ende Collective Code Ownership stehen soll, dann reicht es nicht, den Code im Pair Programming zu schreiben. Dazu müssen Reviews kommen (Diskussion!), dazu müssen aber vor allem gemeinsame (!) Analyse der Anforderungen und gemeinsames (!) Nachdenken über den Lösungsansatz kommen (Diskussion!).
Und da solches diskursives Nachdenken nicht so schnell geht und für die meisten Teilnehmer sehr ungewohnt ist, verwenden wir den größten Teil von Clean Code Development Trainings darauf.
Anders als im bisher üblichen Tagesgeschäft der Teilnehmer sind wir allerdings sehr darauf bedacht, dass dieses gemeinsame Nachdenken nicht spurlos bleibt. Dafür hier ein Beispiel aus einem aktuellen Training:
Das ist der Papertrail von zwei Tagen. In denen haben wir uns auf eine Übungsaufgabe konzentriert: eine Anwendung zur Vorhersage von Aufwänden mittels Monte Carlo Simulation.
Was genau all diese Diagramme und Notizen bedeuten, ist hier nicht so wichtig. An dieser Stelle möchte ich Ihnen nur einen visuellen Eindruck davon vermitteln, wie es halt in den Trainings der CCD School zugeht.
Acht Teilnehmer und ich haben im Verlauf von zwei Tagen, also 16 Stunden Training, diese Spur in intensiven Diskussionen produziert – und auch noch implementiert.
Am ersten Tag haben wir ca. 60 Minuten codiert; wir hatten uns nur ein kleines Inkrement zum Einstieg vorgenommen. Am zweiten Tagen waren es 190 Minuten in mehreren Blöcken und sogar arbeitsteilig: ein Teil der Teilnehmer hat sich auf die Simulation konzentriert, ein anderer auf die Vorhersage. Beide Aspekte der Domäne wurden dann als Bibliotheken den anderen zur Integration zur Verfügung gestellt.
So geht es zu in unseren Clean Code Development Trainings. Selbst Männer kommen ins Reden – und fühlen sich gut dabei :-) Und damit nicht nur „daher geredet wird“, zeichnen wir die Gedanken auf. Es ist uns wichtig, dass die Teilnehmer lernen, das, was sie in der Analyse verstehen, anderen visuell vermitteln zu können. Nur so lässt sich ein gemeinsames (!) Verständnis verlässlich erreichen. Dasselbe gilt für ihre Vorstellungen von der Lösung des Problems. Visualisierung, Gedanken auf Papier ausdrücken können, ist das A und O der Softwareentwicklung im Team. Dazu kommen natürlich noch Prinzipien und Konzepte sauberer und agiler Strukturen, doch das Codieren ist am Ende im Grunde der einfachste Teil. Clean Code schreibt sich fast schon von allein ;-)
Wenn Sie jetzt Lust bekommen haben, das auch einmal zu erleben, dann schreiben Sie uns eine Email an info@ccd-school.de und wir schauen, wann wir für Ihr Team das „Trainingslager“ aufschlagen können. Oder Sie machen bei einem Clean Code Retreat mit oder belegen einen Kurs der Clean Code Development Akademie.
[the_ad_group id=“15″]