Stefan Liesers Blog

Gestern habe ich den Standpunkt vertreten, dass Refaktorisieren im Test-Driven Development meiner Ansicht nach an der falschen Position im Prozess steht. Ferner habe ich erwähnt, dass vor dem Kodieren immer eine Planung stehen sollte. Diesen Vorschlag möchte ich etwas präzisieren.

In der Abbildung kann man sehen, dass der Prozess aus zwei Schleifen besteht. Im Inneren liegt der TDD Prozess. Im Gegensatz zur weit verbreiteten Ansicht vertrete ich die Meinung, dass Refaktorisieren jeweils am Anfang eines TDD Zyklus stehen sollte. Bevor ich den nächsten Test schreibe sollte ich überlegen, ob der Code durch Refaktorisieren verbessert werden kann. Verbessern meint hier, dafür zu sorgen, dass Prinzipien eingehalten werden und nicht gegen Werte verstoßen wird. Mein persönlicher Standpunkt zu Prinzipien, Praktiken und Werten ist bekanntlich unter clean-code-developer.de dokumentiert. Wer mag, orientiert sich daran, diskutiert mit Ralf und mir darüber oder findet seine eigenen Prinzipien und Werte. Warum ich glaube, dass Refaktorisieren am Anfang besser aufgehoben ist als am Ende habe ich gestern bereits beschrieben. Eine wichtige Annahme dabei ist, dass vor dem Kodieren eine Planung steht.

Mit der Planung beginnt die äußere Schleife. Nachdem ein Entwickler oder ein Team die Anforderungen geklärt hat (eine weitere interessante Herausforderung), sollte durch Planung ein Entwurf entstehen. Planung ist ein kreativer Prozess, bei dem die Gedanken freien Lauf haben sollen. Am besten nutzt man die Planungsphase sogar als Gelegenheit, mal von der Konsole aufzustehen und stellt sich ans Whiteboard. Mindestens aber sollte diese Planung auf Papier erfolgen, nicht am Rechner. Arbeiten am Rechner sind eher linear. Allemal wenn Code ins Spiel kommt. Der muss in einer gewissen Reihenfolge eingegeben werden und streng der Syntax genügen. Das behindert den freien Fluss der Ideen. Das Ziel der Planung ist es, das anstehende Gesamtproblem in Teilprobleme zu zerlegen. Das geht selbst bei so simpel anmutenden Aufgabenstellungen wie FizzBuzz, wie Ralf in seinem Blogpost sehr schön gezeigt hat.

Diese Planung dient nicht dazu, im Sinne von big-design-upfront gleich die Architektur für die gesamte Anwendung zu erstellen. Sie dient dazu, die Implementierung einer überschaubaren Anforderung zu planen. Um mal eine zeitliche Größenordnung zu nennen: die anschließend anstehende Implementierung nimmt einen Zeitraum im Bereich weniger Stunden in Anspruch.

Es gibt zahlreiche Gelegenheiten, diese Vorgehensweise mal auszuprobieren. Jeder Entwickler kann es für sich tun. Anregungen zu Übungen gibt es beispielsweise hier bei der dotnetpro. Nächste Woche startet in München das erste Clean Code Developer Praktikum. Auch dort werden wir nur mit Planung kodieren. Ziel dieses Praktikums ist unter anderem, unsere Vorgehensweise zu reflektieren. Im September starten wieder unsere Clean Code Developer Seminare. Und wer mal “für lau” in der Gruppe planen möchte, kann die Coding Dojos am 5.8. in Berlin oder am 19.10. in MünchenNürnberg nutzen.

Happy planning!

This entry was posted on Thursday, July 1st, 2010 at 10:43 and is filed under Clean Code Developer. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.