CCD-Praktikum – Wie war’s?

Vor einer Woche hatte ich das Clean-Code-Developer-Praktikum in München mitgemacht. Die Teilnahme war der Lohn für die Lösung der vorgeschalteten Bewerbungsaufgabe von Ralf Westphal und Stefan Lieser. 

Kennenlernen

Montag früh um 9:00 sind wir gestartet. Zusammen mit 4 weiteren Mitstreitern habe ich die Dozenten Ralf Westphal und Stefan Lieser persönlich kennengelernt. Nach der Vorstellungsrunde, in der jeder Teilnehmer kurz etwas über sich erzählte, war mir klar, das Niveau dieser Truppe ist überdurchschnittlich hoch. Wie sich noch herausstellte, galt dies auch für unsere Motivation.

Schnell hatten Ralf und Stefan uns eröffnet, dass wir an einem Experiment teilnahmen. Die beiden wollten ihr Vorgehensmodell für die Softwareentwicklung im Feldversuch erleben. Ihr Vorgehen beruht natürlich auf den Grundsätzen der Clean-Code-Developer.

Das Vorgehensmodell der beiden lautet vereinfacht:

1. Anforderungen verstehen,
2. gemeinsame Sprache entwickeln (Ubiquitous Language)
3. Features der Anwendung ermitteln und priorisieren
4. Umsetzung planen
5. Coding – (Test-First)

In den nächsten Tagen hatten wir die Möglichkeit mit diesem Vorgehen an mehreren kleinen Projekten Erfahrungen zu sammeln.

Anforderungsanalyse

Bei der Anforderungsanalyse hieß es immer wieder von einem der beiden: “Welche Glaskugel verwendest du denn jetzt?” Mit Witz und Sachverstand haben die beiden uns immer wieder gewarnt: “YAGNI, lauert überall!”.
Gemeint war damit, das wir die Anforderungen nicht interpretieren sollen, sondern direkt vom Kunden abfragen. Nicht unsere Vorstellung von der Problemdomäne bestimmt was zu realisieren ist, sondern was der Kunde wirklich braucht. Immerhin ist der Kunde meist Spezialist innerhalb der Problemdomäne.

Ubiquitous Language

Der nächste Schritt im Vorgehen ist eine gemeinsame Sprache, die “Ubiquitous Language”, zu entwickeln und vor allem auch zu verwenden. Hier ist das Ziel, dass diese Sprache Einzug in den Code erhält. Die konsequente Verwendung dieser gemeinsamen Sprache aller Beteiligten führt zu einer präzisen Kommunikation. Diese wiederrum mindert die Zahl der Missverständnisse und beschleunigt das Verständnis.
Zur Verdeutlichung der gemeinsamen Sprache wurden verschiedene Hilfsmittel eingesetzt. Mal war es eine Concept-Map, mal eine einfache Liste der entdeckten Begrifflichkeiten. Ein anderes Mal war es ein konzeptionelles Datenmodell, das ausreichte, um die Beziehungen zwischen den Begriffen zu verdeutlichen.
Wichtig war hier vor allem, das wir die Begriffe auch aktualisierten, sobald wir bessere fanden. So stellte sich im Datenmodell zur Kinokasse heraus, dass “Sitz” ein passenderer Begriff als “Platz” war, wenn der Stuhl im Kinosaal bezeichnet werden sollte, den der Kunde für eine bestimmte Vorstellung reservierte. Sofort wurde dieser Begriff im Datenmodell wie auch in der Liste der Ubiquitous Language angepasst.

Features der Anwendung

Im dritten Schritt wurden die Features der Anwendung erhoben und priorisiert. Beide Tätigkeiten wurden aus Sicht des Kunden durchgeführt. Das heißt auch hier steht der Kundennutzen im Mittelpunkt. Der Kunde soll am Ende der ersten Iteration ein lauffähiges Produkt erhalten. Ein Produkt, dass ihm einen Nutzen liefert. Ein Produkt mit dem er arbeiten, das er testen und bewerten kann. Dazu muss klar sein, welche Features zu welchem Kundennutzen führen. Erst dann kann priorisiert und festgelegt werden, “Was” zu realisieren ist.

Umsetzung planen

Nach dem die Features priorisiert wurden, war klar in welcher Reihenfolge sie zu realisieren sind. In der Umsetzungsplanung geht es nun darum, Klarheit über das “Wie” zu schaffen. Mit dem “Wie” wird nun bestimmt, welche Prozesse und Prozessschritte zur Realisierung der Features nötig sind. Hier wird also auch der Ablauf modelliert.
Die Prozessschritte, die thematisch zueinander passen, werden zu Komponenten zusammengefasst und jeweils einem oder einem Team zur Realisierung übertragen.

Überraschend war hier, dass wir in allen Beispielprojekten während der Umsetzungsplanung eine andere Lösung planten, als die, die wir bei der Vorstellung der Aufgabe im Kopf hatten.
Soll heißen: Bei der Vorstellung der Aufgabe hatte jeder Entwickler ganz automatisch eine Vorstellung davon im Kopf, wie er die Aufgabe lösen würde. Während der Diskussion, die uns bis zur Umsetzungsplanung führte, entstand in der Gruppe immer eine andere, neue Lösung.
Nicht so überraschend war hingegen, das diese neue Lösung besser zum Problem passte, da wir mittlerweile das Problem gedanklich besser durchdrungen hatten.

Coding – endlich!

Zum Schluss kamen wir dann endlich auch zum coden. Einzige Prämisse hier: Test First musste es sein, aber das ist selbstverständlich, wenn man was auf sich hält, als Software-Entwickler.

Das Ergebnis zum Thema Coding:

1. Das Coding war in jedem der Projekte sehr schnell erledigt,
   das war zu erwarten gewesen, wenn man sich so intensiv mit den zugrundliegenden Problemen beschäftigt.
2. Das Coding war sehr fehlerarm.
   Nun, das könnte auch an dem Test First – Ansatz liegen. Werden hier doch für alle relevanten Codefragmente Tests geschrieben.
3. Das Coding wurde parallel durchgeführt
   Das war die eigentliche Überraschung. Wir konnten parallel entwickeln und hatten kaum Probleme im Zusammenspiel der Komponenten.
   Das heißt: die Komponenten zusammenstecken und laufen lassen - fertig.

Eine weitere Erkenntnis zum Coding ist: Durchstich-orientiert zu programmieren. Das heißt möglichst früh ein Lieferergebnis herstellen. Lieber nur einen Teil der Ziel-Funktionalität realisieren, dafür aber immer die vollständige Strecke des Ziel-Prozesses umsetzen.

Fazit

Fr. 17:00 ging es zu Ende und mein Fazit lautet: Für mich war es eine überaus kurzweilige und lehrreiche Erfahrung. Die Dozenten haben uns ein sehr interessantes Thema der Software-Entwicklung äußerst unterhaltsam und sachkundig rüber gebracht.

Vieles von dem was ich in dieser Woche und auf der Seite der

gelernt habe, kann ich direkt in meiner Arbeit verwenden. Insbesondere den Punkt: “Soviel Zeit wie nötig, für die Analyse und Planung zu verwenden” möchte ich hier nochmal hervorheben.

Doch wir hatten auch Glück mit der Gruppe, denn sowohl die Motivation wie auch die soziale und technische Kompetenz waren hoch.

Alles in allem hat es mir sehr viel Spaß gemacht und ich freue mich auf die online-Fortführung dieses Experiments.

Warum CleanCodeDevolper?

 

Rumms, die Glastür kracht ins Schloss. Schwere Schritte nähern sich unaufhaltsam vom Ende des Gangs. Ein Bein schleift nach. Käptn Ahab auf hoher See. Dann verdunkelt sich mein Büro. Ein Schatten schiebt sich über meinen Schreibtisch wie eine Sonnenfinsternis.

„Na, wie schauts?“, 

dröhnt er. Der Mann meiner schlaflosen Nächte steht im Türrahmen. „Frage oder Urteil?“, schießt es mir noch durch den Kopf, immer ganz der Philosoph. Immer Haltung bewahren. Ich muss etwas antworten. Zum Stand des Projektes, dass ich vor genau 91 Tagen übernommen hatte.

Nein, ich hätte es nicht annehmen sollen, dieses Projekt. Doch vielleicht das Projekt, aber nicht diesen Code. Angeblich nur ein paar Änderungen, mal eben nebenher, nichts Wildes! Doch ruckzuck gehen die Wochen ins Land. Man probierte hier und setzte dort an. Sobald ich irgendwo was änderte, krachte es wo anders im Klassenmeer. Mein Vertrauen in den Code schwand dahin, der Liefertermin rückte näher. Irgendwie musste ich raus aus dieser Miesere!

Rettung? „Test-Driven-Development“. Morgens um fünf, hatte ich eines Nachts die Seite der CleanCodeDeveloper entdeckt!

 

Dort war im 3. Grad die Rede von automatisierten Unit Tests und Testattrappen (Mockups). Schnell den Kenntnisstand über TDD vertieft, NUnit runtergeladen und das Tutorial durchgecheckt. Ich beschloss, das Verfahren auf das aktuelle Projekt anzuwenden.

Doch nach Anfangserfolgen Ernüchterung! Wo sollte ich mit dem Testen anfangen und wie sollte ich erkennen, wann ich genug getestet hatte? Nach wenigen (Test)durchläufen hatte ich den Überblick verloren. Dafür gesellte sich nun das ungemütliche Gefühl von Wiederholungen der vertrauten alten Fehler, nur im neuen Gewand, mit anderer Technik, zu mir an diesen einsamen Abenden in meiner Programmierstube, während der Rest der Welt Fußball schaute. Coole Ratschläge aus der Blogosphäre zur Benennung der Tests „die-Klasse-Sollte-X-tun-Und-das-Ergebnis-Y-erzielen“, waren auch nicht gerade inspirierend. Die entscheidende Frage blieb unbeantwortet: „Wann habe ich genug getestet?“ Resignation zog wie klammer, feuchter Bodennebel in meine Stube. Den Job an den Nagel hängen? Müllmann werden? Oder Traumtänzer, Zahlenjongleur im Zirkus? Eine Therapie anfangen? Oder in die Wüste gehen? Nach meinem bescheidenen Wissenstand gabs dort immerhin keine Bodennebel.

Während ich so über die Zukunft sinnierte, wollte mein Schicksal, dass mir in einem schlaflosen Wachttraum Behaviour-Driven-Development erschien. Erneut Funken der Hoffnung! Ich begann Szenarien zur Nutzung der Anwendung zu bauen, immer das Ziel des Anwenders vor Augen. Ich begann ganz von vorne: das Starten der Anwendung und die Eingabe der ersten Daten im Gherkin-Stil zu dokumentieren.

Auf einmal wurde mir klar, dass ich so dem Weg des Anwenders durch das Programm folgte. Die Szenarien des BDD wurden auf einmal Brücken zu den User Stories der Anforderungsanalyse. Ich befand mich zwar nun auf der Ebene der Integrations- und Oberflächentests, hatte aber ein Ziel vor Augen. Endlich konnte ich die gesamte Anwendung zielorientiert auseinander nehmen und refaktorisieren. Genau so musste ich die Tests anpacken! Das wusste ich nun. Blieb nur die Frage, wann konnte ich aufhören. Und diese konnte ich mit Code Coverage beantworten. Denn sobald ich alle praxisrelevanten Wege durch das Programm in Form von Szenarien spezifiziert hatte und dann den Nachweis hatte, dass alle Code-Zeilen durchlaufen waren, war ich fertig. Wow!

Rumms, die Glastür kracht ins Schloss. Schwere Schritte. Gelassenheit in mir. Ich bin ganz Blumenkind. Depression, Bodennebel ade! Auch Chefs sind Menschen, sinniere ich in der mir eigenen Großzügigkeit. Ich strahle innerlich wie alle Atommeiler dieser Erde zusammen. Die Schritte nähern sich. Mein ganzes Lächeln für dieses Sonnensystem! Dann der Schatten. Er schiebt sich über meinen Schreibttisch.

„Na, wie schauts?“.

Fortsetzung folgt. Dann geht’s um das SUB-DD-Vorgehensmodell. Mein erster Artikel hierzu wird sich mit dem Anforderungs-Management befassen.