Stefan Liesers Blog

Inzwischen ist das TDD Mantra “Red/Green/Refactor” nicht mehr ganz unbekannt. Die Grundidee:

• Schreibe einen Test – Red
• Implementiere gerade soviel, dass der Test erfolgreich durchläuft – Green
• Räume auf – Refactor

Entwickler die beginnen, sich mit Test Driven Development zu befassen, sehen die größte Herausforderung darin, die Reihenfolge von Implementierung und Test umzudrehen. Das ist in der Tat nicht immer einfach und erfordert Disziplin. Man muss sich zunächst mal auf dieses Experiment einlassen, um den tatsächliche Nutzen zu erkennen. Der liegt nämlich nicht nur in einer verbesserten Korrektheit, sondern vor allem in einer besseren Evolvierbarkeit. Das liegt daran, dass TDD einen starken Einfluss darauf hat, wie man seinen Code strukturiert. Denn es entsteht, oft wird behauptet ganz von alleine, gut testbarer Code. Meiner Erfahrung nach verbessert sich die Qualität des Codes zwar nicht so ganz von alleine, aber ich bestreite nicht, dass schon allein die Reihenfolge, erst Test, dann Implementierung einen positiven Einfluss auf die Codequalität hat. Deutlich besser wird die Qualität durch einen vorgelagerten Planungsschritt. Damit rede ich nicht dem “Big Design Upfront” das Wort, sondern ich meine, als Entwickler müssen wir uns die Zeit nehmen, vor dem Codieren ein paar Skizzen auf Papier zu machen.

Angeregt durch einen Artikel in der aktuellen Ausgabe der Visual Studio One möchte ich aber etwas zum Refaktorisieren los werden. In dem Artikel war eine Abbildung zur Vorgehensweise bei TDD abgedruckt. Nach kurzer Suche stolperte ich bei Wikipedia über eine ähnliche Abbildung. Das Bild beschreibt TDD als Prozess. Was mir sofort auffiel ist die Tatsache, dass es auf dem “Repeat” Pfad vom Refaktorisieren zurück zum nächsten Test keine Entscheidung gibt. Zwischen Test und Implementierung liegt eine Entscheidung: man geht erst zur Implementierung über, wenn man einen Test geschrieben hat, der fehlschlägt. Auch beim Übergang von der Implementierung zum Refaktorisieren kommt es zu einer Entscheidung. Diesmal geht es erst weiter zum Refaktorisieren, wenn alle Tests erfolgreich verlaufen. Doch dann die Überraschung: vom Refaktorisieren geht es einfach so wieder zurück zum nächsten Test. Da stellt sich mir doch die Frage, wann bin ich denn mit dem Refaktorisieren fertig? Und in der Tat taucht diese Frage bei Entwicklern in der Praxis ebenfalls auf, ohne dass sie sich den Prozess anhand eines solchen Bildes bewusst machen. Und auch beim Coding Dojo in München im Rahmen des dotnetpro-powerday kam kurz die Diskussion auf, ob denn nach der Implementierung nicht refaktorisiert werden solle. Die Frage ist also ganz offensichtlich nicht nur, wann bin ich fertig mit dem Refaktorisieren, sondern soll ich überhaupt refaktorisieren?

Meine These dazu: das Mantra Red/Green/Refactor suggeriert etwas Falsches. Da steht Refaktorisieren nämlich jeweils am Ende, nach der Implementierung. Es suggeriert, dass man immer nach der Implementierung refaktorisieren solle. Und das halte ich für falsch. Allemal, wenn beim Refaktorisieren nicht zwischen Mikro und Makro unterschieden wird. Mikrorefaktorisierungen wie etwa das Reformatieren des Quellcodes mit dem Ziel, die Klammern alle an der richtigen Position zu haben oder das Umbenennen eines Bezeichners, etc. stehen möglicherweise desöfteren nach der Implementierung an. Aber die größeren Refaktorisierungen eben nicht. Damit meine ich beispielsweise Änderungen an Zuständigkeiten; so etwas wie das Aufbrechen einer Klasse in zwei, mit dem Ziel, das Single Responsibility Principle (SRP) einzuhalten. Oder auch das Aufteilen einer Methode in mehrere. Das sind alles Refaktorisierungen, für die ich einen triftigen Grund benötige. Dabei bitte ich zu berücksichtigen, dass ich wie oben erwähnt, Verfechter von Planung bin. Wenn ich mich vor dem ersten Test mit einem Stück Papier hinsetze entstehen selten Strukturen, die hinterher einer größeren Refaktorisierung bedürfen.

Mein Vorschlag: das Mantra sollte etwas anders angeordnet werden. Es sollte lauten [Refactor]/Red/Green. Dabei sollen die eckigen Klammern andeuten, dass Refaktorisieren vor dem nächsten Test nicht in allen Fällen, aber oft erforderlich ist. Der Vorteil: nun habe ich konkrete Anhaltspunkte, ob ich Refaktorisieren muss bzw. wann ich damit fertig bin. Gelingt es mir nicht, eine neue Anforderung umzusetzen, weil die Struktur des Quellcodes dafür ungeeignet ist, habe ich einen Grund zu refaktorisieren. Sobald ich in der Lage bin, den nächsten Test zu schreiben, ohne dabei Prinzipien zu verletzen, bin ich fertig mit dem Refaktorisieren.

Eine Hinweis zum Schluss: die testgetriebene Entwicklung ist ein komplexer Prozess, den man nicht mit einem Mantra aus drei Wörtern vollständig beschreiben kann. Mir ist selbstverständlich klar, dass man nach der Implementierung kurz inne halten sollte um zu prüfen, ob kleine Mikrorefaktorisierungen anstehen. Diese sind aber so unspektakulär, dass sie keines der drei Worte im Mantra schon komplett für sich beanspruchen sollten. Wenn also bei TDD von “Refactor” die Rede ist, dann ist es wohl sinnvoll, damit die aufwändigeren strukturellen Refaktorisierungen zu bezeichnen. Und die gehören für mich an den Anfang statt ans Ende.

This entry was posted on Wednesday, June 30th, 2010 at 11:01 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.