Follow my new blog

Montag, 10. März 2014

Attrappen gestütztes Nachdenken

Wie viel Design vor dem Codieren darf es denn sein? Diese Frage erhitzt immer wieder die Gemüter. Neulich auch das von Robert C. Martin. Der reagierte nämlich sehr barsch auf einen Blogartikel von Justin Searl.

Martin sieht nun einen Unterschied in der Notwendigkeit zu entwerfen zwischen größeren Strukturen und kleineren. Für die einen sollte man explizit entwerfen, für die anderen sich durch TDD treiben lassen. Ich allerdings erlaube mir anderer Meinung zu sein. Für mich gibt es keine wie von Martin beschriebene Diskontinuität. Vielmehr sehe ich Software als selbstähnliche Struktur, die deshalb auf allen Ebenen auch ähnlich behandelt werden will. Ausführlicher erkläre ich das ein einem englischen Blogartikel.

Damit sei das Thema erledigt – doch dann ließ mich der Artikel von Searl nicht recht los. Der beschreibt nämlich einen TDD-Ansatz, den Searl für mindestens didaktisch günstiger hält als “den traditionellen”.

Schon beim ersten Lesen flog mich da eine Ähnlichkeit zu Flow-Design an, doch ich konnte sie noch nicht recht greifen. Als mir jedoch die Mock-Frameworks TypeMock Isolator und JustMock einfielen, habe ich mich darangesetzt, und Searls Vorschlag ausprobiert. Das Ergebnis hat mir sehr gefallen.

Schon lange setze ich keine Mock-Frameworks mehr ein, weil die Zahl der Attrappen zum Test meiner Flow-Designs klein ist. Für noch ausgefeiltere Mock-Frameworks wie die beiden hatte ich deshalb schon gar keinen Bedarf. Doch jetzt finde ich sie sehr nützlich. Lange hat das Profiler-gestützte Mocking auf einen Einsatzzweck bei mir gewartet, nun ist er da: mit JustMock kann ich Flow-Designs schneller in Code übersetzen – und das top-down.

Wie ich mir das denke, habe ich in einem längeren englischen Blogartikel beschrieben. Der ist als Dialog abgefasst, weil er eine Herangehensweise an TDD beschreibt – wie weiland Martin es getan hat.

image

Den Dialog zu schreiben, hat Spaß gemacht. Das war mal ein ganz anderes Format als sonst. Doch, ja, ich gebe zu, er ist ein bisschen lang und gewunden geworden. Jedenfalls für den normalen Leser im Web, der schnell, schnell Informationen sammeln will.

Deshalb habe ich das Vorgehen in einem englischen Folgeartikel nochmal systematischer beschrieben. “Informed TDD” habe ich diese Herangehensweise genannt, weil hier TDD nicht “blind” aufgrund von Testfällen betrieben wird, sondern geleitet durch ein entwerfendes Nachdenken.

image

Ich verstehe, wenn manchem der Entwurf am Flipchart zu theoretisch ist. Zwar halte ich das für eine Gefühl, das sich mit etwas Übung überkommen lässt – doch erstmal ist es halt so. Mit “Informed TDD” kann hier jedoch schneller abgeholfen werden: Das Nachdenken kann kürzer ausfallen, weil es das Problem zunächst weniger tief durchdringen muss. Schneller kann man zur Tastatur greifen und schonmal Code schreiben, der das Nachdenken verifiziert. Schrittweise werden die durch “hartes TDD” zu lösenden Probleme auf diese Weise kleiner.

Attrappen stützen also das Nachdenken. Und das ganz modern ohne spezielle Vorkehrungen für eine Injektion von Funktionalität.

Kommentare:

Michael hat gesagt…

Hallo Ralf,

wenn ich deinen "ITDD"-Artikel richtig verstanden habe, demonstrierst du hier, dass man mit TDD und dem passenden Framework auch "Top Down" entwerfen kann (und nicht nur "Bottom Up", wie man das sonst meist sieht). Das ist sicher eine gute Idee, sollte ich unbedingt mal ausprobieren. Trotzdem hört sich das für mich an wie "alter Wein in neuen Schläuchen". So richtig "neu" ist "Top Down" Entwurf ja schließlich nicht - ich kann mich erinnern, Top Down- und Bottom-Up-Entwurfstechniken vor fast 30 Jahren im Informatikunterricht in der Schule gelernt zu haben. Aber vielleicht ist ja diese "klassische" Technik tatsächlich im Zuge des TDD-Hype ein wenig zu sehr in den Hintergrund gerückt.

Grüße

- Michael -

Anonym hat gesagt…

Warum heißt es "Attrappen gestütztes" und "Vertragsstrafe", aber nicht "Attrappengestütztes" und "Vertrags Strafe"?

Leute, so schwer ist das doch nun auch nicht. Beide Wörter schreibt man latürnich zusammen. Und wenn schon getrennt, dann bitte wenigstens mit Bindestrich. Läßt sich das einrichten?

Trupp hat gesagt…

Ich bin verwundert ueber diesen momentanenTDD bashing Hype. Ich bin ein Großer freund von konstruktive Kritik, ohne kann nix gescheites zustande kommen. Aber was ist hier konstruktive?
Das Testmethod nicht von Baum fehlt ist klar d.h. beginnt TDD immer mit der Entwurfsfasse. Wie diese Entwurfsfasse ausfällt hat nichts mit TDD zutun, nur mit Fähigkeiten des Entwicklers. Bis hierher sollten sich alle einig sein, und trotzdem „musste“ dass schon mehrmals im Web ausdiskutiert werden. Das Rotfasse kein Entwurf erfordert ist klar, es ist die Implementierung des Testentwurfs. Bb man Testinput „zeile1“ oder „zeile2“ nennt darf man nicht „Entwurf“ nennen da man damit das Wort bedeutungslos macht und alles ist „Entwurf“. Grün: die Implementierung muss trivial sein ansonsten ist der Test schlecht entworfen s. oben. Es ist kein TDD wenn in Grünfasse mehr als eine condition, iteration oder scalar zustande kommt s. unten. Refactoring: ist „Entwurf“! Hier wird’s lächerlich, das ganze schritt ist nur dafür da das man sein System auf low level designt und dann wird gesagt das man mit TDD nicht denken oder entwerfen muss.
Jeder darf „anderer Meinung sein“. Nur was viele nicht wahrnehmen oder es ist ihnen egal ist, das öffentlich „anderer Meinung zu sein“ Verantwortung mit sich bring. Und wenn ein Experte öffentlich sagt 1+1=3 trägt er die Verantwortung alle falsch geteilte Apfel.

Ralf Westphal - One Man Think Tank hat gesagt…

@Anonym: Zur Getrenntschreibung s. §58 hier: http://www.duden.de/sprachwissen/rechtschreibregeln/getrennt-und-zusammenschreibung#K58

Insofern sehe ich "Attrappengestützt" wie "Attrappen gestützt" als korrekt oder allemal tolerierbar an.

"Vertragsstrafe" hingegen getrennt zu schreiben, macht keinen Sinn. "Strafe" ist ja kein Adjektiv oder Partizip. Genausowenig wäre Autohaus oder Blumenkasten ein Beispiel dafür, warum "Attrappen gestützt" zwingen zusammengeschrieben werden muss. Das Deutsche erlaubt es halt, dass neue Substantive aus mehreren anderen gebildet werden. Blumentopferde, Kapitänsmützenherstellervereinigung. Darüber hat sich schon Mark Twain lustig gemacht. Oder lustiggemacht? Hm...

Ralf Westphal - One Man Think Tank hat gesagt…

@Trupp: Entwurf ist Planung von Struktur. Insofern muss Entwurf vor (!) dem handwerklichen Refactoring stattfinden. Denn sonst weiß das Refactoring nicht, welche Struktur es herstellen soll.

Und ansonsten: Entwurf soll vor (!) den Phasen red+green stattfinden. Denn ohne einen Entwurf weiß ich nicht mal, wie das aussehen soll, was da implementiert wird. Ja, ohne Entwurf kann ich nicht mal wissen, welchen Test ist als nächsten schreiben soll. Denn das leitet sich aus dem entworfenen Lösungsansatz ab.