Clean Code Coding Dojo - Fazit eines Workshops

Was ist Clean Code und welche Prinzipien unterstützen einen um sauberen Code zu erzeugen? Diese und weitere Fragen wurden von uns in dem Zwei-Tages Workshop letzte Woche in der HfT beantwortet. Um das theoretische Wissen gleich in der Praxis anzuwenden haben wir mehrere kleine Übungsaufgaben mitgebracht. Diese sogenannten Katas wurden in mehreren Coding Dojos mithilfe von Test-Driven Development (TDD) umgesetzt.

Erste Kata: FizzBuzz

Den Anfang machte die Fizz Buzz Kata. Sieist am besten geeignet für Entwickler, die das erste Mal an einem Dojo teilnehmen. Die Anforderung besteht darin eine Funktion zu implementieren, die Zahlen entgegennimmt und diese wieder zurückgibt. Es gibt jedoch drei Sonderfälle: Falls die übergebene Zahl das Vielfache von 3 ist soll der Term „Fizz“ zurückgegeben werden; falls die Zahl ein Vielfaches von 5 ist, soll „Buzz“ zurückgegeben werden; und falls die Zahl ein Vielfaches von 3 und 5 ist, soll „FizzBuzz“ returniert werden. Diese Anforderung ist fachlich gesehen keine Herausforderung. Das ist bei Katas üblich, denn das Ziel ist es nicht „Nüsse zu knacken“, sondern Techniken zu üben und solange zu wiederholen bis man sie verinnerlicht hat. FizzBuzz ist besonders als Einsteiger-Kata geeignet, da die Anforderung sehr detailliert beschrieben und bereits in kleine Teil-Aufgaben unterteilt ist. Somit wird dem Entwickler Arbeit abgenommen und er kann sich mehr auf die eigentliche Technik, die er üben will, fokussieren.

Coding Dojo - Randori

Der Ablauf eines Dojos ist für den Anfang gewöhnungsbedürftig. Auf Projekten ist es üblich, dass jeder Entwickler fleißig alleine vor sich her coded und sein Werk, von anderen ungesehen, in das zentrale Repository eincheckt. Auf manchen Projekten ist man bereits dazu übergegangen das Code Review oder Pair Programming zur Qualitätssicherung einzusetzen. Somit wird jeder Code zumindest on einem Kollegen angeschaut. Programmieren vor einem kleinen Publikum, wie das bei Coding Dojos üblich ist, ist daher für viele absolutes Neuland.

Wir haben die Coding Dojos nach dem Randori Prinzip aufgesetzt: Es gibt einen Fahrer, der den einzigen Rechner vor sich hat und als einziger programmieren darf; es gibt den Beifahrer, der den Fahrer mit Tipps unterstützen kann; und es gibt das Publikum, welches den Code sehen kann, jedoch nicht reden darf. Nach drei Minuten Entwicklungszeit werden die Rollen getauscht: Der Fahrer wird zum Zuschauer, der Beifahrer wird zum Fahrer und ein Zuschauer wird zum neuer Beifahrer. Auf diese Weise wird die Anforderung umgesetzt.

Clean Code Techniken

„Testing is the engineering rigor of software development” (Neil Ford) Wir sind derselben Meinung und deshalb ist die erste Technik, die wir geübt haben, Test-Driven Development. Bei der testgetriebenen Entwicklung wird der Produktivcode in mehreren Iterationen geschrieben. In jeder Iteration wird eine kleine Teilaufgabe der Anforderung implementiert, indem sie die Phasen des TDD Zyklus (figure 1) passiert. Die Teilnehmer haben sehr schnell die Vorteile dieses Prozesses erkannt:

  • Man muss sich gleichzeitig nur auf eine Aufgabe konzentrieren: entweder man schreibt neuen funktionierenden Code oder man verbessert die Lesbarkeit des bestehenden Programms.
  • Man hat immer ein Sicherheitsnetz, welches verhindert, dass man einmal entwickelte (und abgenommene Funktionalität) aus versehen kaputt repariert.
  • Wenn man auf dem grünen Pfad refactored, d.h. so den Code umstrukturiert, dass die Tests immer grün bleiben, hat man jederzeit ein auslieferbares System.

Während des Refactorings machten sich die Studierenden mit der Sinnhaftigkeit der anderen Clean Code Prinzipien vertraut. Beispielsweise warum es gut ist sich nicht zu wiederholen (Don’t Repeat Yourself). Falls nämlich der redundante Code einen Fehler enthält oder sich ändert, müssen alle seine Kopien manuell angepasst werden. Die Suche nach den Kopien kann dabei sehr mühsam sein. Des Weiteren hat man auch schnell festgestellt, dass sprechende und sinnvolle Namen für Variablen und Methoden die Lesbarkeit ungemein erleichtern. Dieses Prinzip (Meaningful Names) sollte dabei nicht nur auf den Produktivcode eingeschränkt werden, sondern gilt genauso auch für Testcode.

Bei der Umsetzung weiterer Katas sind wir auch den Prinzipien Single Responsibility Principle, Keep It Simple, Stupid und You Ain’t Gonna Need It begegnet. Als Trainer haben wir Wert darauf gelegt, dass die Studierenden selber den Bedarf für die Prinzipien erkennen. Beispielsweise wenn eine Klasse an die 20 Methoden angehäuft hat, die dies und jenes machen, kann keiner genau sagen wie man die Klasse verwenden kann und für was sie eigentlich gut ist. Solche Klassen sind schwer zu verstehen und somit auch teuer zu warten. Hier kommt SRP ins Spiel. Das Prinzip sagt nämlich, dass eine Klasse genau eine Verantwortlichkeit haben sollte und diese Verantwortlichkeit sollte sie gut ausführen. Wir haben das Prinzip angewandt und die Klasse in mehrere Klassen geteilt, wobei jede nur genau einen Grund hat sich zu ändern.

Über Code reden

Die Anwendung der Prinzipien führte zu mehreren Aha-Erlebnissen. Diese wurden während und nach jedem Übungsblock diskutiert. Was in der Praxis auch gerne zu kurz kommt, ist das Reden über den Code. Wir wollten dem entgegenwirken und motivierten unsere Teilnehmer zur Diskussion. Wann ist Code sauber und welcher Code wird von den meisten als unsauber wahrgenommen? Wann sollte man die Prinzipien anwenden und wann ist es in Ordnung diese sogar bewusst zu verletzten? Es entstanden wertvolle Gespräche von welchen alle Anwesenden profitiert haben.

Fazit

Abschließend bleibt zu sagen, dass es tolle zwei Tage waren, die wir in der Hochschule verbringen durften. Die Teilnehmer waren alle sehr engagiert und motiviert und haben es uns mit ihrer Neugierde positiv überrascht. Wir haben uns sehr gefreut mit solch einer Gruppe unser Wissen teilen zu dürfen und freuen uns bereits auf die nächste Summer School an der HfT.