Kurz zum KataBlog: Das Kata ist logisch gesehen eine unfassbar einfache Aufgabe. Doch genau das macht das Kata so besonders und zum Teil auch besonders “herausfordernd”. Ein Blog mit ASP.NET MVC im vollen TDD zu lösen ist für Einsteiger eine nicht zu unterschätzende Aufgabe. Ebenso würden wahrscheinlich auch TDD Skeptiker sich mit diesem Kata schwer tun und sich auf den ersten Blick in Ihrer Meinung auch bestätigt fühlen. Doch KataBlog ist wohl (nach KataFizzBuzz) der nächste große Schritt für Neulinge. Die Erkenntnisse aus dem Blog möchte ich dem passionierten Dojo- und Kata-Freund nicht gleich verraten – schließlich ist Selbsterkenntnis eine schöne Sache. ;)

Nun, wie dem auch sei: Im gestrigen Dojo waren wieder einmal gut aufgelegte und aktive Teilnehmer dabei. Zu meiner Überraschung interessierten sich die Teilnehmer sehr viel mehr über grundlegende Technologien wie HTTP, ASP.NET und das ASP.NET MVC als über die eigentliche Aufgabenstellung. Pete reagierte gut, indem er alle nochmals darauf hinwies, dass ein Coding Dojo ein einziges Ziel verfolgt: Die erfolgreiche Vermittlung von nutzbaren Lerneffekten – für jeden Teilnehmer. Er sagte dass ein Dojo keine feste, durchgeplante Veranstaltung mit fixem Programm oder Paradigma sei, sondern dass das Dojo primär die Teilnehmer und den Lerngedanken im Fokus hat. Er stellte die Einsteiger vor die Wahl: Wollen sie mehr über “das Handwerkszeug” ASP.NET & ASP.NET MVC erfahren, oder mehr über die Lösung der Aufgabe per TDD und professionellen Entwicklungs-Prinzipien?

Die Teilnehmer überlegten eine Weile, bevor man sich dann einhellig für eine tiefere Behandlung der Technologie entschied. Pete & ich gingen auf diesen Wunsch ein und erklärten die Technik. Anfangs noch ein wenig theoretisch. Es wurden Fragen beantwortet wie z.B. “Was ist MVC?” oder “Was ist der Unterschied zu Web Forms?”. Nach einem kurzen Theorie-Exkurs am Flipchart ging es dann endlich Hands-On mit ASP.NET MVC auf zum Blog.

Pete zeigte die ASP.NET Templates, die Einbindung der Unit-Test Frameworks NUnit und xUnit in diese und die einzelnen Wizards für den Controller und die Views. Gelöst haben wir dann das Blog indem wir und Stück für Stück mit den Views an die Grundfunktionen “Anzeigen”, “Editieren”, “Erstellen”, “Löschen” und “Auflisten” herangewagt haben. In Anbetracht der Tatsache, dass es so viele Fragen zu MVC gab (Stichwort: Routes, Convention over Configuration, Partial Views usw usf.) ging es auch relativ flüssig durch. Nach knapp 3 Stunden waren wir soweit und hatten den Blog am laufen.

Ich kann jedem empfehlen, der sich mit TDD ernsthaft auseinandersetzen möchte, sich (nach den Erkenntnissen von KataFizzBuzz), die nächste Stufe Richtung sauberen Code und erweiterbarem Design zu erklimmen und das Kata zu lösen. Die Fortgeschrittenen TDD’ler werden schnell sehen, worum es bei dem Kata geht. Ich finde es besonders mutig und gut, dass Pete so eine technisch wie auch methodisch herausfordernde Aufgabe im Einsteiger-Dojo vorgestellt hat. Noch bewundernswerter war allerdings das aktive “erfassen & erkennen” der Teilnehmer, die sich keineswegs davor gescheut haben, sondern die ganzen 3 Stunden über mit voller Konzentration dabei waren. Ich kann nur sagen: Hut ab & Danke!

Was soll ich sagen, mein Fazit wird langsam eintönig, aber es ist nun mal so: In zwei Wochen ist schon wieder Experten-Dojo (18.11.2009 18:00 Uhr) und ich freue mich jetzt schon wahnsinnig. Es wird sicherlich wieder eine erkenntnisreiche, spannende und spassige Sache!

Unit Tests & TDD machen Sinn!

Ganz ehrlich, Unit Tests & TDD machen sogar richtig viel Sinn. Unit Testing selbst macht schon sehr viel Sinn, weil eine Verifikation von Anforderungen (fachlicher und technischer Natur) ein wichtiger Bestandteil in der Beurteilung von Leistungsanforderungen an eine Software sind. Ha! Komischer Satz irgendwie, aber im Endeffekt einfach abkürzbar: Wer will ein Auto ohne getestete Bremsen fahren? Übrigens auch ein ziemlich netter Vergleich, denn “bremsen” ist das Feature, welches von verschiedensten Komponenten und Faktoren abgedeckt wird (Bremsflüssigkeit, ABS, Bremsscheiben, Bremsbacken, Bremsblöcke usw usf.). Naja, ich glaube da gibt es nicht viel mehr darüber zu sagen.

Darüber hinaus geht es beim Testing & Test-Driven-Development um die Entwicklung von stabiler Software. Stabil ist in diesem Sinne nicht nur die Verifikation der Funktionalität (”Im Werk wurde einmal auf die Bremse getreten, der Wagen blieb stehen – Passt.”), sondern um die Haltbarkeit der Funktionalität als Subsystem (die gesamte Bremsanlage) und innerhalb des Gesamtsystems (Auto). Kurz und bündig: Wer heutzutage stabile, wartbare und erweiterbare Software entwickeln möchte wird ernsthaft TDD einsetzen wollen.

TDD ist ein mächtiges Entwicklungswerkzeug

Wie Ralf es schon in seinem Post über TDD erklärt und in vielen Kommentaren wiederholt, darf man TDD nicht als das “Allheilmittel” ansehen, sondern als dediziertes, mächtiges Werkzeug. Mit TDD als Tool kann man viele Dinge sicherer und schneller gestalten. Mittlerweile kann ich behaupten, dass ich TDD in keinem Projekt außer acht lassen will und werde, weil es ein essentielles Werkzeug in meinem “Software-Entwicklungs-Baukasten” ist – wie z.B. eine gute IDE oder Patterns oder SCM oder CI… TDD ist einfach mit dabei.

Manch einer macht hierbei noch eine feine Unterscheidung. Es heisst: “Bei neuen Projekten TDD, ok. Aber bei den alten Dingern? Boa, nee”. Ehrlich gesagt habe ich das am Anfang auch so gesehen. Aber Mittlerweile sehe ich das ganz anders. Egal ob Green- oder Brownfield – TDD ist immer gut. Bei schon existierenden Projekten (die evtl. sogar wenig Tests haben) treibt TDD die Testbarkeit und die lose Kopplung voran, fördert die Effektivität der Arbeit an Erweiterungen und erleichtert vehement die Umstrukturierung und Wartung des Codes. Dort wo es machbar ist, sollte TDD auch gemacht werden, denke ich.

Jaaa, aber wo ist denn TDD nicht machbar? Klare Antwort: I/O und Parallelität / Multithreading. Alles was mit Ein- und Ausgabegeräten zu tun hat, eine Ressource für Ein- oder Ausgabe darstellt oder in einem asynchronen Verarbeitungskontext liegt. In der Praxis: Joystick, Komplexe Eingaben, User Interfaces, Datenbank. Das sind kritische Punkte, ja. Und gerade dort wünscht man sich TDD, obwohl genau dort die Grenzen früher oder später erreicht werden, weil man einfach keinen Einfluss mehr auf den Status, die Eingabe, die Ausgabe oder die Erwartung derer hat.

TDD im Grenzbereich

Dennoch darf man sich nicht durch diese “Schwierigkeiten” abschrecken lassen. Ich habe gerade bei diesen Situationen festgestellt, dass es enorm hilfreich sein kann, am “Grenzbereich” von TDD sprichwörtlich “bis zum geht nicht mehr” umzusetzen. Man stellt schnell fest, dass man an diesen “Nahtstellen” der Anwendung sauberer und klarer strukturiert, Verantwortlichkeiten besser aufteilt. Danach betrachtet man das Ergebnis mit anderen Augen. Man stellt fest, dass die UI wirklich nur noch das nötigste macht, absolut schlank ist und dass viele Dinge, die in der UI hilfreich sind (wie z.B. “Pagination”) auch komplett ohne UI wunderbar anwendbar werden. Da ist TDD ein wenig wie beim Autorennen: Im Grenzbereich ist es anstrengend, ist aber hocheffektiv und macht obendrein noch Spass.

Für die TDD-Stirnrunzler, die wirklich mal wissen wollen, wie sich das dann im Endeffekt anfühlen kann, denen lege ich wärmstens ein paar Code Kata’s an’s Herz. Zum Beispiel ist das populäre KataFizzBuzz im letzten Einsteiger-Dojo als Windows-Forms-Kata implementiert worden. Dort gab es viele, die sich gefragt haben, wie man überhaupt die UI testen kann. Doch statt sich mit der “Untestbarkeit” der GUI zufrieden zu geben, hat man konsequent das TDD ausgereizt und dadurch ein einfaches MVP-Pattern umgesetzt.

Für TDD-Neulinge empfehle ich auch das KataBlog. Es ist eine wunderbar einfache Programmieraufgabe, die sehr subtil zeigt, wie man über TDD Design & Entkopplung der Verantwortlichkeiten treibt und welche (anfangs ungeahnten) Vorteile man sich dadurch schaffen kann. Jedoch warne ich die Interessierten schon vor: KataBlog zeigt die Erkenntnisse subtil, zwischen den Zeilen.

Fazit: TDD & Unit Testing ist ein absolutes Muss in der modernen Software-Entwicklung!

Null References: The Billion Dollar Mistake
Womit ich eigentlich auch schon bei meiner persönlichen Top-Sessions-Liste angekommen bin. Mit großem Abstand war der Vortrag von Tony Hoare über “Null References: The Billion Dollar Mistake” wohl der beste und beeindruckendste. Es war unglaublich interessant – ja ich würde sagen fesselnd – zuzuhören, wie es dazu kam, dass Tony Hoare bei der Reimplementierung der Programmiersprache Algol das Konzept des Null-Pointers eingeführt hat. Er bezeichnet selbst diese Entscheidung, die er im übrigen in den 60er-Jahren fällen musste – als großen Fehler. In Folge dessen haben nahezu alle höheren Sprachen das Konzept der Null-Referenzen übernommen – bis zum heutigen Tag. Es verfolgt jeden C#-Entwickler tagtäglich, ganz zu schweigen von all den anderen Programmiersprachen wie Java, C++ usw usf. Ich könnte seitenlang darüber berichten, wie unglaublich packend Tony Hoare seine Geschichte erzählte, mit all den Überlegungen, den Zweifeln und dem Druck, dem er damals ausgesetzt war. Sir Tony Hoare, my deepest and honest respects.

Pimp my Architecture
Ein paar Galaxien näher an der Erde und am täglichen Geschehen war “Pimp my Architecture” von Dan North. Er ging humorvoll, jedoch zu gleichen Zeit sehr informativ auf die Aufgaben eines Architekten ein, der sich immer wieder in der Situation vorfindet, bestehende Architekturen ändern und verbessern zu müssen. Dabei beleuchtete er verschiedenste Aspekte: die Technologie, das Design, die Grundarchitektur, die Projektbedingungen, das Entwicklungsteam und die Stakeholder und Sponsoren. In vielen kleinen Geschichten aus dem Alltag zeigte er, welche Möglichkeiten man als Architekt hat, um bestehende Systeme zu verbessern. Ganz besonders hat mir dabei gefallen, dass er auch explizit die Dinge und Situationen angesprochen hat, die man als Architekt kaum oder garnicht beeinflussen kann bzw. sollte.

Concurrent Programming with Microsoft F#
F# (F-Sharp) – das in Zukunft neue Mitglied der .NET-Sprachfamilie, ist schon lange vor dem Vortrag von Amanda Laucher in meiner Interessensliste gewesen. Umso erfeulicher war es für mich, in ihrem Vortrag “Hands-On-Experience” mitzunehmen. Amanda entwicklet seit geraumer Zeit eine “Real-World-Application” in F# für ein großes Versicherungsunternehmen und gab die Erfahrungen und Möglichkeiten, die sie in diesem Zuge mit der Programmiersprache gemacht hat unverblümt in ihrem Vortrag wieder. Ich muss sagen, nach dem Vortrag wurde ich in meiner eigenen Auffasung bestätigt, dass F# nicht nur ein weiteres exotisches Akademikerwerzeug ist, sondern eine echte Bereicherung für die Entwicklung mit dem .NET Framework darstellen kann. Natürlich ist es ein Umdenken in vielerlei Hinsicht – der funktionale Ansatz, die Syntax, das Prinzip der unveränderlichen Variablen. Aber es ist ein mächtiges Werkzeug, dass man (auf Grund des unstreitbar genialen Designs der .NET-Sprachen mit CLR und CTS) wunderbar in Verbindung mit C#-Projekten einsetzen kann. Ich persönlich denke nicht, dass man komplette Anwendungen in F# schreiben wird (obwohl das durchaus möglich wäre). Vielmehr macht F# für bestimmte Szenarien Sinn, die eine parallele, hochperformante Ausführung benötigen und in gleichem Maße formale Korrektheit abverlangen.

Neben diesen drei Highlights gab es natürlich noch eine Menge weiterer interessanter Vorträge. Es würde jedoch zu weit führen, wenn ich hier alle Dinge wiedergeben würde. Summa summarum war es eine gute Konferenz – auch mit einigen Schwächen. Dennoch, die interessanten Themen waren deutlich überwiegend. Soweit meine kurze Zusammenfassung zur QCon London 2009.