Buch-Rezension zu “Professional Test Driven Development with C#”

“Professional Test Driven Development with C#” von Jeff McWherter und James Bender erschien im Mai 2011 bei Wiley. Das Buch richtet sich an all die Entwickler, die ihre C#-Anwendungen nach Test-First entwickeln wollen.

Wer sich bisher noch nicht mit dem Thema Test Driven Development (TDD) beschäftigt hat findet in den ersten beiden Teilen des Buches eine gute und ausführliche Einführung ins Thema.

 

 

TDD Szenarien aus der Praxis

Der dritte Teil widmet sich den praxisorientierten TDD Szenarien. Im Gegensatz zu vielen anderen Büchern geht es hier um die schwerer zu testenden Teile:

• ASP.Net WebForms
• ASP.Net MVC
• JavaScript
• WPF
• Silverlight
• WCF

Im Buch wird zu jeder dieser Technologien aufgezeigt wo die besonderen Herausforderungen liegen und wie man diese Testen kann. Wann immer möglich sollte man die dazu passenden Patterns verwenden. Geht dies nicht ist man auf sich alleine gestellt: Das Buch erklärt leider nur genau einen Weg um die entsprechende Technologie zu testen.

 

Werkzeuge und Katas

Als Abschluss gibt es einen Teil der sich den Werkzeugen widmet. Bei der Vielzahl möglicher Test-, Mock- und DI-Frameworks ist es nicht leicht eine Auswahl zu treffen. Die Autoren vergleichen jeweils einige Werkzeuge aus dem gleichen Bereich und nennen die für sie wichtigsten Unterschiede. Auch wenn dies die eigene Recherche nicht ersetzt, so ist dies doch ein guter Ausgangspunkt um seinen Werkzeugkasten zusammen zu stellen.

Im Appendix wir noch auf das Thema (TDD-) Katas eingegangen. Kleinen Übungen sollen einem dabei helfen das gelernte zu verinnerlichen. Die Idee stammt aus dem Kampfsport und hilft dort die richtigen Aktionen und Bewegungen zur richtigen Zeit zu machen. Übertragen auf TDD bedeutet dies: Hat man immer und immer wieder geübt wie man erst einen Test und dann den produktiven Code schreibt, geht dies in einem über und man wendet die gleiche Technik auch mit dem Code direkt vor einem an.

 

Ein E-Book aber kein PDF

Wiley bietet für dieses Buch eine E-Book Version an, aber leider nur in den Formaten ePub und mobi. Gerade wenn ein Buch viele Code-Beispiele hat habe ich neben der Kindle-Version sehr gerne noch ein PDF. Nicht nur sieht der Code dort meist besser aus, er lässt sich auch einfach kopieren. Mir schein als ob Wiley der Konkurrenz in diesem Bereich noch weit hinterher hinkt.

 

Fazit

Den beiden Autoren ist in einem oft behandelten Themenbereich ein gutes Werk gelungen. Die beiden Einführungsteile liefern alles nötige Grundwissen damit man auch als Anfänger durchstarten kann. Die Auswahl eines Werkzeugkastens und das vermitteln der Ideen rund um TDD runden dieses Buch ab. Mir fehlen hier einzig noch einige alternative Ansätze zum Testen der behandelten .Net-Komponenten.

„The Art of Unit Testing“ ist zwar immer noch mein Favorit zum Thema TDD, dieses Buch folgt aber mit einem sehr kleinen Abstand.

 

Zum Buch

“Professional Test Driven Development with C#” von Jeff McWherter und James Bender, 2011 Wiley, ISBN: 978-0-470-64320-4, 360 Seiten, Englisch

Täglich reflektieren – nicht nur etwas für CCD

Täglich über seine Arbeit zu reflektieren ist eine der Praktiken, die bei Clean Code Developer (CCD) im roten Grad gefordert werden. Der rote Grad ist der Beginn einer Reise, die einem als Softwareentwickler zu einem (inneren) Wertesystem führen soll. Dies geschieht durch eine bewusste Auseinandersetzung mit seinem Metier und dem verinnerlichen grundlegender Praktiken und Prinzipien.

Im roten Grad gibt es neben der Reflexion noch zahlreiche andere Praktiken und Prinzipien. Ich finde diese Praktik aber besonders wichtig und schliesse mich der Begründung von CCD an:

Keine Verbesserung, kein Fortschritt, kein Lernen ohne Reflexion. Aber nur, wenn Reflexion auch eingeplant wird, findet sie unter dem Druck des Tagesgeschäftes auch statt.

Wer nicht über seine Arbeit reflektiert hat keine Chance diese zu verbessern. Man findet sicher weitere Möglichkeiten seine Arbeit anders zu machen. Doch lernt man dabei auch etwas? Natürlich kann es spannend sein seine Arbeit jeden Tag ein wenig anders zu gestalten. Doch ist das wirklich lernen? Braucht es zum anders machen nicht auch die Erkenntnis, welche der vielen Möglichkeiten einem helfen?

Werde ich wirklich ein besserer Programmierer wenn ich LINQ an jeder Stelle einsetze – unabhängig davon ob es da Sinn macht? Wird mein Code wirklich leserlicher, wenn ich var in allen Bereichen verdamme? Gewinne ich wirklich etwas beim Einsatz optionaler Parameter für Parameter die ich in jedem Fall angeben muss? Oder folge ich damit nicht einfach einem Hype?

Um eine Antwort darauf zu finden, muss ich nachdenken – und über meine getane Arbeit reflektieren.

 
Reflektieren – aber wie?
Um zu überprüfen ob meine erledigte Arbeit mit meinen Zielen übereinstimmt brauche ich als erstes Ziele. So banal dies tönt, so wichtig ist es. Wenn ich täglich reflektieren will, muss mein Ziel idealerweise innerhalb des gleichen Zeitrahmens erreichbar sein. Ist mein Arbeitspaket grösser, muss ich meine Arbeit in Stücke teilen, die ich innerhalb eines Tages erledigen kann.

Habe ich die Ziele, kann ich überprüfen ob ich diese Ziele erreicht habe. (Konnte ich das GUI wie gefordert erstellen? Habe ich allen doppelten Code entfernt?) Diese Ziele müssen aber nicht nur technischer Natur sein. Ich kann dabei auch darüber nachdenken, wie ich diese Ziele erreicht habe. Was hat mir bei meinem Arbeitsablauf gefallen? Was hat mich Zeit gekostet? Wo sehe ich Möglichkeiten meine Effizienz zu steigern oder mich zu verbessern?

Mir hilft es wenn ich neben den Zielen auch 3 oder 4 Punkte zum Tag im Allgemeinen aufschreibe. Dies kann von technischen Kniffen und der Ursache hinter kryptischen Fehlermeldungen bis zu ganz allgemein gehaltenen Aussagen reichen. (wie: „Nach jedem erledigten Teil ein commit.“)
Wenn sich Punkte wiederholen, weiss ich dass ich dem nachgehen muss.

 
Und wann?
CCD schlägt vor am Abend jedes Tages zu reflektieren. Ein Arbeitstag ist eine gute und greifbare Einheit, die für ein längerfristig ausgelegtes Vorhaben genau genug ist.

Ich überprüfe am Ende jedes Arbeitstages ob auch wirklich alle Bugfixes vom branch in den trunk gemerged wurden und ob meine Issues alle nachgeführt sind. Da ich dabei eh über meine an diesem Tag erledigte Arbeit nachdenken muss, nutzte ich diese Gelegenheit zur Reflexion. Der Mehraufwand für CCD ist dadurch vernachlässigbar.

Aber auch ohne CCD und ohne Issues die gepflegt werden müssen ist eine tägliche Reflexion machbar. Es braucht gar nicht so viel Zeit wie man vermutet. Mit ein wenig Übung geht dies in kürzester Zeit in weniger als 10 Minuten.

Ein weiterer positiver Nebeneffekt ist der dadurch gemachte saubere Abschluss des Arbeitstages. Wenn alles abgeschlossen ist gibt es auch keinen Grund mehr im Feierabend darüber nachzudenken. Der Feierabend dient dann wie vorgesehen der Erholung – und nur der.

 
Fazit
Die tägliche Reflexion scheint so banal und vernachlässigbar. Sie ist aber der Garant für eine stetige Verbesserung und dadurch unverzichtbar. Mit wenig Aufwand kann man die Reflexion in seinen Arbeitsalltag aufnehmen. Nur wer weiss wo er steht kann sich sinnvolle nächste Schritte überlegen. Und für beides hilft das tägliche reflektieren.

Buch-Rezension zu “Dependency Injection in .Net”

“Dependency Injection in .Net” von Mark Seemann erscheint 2011 bei Manning. Man bekommt das Buch aber bereits jetzt via MEAP. Da nur noch ein einziges Kapitel zu Spring.Net fehlt, wage ich mich bereits an eine Rezension.

Schon zu Beginn des Buches wird einem klar, dass man es hier mit etwas speziellem zu tun hat. Welches Buch zu irgendeinem IT-Thema beginnt mit einer Erklärung wie man eine Sauce béarnaise zubereitet? Man mag schon fast meinen Manning hätte die Bücher vertauscht, doch hat diese Einführung durchaus ihren Sinn.

Mark Seemann kocht gerne und sieht zwischen Dependency Injection (DI) und einer Sauce béarnaise parallelen: Bei beiden vermutet man es sei kompliziert und viele verzichten daher darauf. Die ersten Versuche können fehlschlagen, doch hat man mal den dreh raus wird man es überall anwenden können.

 
Klare Struktur
Will einem ein Buch beim Strukturieren der eigenen Programme helfen, so sollte es selber auch klaren Strukturen folgen. Dies gelingt „DI in .Net“ so gut, dass man die einzelnen Kapitel in beliebiger Reihenfolge lesen könnte.

Wer dem vorgegebenen Pfad folgt beginnt mit einer Einführung, lernt Patterns und wie man DI auch von Hand machen kann. Sind einem alle nötigen Abläufe bekannt, zeigt einem der letzte Teil die jeweiligen Vor- und Nachteile dieser DI-Container:

• Castle Windsor
• StructureMAP
• Spring.Net (fehlt derzeit noch)
• Autofac
• Unity
• MEF

 
Patterns und Anti-Patterns
Im Kapitel zu Patterns werden einem die Anwendungsmöglichkeiten von DI in .Net gezeigt. Seemann bevorzugt ganz klar die Abhängigkeiten wie Konstruktor den Objekten zu übergeben. Geht dies nicht kann man auch über Properties die Werte setzen oder bei jedem Methodenaufruf einen entsprechenden Kontext mitgeben.

Bei jedem Pattern wird immer erst erklärt wie das Prinzip funktioniert. Anhand der .NET Base Class Library (BCL) wird dann gezeigt, wo dies von Microsoft selber umgesetzt wurde. So zeigt Seemann wo man dieses Konzept schon bei der täglichen Arbeit nutzt – ohne das man DI verwendet. Ein ausführliches Beispiel rundet die jeweilige Vorstellung ab.

Bei den Anti-Patterns läuft es ähnlich ab. Nach einer Erklärung was er unter diesem Pattern versteht beschreibt Seemann wieso dies ein Problem ist. Die kleinen Abkürzungen ziehen Probleme mit sich die zwar harmlos aussehen aber zu grossen Verrenkungen führen. Gut gemeint ist halt noch lange nicht gut gemacht – dies gilt auch für die Konzepte rund um DI. Die vorgeschlagenen Refactorings zur Korrektur fand ich sehr hilfreich und sind das Geld fürs Buch bei weitem wert.

 
DI und Manning – war da nicht schon etwas?
Vor ein wenig mehr als einem Jahr habe ich schon ein anderes Buch zu diesem Thema mit dem Titel “Dependency Injection” vorgestellt. Mein Fazit war damals durchzogen und ich schlug vor, auf eine 2. Ausgabe zu warten. “Dependency Injection in .Net” ist zwar nicht diese 2. Ausgabe, aber es erfüllt meine damals erhofften Verbesserungspunkte. Das Buch ist sehr angenehm zu lesen und bekommt die Prinzipien und Vorteile auf eine sehr einfache Art erklärt.

 
Trotz MEAP bereits jetzt kaufen?
In der Mitte Januar vorliegenden Version ist das Buch noch nicht ganz fertig. Laut der Übersichtsseite fehlen noch ein Kapitel, das Vorwort, die Danksagung und der Index. Auch im Layout wird es in den nächsten Monaten noch zahlreiche Änderungen geben. Mir hat das Buch in der aktuellen Form schon sehr geholfen. Mir gefällt es aber auch schon bei der Entstehung Verbesserungen anregen zu können (via Online-Forum).

Wer grossen Wert auf ein perfektes Layout legt, sollte lieber noch bis zur offiziellen Veröffentlichung warten. Diese ist derzeit für den Juni 2011 geplant.

 
Fazit
Das Buch bietet eine gute Einführung ins Thema Dependency Injection. Durch den Aufbau und die vielen Tipps und Tricks ist es auch für Leute geeignet die mehr wollen als nur eine Einführung. Ich kann das Buch daher ohne Einschränkung weiterempfehlen.

Ich gehe sogar soweit dieses Buch als „Must Read“ zu deklarieren. Die darin vorgestellten Konzepte und Ideen sind so grundlegend, das man als Entwickler nicht darum herum kommt.

 
Zum Buch
“Dependency Injection in .Net” von Mark Seemann, 2011 Manning, ISBN 978-1-935182-50-4, >500 Seiten, [Englisch]

Buch-Rezension zu “Debug It!”

“Debug It!” von Paul Butcher erschien 2009 bei The Pragmatic Programmers. Wie es der Titel ahnen lässt, geht es um das Debuggen von Programmen. Braucht es dazu ein ganzes Buch? Ja! Und es verwundert wieso dies nicht schon früher geschrieben wurde.

Unter debuggen verstehen viele Entwickler die Zeit, in der sie mit Hilfe eines Debuggers versuchen zu verstehen, was ihr Programm gerade falsch macht. Butcher beschränkt sich nicht auf diesen kleinen Teil sondern behandelt den ganzen Ablauf der Bugbeseitigung. Dies reicht vom 1. Aufblitzen des Fehlers über die Bugmeldung, der Beseitigung des Bugs bis hin zum Verbessern der Abläufe um solche Fehler nicht erneut zu machen.

Damit sollte klar sein wieso für diesen Teil der Software-Entwicklung ein eigenes Buch angebracht ist.

 
Reproduzierbarkeit ist die Grundlage
Viel zu oft vermutet man die Ursache eines Bugs an einer bestimmten Stelle. Da man ja weis was es ist, beginnt man gleich zu reparieren. Das Problem tritt danach nicht mehr auf, also muss es gelöst worden sein. Was aber, wenn man mit einem Datensatz testet, bei dem der Fehler gar nicht auftaucht? Dann ist die ganze Aussagekraft des Nachtests dahin.

Der Hinweis von Butcher ist da sehr simpel: Bevor man etwas macht, muss der Fehler reproduziert werden. Ist dies zu komplex oder zu aufwändig, muss man weiter suchen bis man eine einfache, reproduzierbare Möglichkeit gefunden hat, um den Bug ans Tageslicht zu befördern. Dabei genügt es nicht, dass der Bug ab und zu auftritt. Denn wer sagt einem später, dass man den Fehler wirklich behoben hat und nicht nur gerade den Fall erwischt, wo der Bug sich mal wieder nicht zeigt?

Auf den ersten Blick mag dies zu aufwendig erscheinen. Nur wie viel Zeit verliert man wenn man den gleichen Bug ein 2. Mal beheben muss? Oder was ist wenn der Bug erst wieder in der Produktion auftritt? Ist angesichts der möglichen Auswirkungen wirklich keine Zeit für eine genaue Problemanalyse?

 
Ursachen bekämpfen statt nur Symptome behandeln
Ein weiterer Punkt der viel zu wenig beachtet wird ist was den Bug eigentlich auslöst. Ist es wirklich nur ein Problem des Entwicklers der bei einer Methode mit mehreren Strings als Argumente 2 davon vertauscht? Oder sollte man die Methode nicht ebenfalls anschauen und die Strings reduzieren?

Im Gegensatz zur Reproduzierbarkeit ist die Ursachenbehebung schon deutlich komplexer. Sobald sich die Bugs bei der Methode häufen, kann eine tiefgreifende Anpassung aber wiederum deutlich günstiger sein.

 
Wann sollen Bugs gefixt werden?
Im Buch werden 2 gegensätzliche Verfahren beschrieben, wie in der Praxis Bugs gefixt werden. Die einen beheben die Bugs sobald sie entdeckt werden, die anderen gehen diese erst am Ende der Entwicklungsphase an. Butcher bevorzugt klar die Variante mit der sofortigen Behebung des Fehlers. Dies gibt einem Vertrauen in den Code, da man weiss wir haben keine Bugs und funktioniert etwas nicht muss es ein bisher noch nicht bekannter Bug sein. Sind die bekannten Bugs gefixt, wird in der regulären Weiterentwicklung festgestellt, dass der Bug behoben ist.

Beim anderen Ansatz vermutet man den Fehler in einem bekannten Bug und ignoriert dies fürs erste. Hat man am Ende der Entwicklungsphase endlich die bekannten Bugs behoben, muss man nachtesten. Dann stellt sich zu oft heraus, dass ein Teil der Probleme nicht durch die gesammelten Bugs verursacht wird, sondern durch neue. So wiederholt sich der Kreislauf mit den Bugfixes, Nachtests und dem finden weiterer Bugs. Nur ist dafür in den meisten Projekten keine Zeit geplant worden und so kommt es zu grossen Verzögerungen.

Ich bin hier ganz der Meinung von Butcher. Die Bugs müssen so oder so behoben werden und dann kann man dies auch gleich machen.

 
Die Ideale Umgebung fürs Debuggen
Ein ganzes Kapitel ist der Umgebung gewidmet. Dies ist eines der Kapitel, bei dem man nicht einfach als einzelner Entwickler etwas ändern kann. Als unverzichtbar für eine dauerhafte Qualitätssicherung führt Butcher auf:

• Ein Versionierungssystem für Quellcode
• Automatische Tests
• Test-Attrappen (Mocks, Stubs, Testdoubles)
• Automatische Builds
• Continous Integration
• Statische Codeanalyse

Je nach Programmiersprache variieren die dafür zu verwendenden Werkzeuge. Im Appendix gibt es eine Liste mit zahlreichen Tools für Java, C# und C++.

 
Fazit
Das Buch bündelt eine ganze Reihe von Best-Practices. Vieles hat man schon gehört und etliches kennt man eigentlich schon lange. Die Kombination zusammen mit guten Beispielen gibt einem aber einen Ruck es auch endlich umzusetzen. Zumal ein Grossteil der Tipps unabhängig von Team, Programmiersprache und Vorgehensmodell ist. Put it in Action!

 
Zum Buch
“Debug It!: Find, Repair, and Prevent Bugs in Your Code” von Paul Butcher, 2009 bei The Pragmatic Programmers, ISBN 978-1-9343-5628-9, 232 Seiten

Buch-Rezension zu “Refactoring to Patterns”

“Refactoring to Patterns” von Joshua Kerievsky erschien 2004 bei Addison-Wesley. Es verbindet die beiden Themen Design Patterns und Refactoring.

 
Voraussetzungen
Um mit diesem Buch arbeiten zu können, sollte man unbedingt “Refactoring” von Martin Fowler zur Hand haben. Kerievsky verweist bei den Refactorings fast immer auf Fowler [F]:

Now I apply Inline Class [F] …

Dies hat den Vorteil nicht noch einmal alle Refactorings aufschreiben zu müssen, mit denen Fowler ein ganzes Buch füllte. Dies bedeutet aber auch, dass man ohne “Refactoring” grosse Verständnisprobleme haben wird.

Bei den Design Patterns ist es ein wenig anders. Man sollte mindestens schon einmal von “Design Patterns: Elements of Reusable Object-Oriented Software” der Gang of Four (GoF) gehört haben. Ein ungefähres wissen was beim Pattern erreicht werden soll genügt um dem Buch folgen zu können. Wer allerdings verstehen will was der Sinn des entsprechenden Patterns ist, wird nicht um weiterführendes Material herum kommen.

 
Wieso Patterns?
In der Einführung darf ein Kapitel zum Thema Patterns natürlich nicht fehlen. Kerievsky räumt darin mit einigen Vorurteilen und festgefahrenen Meinungen auf. Es gibt viele Wege ein Pattern zu implementieren. Dies ist besonders erwähnenswert, da dies allzu oft bestritten wird. Aus platzgründen wurde bei der GoF jedes Pattern nur einmal erklärt. Dies bedeutet aber nicht, dass es nur einen einzigen richtigen Weg zur Umsetzung gibt.

Ein weiterer guter Tipp von Kerievsky ist unter “Patterns Happy” zu finden. Nur weil man sich mit Patterns beschäftigt und diese nun überall gerne einsetzen würde, sollte man dennoch erst einmal Nachdenken. Macht es hier wirklich Sinn? Gewinne ich wirklich etwas durch das Pattern? Stehen Aufwand und Ertrag sowie die Wartbarkeit in einem akzeptablen Verhältnis? Ein blinder Wettlauf um möglichst viele Patterns anzuwenden führt am Ende sicher nicht zu besserer Software.

 
Der Katalog
Der Katalog von Kerievsky umfasst 27 Refactorings. Diese sind auf einer höheren Abstraktionsebene als diejenigen von Fowler. Kerievsky zeigt wie man die Bausteine von Fowler so anordnen kann, das man etwas grösseres daraus machen kann.

Vom Format her orientiert er sich ebenfalls an Fowler. Neben Titel, Zusammenfassung, Motivation, Ablauf und dem Beispiel folgt aber noch Variationen. Dieser Abschnitt dient zum Aufzeigen von alternativen Umsetzungen.

 
Fazit
Kerievsky gelingt es sowohl Patterns mit Refactoring zu verbinden wie auch neue Ideen zu beiden Themen zu liefern. Stellenweise hätte ich mir mehr Informationen zu den Refactorings oder den Patterns gewünscht. Dies lässt sich aber in “Refactoring” und “Design Patterns” nachschauen.

Das Buch kann ich jedem empfehlen, der die beiden Themen zusammen bringen muss. Wer sich allerdings nur für Patterns oder nur für Refactoring interessiert, wird mit diesem Buch nicht viel anfangen können.

 
Zum Buch
“Refactoring to Patterns” von Joshua Kerievsky, 2004 Addison-Wesley, ISBN 978-0-321-21335-8, 400 Seiten