build broken

Obwohl wir Jeff Atwood schon vor Monaten von unseren Bloggerliste gestrichen haben, ich habe ihn noch nicht aus meinem Googlereader entfernt. Er ist ein Typ, der liebt viel Wirbel zu verursachen (Scott Hanselmann nennt ihn aus den Wörtern friend und enemy “my friendemy” ) aber manchmal trifft er den Nagel auf den Kopf. So auch in seinem letzten Artikel “The Non-Programming Programmer”.

…
I wrote that article in 2007, and I am stunned, but not entirely surprised, to hear that three years later “the vast majority” of so-called programmers who apply for a programming job interview are unable to write the smallest of programs. To be clear, hard is a relative term — we’re not talking about complicated, Google-style graduate computer science interview problems. This is extremely simple stuff we’re asking candidates to do. And they can’t. It’s the equivalent of attempting to hire a truck driver and finding out that 90 percent of the job applicants can’t find the gas pedal or the gear shift.

Wir haben wie viele von uns in der Webentwicklung vor vielen Jahren mit Scriptsprachen und mit prozeduralen – Spaghetti-Code – angefangen. Mit der Zeit wuchs unsere Webpräsenz zu einer unüberschaubaren Anwendung mit manchen Seiten, die keiner von uns mehr anfassen wollte – aus Angst vor den Konsequenzen.

Um etwas Ordnung in die Webanwendungen zu bringen, haben wir also vor 4 Jahren angefangen, nach einem 3-Schichten-Modell zu entwickeln. Wir haben neue Funktionalitäten und neue Anwendungen nur noch so gebaut und wir waren für eine kurze Zeit zufrieden. Alles lief gut. Als wir den Umstieg auf .NET begonnen haben, haben wir weiterhin nach einem Mehr-Schichten-Modell gearbeitet, wir haben nur die Anzahl der Schichten erhöht.

Ich lese gerade das Buch Agile Principles, Patterns and Practices in C# from Robert C. Martin und Micah Martin. Dabei bin ich auf eine so tolle Metapher gestoßen, dass ich sie hier unbedingt niederschreiben wollte (die Übersetzung ist frei von mir):

Refaktorisierung ist, wie die Küche nach dem Abendessen aufzuräumen. Das erste Mal, wenn du das überspringst, bist mit der Kochen schneller fertig. Aber das Fehlen von sauberem Geschirr und sauberem Arbeitsplatz führt dazu, dass die Vorbereitung diesmal länger dauert. Am liebsten würdest du das Aufräumen wieder überspringen. Tatsache ist, dass du heute ohne das lästige Geschirrspülen wieder schneller fertig wärst. Aber der Schmutz wächst und wächst. Jedes Mal dauert es länger, das richtige Küchengerät zu finden, die vertrockneten Schmutzschichten vom Geschirr ab zu kratzen, und so weiter und so fort. Das Vorbereiten des Abendessens dauert ewig…
Das Überspringen der Abwasch macht das Kochen eigentlich nicht wirklich schneller.

Der vorherige DbC-Artikel ist ziemlich “abstrakt” ausgefallen, es haben einfach Beispiele gefehlt. Das möchte ich hiermit nachholen.

Erstens muss man die IDE anpassen: im März kommt .NET 4.0 raus und da wird Design by Contract mitgeliefert. Man kann das Konzept aber jetzt schon anwenden, wenn man die Assembly zusätzlich installiert. Danach muss man die dll referenzieren und im Eigenschaftenfenster des Projektes im neuen Tab Code Contracts das Runtime Checking einstellen.

Jetzt zum Code: Nehmen wir eine ganz einfache Klasse Bill deren Objekte mit einem IRepository gespeichert bzw. geladen werden.

Endlich ist es geschafft. Ich habe das Buch “Clean Code” von Robert C. Martin a.k.a. Uncle Bob durchgelesen. Nach dem ersten Teil hier nun die versprochene Fortsetzung meiner Zusammenfassung:

10 Classes

Die erste Regel von Klassen lautet: Sie sollten klein sein.
Die zweite Regel von Klassen lautet: Sie sollten noch kleiner sein als das.

Klassen sollten eine hohe Kohäsion haben.
Kohäsion ist ein Maß dafür, wie stark die Methoden und Daten einer Klasse miteinander zu tun haben. Zur Verdeutlichung:
Eine Klasse, in der jede Membervariable von jeder Methode der Klasse verwendet wird, ist maximal kohäsiv.

Bald kommt .NET 4.0 raus, zusammen mit einem für C# neuen Konzept: Kontrakte im Code mit Spec# festzulegen.

Wikipedia definiert DbC folgendermaßen:

Design by contract (kurz DbC; englisch Entwurf gemäß Vertrag) oder Programming by Contract ist ein Konzept aus dem Bereich der Softwareentwicklung. Ziel ist das reibungslose Zusammenspiel einzelner Programmmodule durch die Definition formaler „Verträge“ zur Verwendung von Schnittstellen, die über deren statische Definition hinausgehen. Entwickelt und eingeführt wurde es von Bertrand Meyer mit der Entwicklung der Programmiersprache Eiffel.

Im Podcast “Talking with Jeremy Miller about ALT.NET” spricht James Avery mit Jeremy Miller über ALT.NET und die Community allgemein.

Beim ALT.NET Open Spaces in Seattle wurde wieder eine sehr negative Session angesetzt, “Why so mean?”. Scott Hanselman stellt hier sehr provokant die Frage, warum die Community immer mehr Energie aufwendet um zu Kritisieren, anstatt die neuen Technologien positiv nach aussen zu tragen. Dies kann ich nach meinen jetzigen Erfahrungen beim .NET Open Spaces in Ulm nicht bestätigen. Bei uns habe ich keinerlei negative Energie gespürt.

Da es für einen Entwickler wichtig ist, sich ständig weiterzuentwickeln, sollte man sich durch Austausch mit anderen Entwicklern, aktives Programmieren oder eben Bücher weiterbilden. Das Buch, das ich gerade lese, heißt Clean Code von Robert C. Martin a.k.a. Uncle Bob. Ich bin momentan bei der Hälfte des Buches und muss sagen, dass ich von dem Buch ziemlich begeistert bin. Da ich denke, dass es vielen Entwicklern helfen würde, besseren Code zu schreiben, habe ich den Text ein wenig verkürzt und zusammengefasst – was natürlich nicht heißt, dass man dieses Buch nicht lesen muss. Meiner Meinung nach ist es absolute Pflichtlektüre für jeden Entwickler, der was auf sich hält.

Seit dem ich Code schreibe, steht für mich ein klarer und verständlicher Code an oberster Stelle. Ich hatte dann vor ca. eineinhalb Jahren Code Complete und The Pragmatic Programmer gelesen und dadurch die ersten Antworten bekommen, WIE man den Code unter Kontrolle hält. Anfang 2009 sind wir – ich und Stefan – durch den Podcast von Hanselman und Uncle Bob auf das Thema SOLID gestoßen – und darüber auch eine ausgiebige Diskussion geführt. Eins war uns klar: die Ideen, die dahinter stecken, könnten die Antwort auf unsere Suche sein.