See#

Das von der .NET Usergroup Konstanz-Kreuzlingen organisierte Event hatte eine eine sehr ansprechende Agenda und hochkarätige Speaker zu bieten. Meine Sessionliste:

• Windows Phone 7 Applications mit Silverlight, Laurent Bugnion
• IronRuby für .NET Developer, Thorsten Hans
• ADO.NET Entity Framework in N-Tier Applikationen integrieren, Robert Meyer
• Code-Generierung mit dem Text Template Transformation Toolkit (T4), René Leupold

Besonders schade fand ich, dass ich in Ermangelung meiner Parallelisierungsfähigkeiten bei folgenden Sessions nicht dabei sein konnte, denn sie hätten mich brennend interessiert:

• Powershell für Entwickler, Thomas Krause
• UI/UX – Grundlagen für Entwickler, Roland Weigelt
• Framework Design Guidelines – Wiederverwendbare Frameworks in C#, Rainer Stropek

SL4@WP7

Naja, nicht so schlimm, denn ich wurde von meiner Sessionwahl keineswegs enttäuscht. Den Anfang machte Laurent mit Windows Phone 7 Entwicklung. Angenehm: er spricht deutsch! Er gab einen guten Überblick über die Funktionen des neuen WP7 und die Programmiermöglichkeiten, darunter Silverlight. Highlight hierbei ist sicherlich, dass Laurent live in der Session gegen ein echtes Device die Programmierbeispiele ausgeführt hat und mit der Webcam dem Publikum gezeigt hat. Nice!

IR

Danach ging es schon weiter. Thorsten Hans zeigte in seiner IronRuby-Session wirklich beeindruckend, dass das .NET Framework mit der CLR und DLR eine revolutionäre Programmierplattform ist. Er ging zunächst auf die DLR und deren Komponenten ein und steigerte während seiner Session stetig den Geekfaktor. Zunächst zeigte er, wie man mit IronRuby umgeht – das Handwerkszeug sozusagen. Danach wurde es schon cooler: .NET-Assemblies und IronRuby im Zusammenspiel: IronRuby-Skripte (mit Scope & Context) aus .NET-Anwendungen aufrufen und vice versa. Als Beispiel zeigte Thorsten eine in Ruby geschriebene Validierung einer Kunden-Registrierung eines .NET-Programms. Ich war beeindruckt! Doch Thorsten ließ nicht locker und haute zum Schluß noch einen richtigen Knaller raus: Unit Testing einer .NET-Komponente mit IronRuby & RSpec!

Gut, dass danach die Mittagspause anstand, dass musste ich erst mal verarbeiten :) In der Pause hatte ich dank Basti auch die Gelegenheit, den von Thomas getesteten Sony Vaio VPCS12V9E/B selbst einmal “anzutesten”. Ich muss sagen, dass Thomas die Messlatte ganz schön hoch legt, denn für meinen Geschmack ist die Verarbeitung des Sony wirklich gut. Das Gehäuse ist kein Shiny-Alu-Guß, aber auch kein Plastik. Die Chiclet-Tastatur ist ok, der Druck relativ sensibel. Performance gut, Display in Ordnung.

EF4

Nach der Mittagspause ging es zu Robert’s Entity Framework Session. Er ging zunächst auf die “Schwierigkeiten” der ersten Version des Entity Frameworks ein, um danach gleich mit den Neuerungen von EF4 nachzulegen. An seinem Vortrag besonders gefallen haben mir die vielen kleinen Beispiele aus der Praxis, mit denen Robert seine Expertise in diesem Bereich einmal mehr zu unterstreichen wusste. In der zweiten Hälfte der Session widmete er sich den neuen Features wie (echten) POCO-Support, Domain-First-Design und natürlich dem IObjectSet<T>. Robert ging auch auf Testbarkeitskriterien von EF4-Lösungen ein und nennte einige Leitfäden zum Testing. Fazit: eine guter EF4 Überblick mit wertwollen Praxisbeispielen vom Experten.

T4

Die letzte Session hatte es in sich: T4. René zeigte zunächst die Grundlagen. Was ist T4, Wieso T4. Aufbau, Architektur, Anwendung. So einfach kann eine Einführung sein. Doch dann ließ es sich auch Rene nicht nehmen, in die Tasten zu greifen. Exemplarisch an Anwendungsbeispielen wie z.B. EF-Templates oder Templates für Unit Testing ging er auf die Features der T4-Engine ein. Bemerkenswert: René lässt sich auch durch kleinere technische Probleme nicht aus dem Konzept bringen. Er hatte wirklich eine Fülle von Beispielen parat, mit denen er reichhaltigen Funktionalitäten von T4 erläuterte. Ein Text- und Code-Jongleur, kann ich da nur sagen.

Trotz dieser guten Sessions war mein Eindruck von See# nicht ganz perfekt – doch daran war ich selbst schuld. Durch die lange Anreise habe ich die Keynote von Golo verpasst. Die lange Reisezeit war schlußendlich auch der ausschlaggebende Faktor, warum ich leider nicht mehr bei der Grillparty und dem .NET Coding Dojo mit Stefan dabei sein konnte. Sehr schade. Nichtsdestotrotz konnte ich wieder auf dem Event wirklich tolle neue Entwickler-Kollegen kennenlernen, darunter Peter Bucher, Roberto Bez, Jürgen Gutsch und Thorsten Hans. Für mich hat sich dadurch die Teilnahme an See# doppelt gelohnt.

Let’s go to NRWConf!

Kaum ist die eine Community Conference zu Ende, steht die nächste schon vor der Tür – die NRWConf 2010 am 9./10. September steht an. Wenn man sich die Agenda der NRWConf ansieht, dann klingt das überaus vielversprechend. Also ich werde mir definitiv wieder eine Menge Sessions so zu Gemüte führen und vieles dazu lernen. Am Abend gibt es – wie auch bei der See# – ein .NET Coding Dojo. Diesmal jedoch mit meiner Wenigkeit als Operator. Ich denke es wird nicht nur eine Menge Spaß machen, sondern wieder einmal erkenntnisreich sein ;-)

Ich freue mich!

Und genau so ist es auch. Zumindest für mich. Ich habe lange Zeit Tests und Implementierung in separaten Projekten entwickelt. Bis ich bemerkt habe, dass es mir nicht hilft, sondern mich eher bei meiner Entwicklung stört. Seitdem halte ich Tests und Implementierung immer ganz nah beieinander, sozusagen „Seite an Seite“. Ich möchte in diesem Post meine Beweggründe & Konsequenzen für Side-by-Side-Specs (oder Near-Specs, wie ich es gerne nenne) schildern, und somit meine Antwort auf Stefan’s Frage geben.

Nun zunächst einmal beschränke ich mit bei den Near-Specs auf Unit Tests. Ganz klassisch im Sinne des TDD. Integrationstests sind bei mir nach wie vor Far-Specs, also separate Projekte. Doch es soll ja um die Unit Tests gehen, besser gesagt um Tests, die aus dem Test-First-Ansatz heraus entstehen. Das können Tests bei TDD oder aber auch Specs bei BDD sein. Ergo: Tests, mit denen ich meinen Code designe & entwickle, halte ich sehr nah am Code.

Verhalten greifbar formen

Doch wieso sind bei mir die Tests nun an der Implementierung dran? Es gibt einen ganz einfachen und für mich auch unschlagbar effektiven Grund: Die Tests sind greifbar. Sie sind dort, wo ich sie brauche, nämlich an dem Verhalten, für das ich sie zur Spezifikation gebraucht habe. Seit dem ich die Tests an der Implementierung habe, „forme“ ich auch mehr und öfter. Soll heissen: Ich führe öfter und effizienter Refactorings durch. Nicht nur vom SUT, sondern natürlich auch von den Tests selbst.

Überhaupt ist es mit den Tests im Implementierungsprojekt ein ganz anderes, viel effizienteres arbeiten. Wenn ich nach einiger Zeit wieder einmal in einem Projekt etwas zu tun habe, schaue ich mir die Tests an. Das Schöne bei den Near-Specs ist jetzt, dass ich sehr schnell zwischen Spezifikations- und Implementierungssicht wechsle und deutlich zügiger navigieren kann. Das fällt mir besonders bei Tests mit mehreren Abhängigkeiten / Mocks auf. Ich komme mit dieser Art von „Code lesen“ viel besser zurecht als vorher mit dem hin- und herspringen zwischen mehreren Projekten.

Zugegeben, anfangs tat ich mir noch ein wenig schwer, denn schließlich ist die Anzahl der Testklassen – genereller: die Menge an Testcode – für ein SUT meist deutlich mehr. Neben der Umgewöhnung des „nicht mehr über Assembly-Boundaries“ hinweg arbeitens hatte ich das Gefühl, dass mich der Testcode „stört“ oder mir „im Weg steht“. Doch dieses Gefühl war schnell wieder weg, als ich das Prinzip auf größere Projekte angewendet habe und immer wieder die Tests für die Spezifikation und das Codeverständnis gebraucht habe. Spätestens dann war bei mir die Erkenntnis da: Side-By-Side-Specifications Rule!

Doch mit dieser „Colocation“ der Tests an die Implementierung tauchen neue Fragen auf. Eine ganz besonders oft gestellte Frage ist die der Auslieferung der Tests in Release-Assemblies. Es ist schließlich erstrebenswert, nur das in ein Release einfliessen zu lassen, was auch wirklich vom Benutzer gebraucht wird: die Funktionalität. So stand ich auch vor dieser Aufgabe, welches sich aber sehr schnell und vor allem einfach bewältigen ließ.

Reduce to the Max

Die Idee ist denkbar einfach: Wenn ich Tests und Implementierung zur Entwicklungszeit nicht trenne, dann trenne ich sie eben später, undzwar zur Auslieferungszeit. In einfachen Worten: der Build muss diese Aufgabe erledigen. Da ich sowieso meinen Code über Build-Skripte bauen lasse, lag es sehr nah, diese Skripte einfach anzupassen. Für meine eigenen Projekte habe ich oft ein kleines Powershell-Skript. Bei größeren Projekten oder CI-Umgebungen ist der Aufruf eines eigenen Post-Clean-Events vor dem Build ein guter Extension-Point.

Als ich die Menge und den Inhalt der Kommentare bei Stefan’s Post gesehen habe, dachte ich mir nur: warum schreiben so viele darüber und finden es „schwierig“ oder „unsauber“, ohne es offensichtlich einmal probiert zu haben? Ich habe es probiert und ich fand es überhaupt nicht schwierig – ganz im Gegenteil. Jetzt ist das für mich eine viel angenehmere, effizientere und vor allem intuitivere Arbeitsweise. Das Build-Skript zum filtern der Testartefakte ist denkbar einfach, bei mir sind das meistens nur so 10 bis 20 Zeilen. Schließlich ist es ja auch „nur“ ein Release-Build. Ich rufe es nicht die ganze Zeit auf wie ein CI-Build, und CD mache bzw. brauche ich derzeit auch nicht.

„Soooo lange, wie ich brauche, diese Kommentare überhaupt zu lesen, brauche ich nicht einmal, wenn ich sogar das Build-Skript per TDD erstelle“ war mein Gedanke, als ich mit dem Lesen der Kommentare fertig war. Und da ich ein Freund von empirischen Erkenntnissen bin, dachte ich mir: „Auf geht’s, das machst Du jetzt!“. Gesagt getan. Das Ergebnis kann man sich auf github ansehen. Erkenntnis: Die Entwicklung des Build-Skripts (ohne TDD Framework und mit meinen „bescheidenen“ Powershell-Kenntnissen) hat etwas mehr als eine Stunde gedauert. So lange habe ich in etwa auch zum Lesen der Kommentare gebraucht ;-)

Separation of Concerns

Doch zurück zum Thema. Beim Lesen der Kommentare ist mir auch aufgefallen, dass man öfter das Argument der „Separation of Concerns“ (SoC) gegen die Zusammenführung von Tests und Implementierung anbringt. Es sei im Sinne der SoC, Tests von der Implementierung zu trennen. Auch gute Freunde von mir, wie z.B. Tehlike – für den ich im Übrigen diesen Post auch auf Englisch verfasst habe – entgegneten mir das gleiche Argument. Dazu mein Statement:

Tehlike, yanılıyorsun! ;-)
(Auf deutsch: Tehlike, Du irrst Dich!)

Ja, ich denke diejenigen irren sich, die SoC als Argument für eine Trennung von Tests & Implementierung anbringen. Sie irren sich meiner Meinung nach sogar gewaltig. Denn SoC ist in meinen Augen bei genauerer Betrachtung sogar ein Argument für die Zusammenlegung von Tests und Implementierung.

Separation of Concerns besagt nämlich, dass unterschiedliche Zuständigkeiten eines Objekts voneinander getrennt werden sollten. Zuständigkeiten sind im Sinne der Domänenmodellierung und Systemanalyse Aspekte von Verhalten und Funktionalität. Ergo: Unterschiedliche Zuständigkeiten eines Verhaltens sollten voneinander getrennt werden. Ein schönes Beispiel ist der Taschenrechner. Die Funktionalität des Addierens des Taschenrechners gestaltet sich aus dem Tastenfeld, der Recheneinheit, und der Anzeige. All das sind Aspekte der Funktionalität, die in eigenständige Zuständigkeiten münden. Im Sinne der „Separation of Concerns“ sind diese Aspekte zu trennen und damit die Komponentenorientierung und Wiederverwendbarkeit zu stärken.

Completeness of Concern

So weit, so gut. Doch Separation of Concerns bedeutet für mich im Umkehrschluß auch, dass man eine Zuständigkeit einer Funktionalität auch zusammenhalten sollte. Ein einziger „Concern“ sollte in sich geschlossen sein. „Das ist er doch automatisch“ denkt man sich. Naja, ganz so einfach ist es meiner Meinung nach nicht. Denn eine Zuständigkeit einer Funktionalität findet man in der Software-Entwicklung oftmals nicht als „ganze Einheit“ an einem Fleck, sondern überall verteilt.

So wird z.B. in der klassischen Softwareentwicklung die Zuständigkeit in den Requirements erfasst. Man findet sie in der Use-Case-Dokumentation und in UML-Diagrammen wieder, diesmal mit ein oder zwei Szenarien. Natürlich wird das Verhalten und dessen Aspekt auch in den Tests manifestiert – dazu sind sie ja da. Und – wer hätte das gedacht – die Funktionalität findet man auch im Code wieder. Resultat: Ein einziger Concern, der im Entwicklungsprozess an allen möglichen Stellen auftaucht. In einem solchen Szenario ist es für den Entwickler meistens wie ein Puzzle, bei dem die Puzzlestücke überall sind – nur nicht auf dem Tisch.

Es ist also für die „Vollständigkeit einer Zuständigkeit“ nicht hilfreich, Tests und Implementierung voneinander zu trennen. Weiterhin hat das Trennen von Tests und Implementierung nichts mit Separation of Concerns zu tun, denn schließlich geht es sowohl bei den Tests als auch bei der Implementierung um einen einzigen Concern – dem Aspekt der Funktionalität, die das SUT eben abbilden soll.

Es ist gerade die Fraktion der BDD-Anhänger, die genau diesem Umstand mit all Ihren Argumentationen und Prinzipien hervorheben möchten. Sie reden nicht von Tests, sondern von Spezifikationen, sie reden nicht über Verifikation, sondern über Verhalten. Ja, sie gehen sogar soweit und reden im Sinne der Context-Specifications von „Concerns“, also „Zuständigkeiten“. Das alles sind klare Hinweise, das die Spezifikation eines Verhaltens und deren Umsetzung als unzertrennliches Paar zu betrachten sind. Übrigens ist diese „Expressivität“ auch ein Grund, warum „BDD“ so gut geeignet ist für Einsteiger in TDD bzw. Test-First.

Feels just like it should

Wenn man mal eine gewisse Zeit per TDD/BDD entwickelt, dann fällt einem oft auf, dass man bei jeder Änderung mindestens zwei Dinge ändert. Man ändert oder erweitert die Tests und man ändert oder erweitert die Implementierung. Ein Verhalten, eine Zuständigkeit, doch zwei Perspektiven, zwei Änderungspunkte.

Das ist bei Far-Specs, (also getrennten Tests und Implementierung über Assembly-Boundaries) genauso wie auch bei Near-Specs (Tests & Implementierung Seite-An-Seite). Doch bei Near-Specs ist es einfacher, schneller und intuitiver, Änderungen am System durchzuführen. Darüber hinaus wird das Streben nach „Vollständigkeit eines Verhaltens und deren Zuständigkeit“ gestärkt. Das wiederum zahlt auf Lesbarkeit, Wartbarkeit und Flexibilität ein.

Seit nun seit knapp 3 Monaten entwickle ich Unit Tests, TDD & BDD ausschließlich per „Side-By-Side-Specifications. Diese „andere“ Art der Codeorganisation ist für mich äußerst angenehm und effektiv gleichermaßen. Für mich ist es ein stückweit näher dran am „TDD-Spirit“, dem test- bzw. spezifikationsgetriebenen designen und entwickeln von Software. Mit Tests & Implementierung nebeneinander fühlt es sich so an, wie es eigentlich sein sollte.

Also: Feels just like it should ;-)

It’s been something like a week since Stefan asked a provoking question in his blog (german): „Where to put the Tests?” He wrote that he’s strictly separating tests from their implementation in separate projects. However, motivated by a statement of me, he gave the idea of having tests & implementation in the same project a try. Wow, all code in one assembly. He as well as a punch of commentators on his blog came to the conclusion, that separating tests from implementation using separate projects is better. I argue the converse.

It’s simply old-fashioned style to separate tests & implementation with separate projects. I did separate my tests from implementation code for years. However, about half a year ago, I realized that this separation doesn’t help me much. Instead, it hinders my development process. Since then I keep tests & implementation together in one project. They are located as near to each other as possible. Let’s name this “side-by-side” residency. In this post I want to show and explain the main reasons, consequences and experiences in favor of “side-by-side specifications” or “near specs”.

Well, first of all, I reduce the practice of „near specs” to unit tests only. Just as in classical sense of TDD. Integration tests and verification-driven tests are located in separate projects (thus being “far specs”), as usual. For me, putting tests and implementation altogether in one project makes sense in test-first approaches. That is, TDD testing or BDD specifications. Ergo: It’s about tests I use to drive my implementation. Tests, which I’m using to design and develop the desired functionality.

The grip of behavior

So, what’s the point then to put tests and implementation side-by-side? In my opinion there’s a quite naive, yet effective reason: You get grip of your tests. The tests are simply there. They’re where I need them; they’re there where I expect them. They are right there where the behavior is. Since I keep tests next to my implementation, I’m just better able to “put them in shape”. Means: I do refactorings a lot more effective and frequent. Naturally not only on SUT, but tests as well.

Generally speaking, it’s a kind of different, more efficient style of development to work with implementation & tests right at hand. Coming back to projects after some time makes it a breeze. I just look and read the tests. Then, I navigate frequently between tests and implementation to understand the details. “Near specs” make it less painful and more pleasant to read the code. This is especially the case for tests where several dependencies / mocks exist. No jumps through projects, no loading of solutions here and there. Just reading, that’s it.

To put it candidly, it was hard at start. The number of test classes – or the amount of test code in general – is quite a lot compared to implementation code only. I had to get used to it somehow. From time to time, I had a strange feeling that my tests are distracting me. It was so unusual for me that I felt that my tests “messed up” my organization in my “production” project. It didn’t last long though. As I continued to keep my tests right where my implementation is, I more and more realized how cool and beneficiary it is to do so. Especially as I utilized this approach on a larger codebase. Since then, it’s clear for me: putting specifications/tests side-by-side rules!

Wait, the world’s not shining always. New questions arise with this new “colocation” of tests right where the implementation is. Probably the most often asked is how the release assemblies of such applications look like. Needless to say, it’s desirable to let release assemblies contain only what the customer actually needs: the functionality. However, with tests in same assembly, how would you achieve this?

Reduce to the Max

The solution is quite simple: If tests and implementation are no longer divided in design- or development-time, then the split-up needs to take place later on, at delivery-time! Simply put, the build needs to take care of this task. Since I’m used to use build scripts for my projects, it’s quite a common thing for me to adjust end enhance my scripts to filter out the test classes and test-related references. For my own tiny projects, I most often use powershell scripts. At larger contexts with CI and Buildsystems, a call to a cleanup extension is an obvious, handy task.

Back to Stefan’s post. As I read through comments, I thought to myself: Why do so many people write so much about it and judge this approach as “tricky” or “dirty” without obviously not having tried it once? I did give it a try and I’m feeling very fine with it. It’s neither difficult, not dirty at all. The contrary is the case. Now that I use „near specs“, my daily TDD and development life is more pleasant and effective than before. Building a filter for test-related artifacts is an easy task. In my scripts, I usually need about 10 lines for this. Moreover, it’s worth to keep in mind that filtering is “only” needed for release builds. No CI build whatsoever affected.

Once read through the whole thread, I just said to myself: „I even would build my build script test-first faster than reading all this”. As some of you know me as a friend of empiric results and measurement, it’s obvious that I needed to check if my statement really would turn out true. Just do it and see if it’s really that fast and easy. No sooner said than done! I pushed the results to my github repository. Brief summary: Even without test-framework and with my „limited“ powershell knowledge, I was able to build my test-artifact filtering in about the same amount of time I spent to read the blog. ;-)

Separation of Concerns

Another argument quite often rose against putting tests and implementation together is “Separation of Concerns” (SoC). “Partitioning tests and implementation in separate projects is following this principle”, it’s being said. Even good friends of mine, like Tehlike bring SoC onto the table against “near specs”. By the way, I specially write this article in English for Tehlike, and therefore:

Tehlike, yanılıyorsun! ;-)
(In english: Tehlike, you are mistaken!)

Yes, I think that those are mistaken who think that SoC is a reason to split tests and implementation. From my perspective, the opposite is the case. SoC is – once considered to look at it carefully – even a reason to put tests and implementation side-by-side.

The essence of Separation of Concerns is quite easy: diverse perspectives, say „concerns“, of a behavior of an object should be separated. „Concerns“, in context of domain modeling and system analysis, are aspects of behavior and functionality. Take the calculator example. The functionality of „addition“ of a calculator has different aspects. You need to enter the numbers through keys, the calculation unit needs to add the numbers, and the sum needs to be displayed. All concerns – better: different concerns – of one functionality. With respect to „Separation of Concerns“, those aspects need to be separated. In consequence, a component-oriented and reusable solution is fostered.

Completeness of Concern

So far, so good. But wait. For my understanding, Separation of Concerns means by implication, that a single concern should strive towards entirety. That is, one single concern ideally should aim completeness. „Isn’t this automatically the case?“ you might think. Mhh, not really, in my opinion. Most often, one concern is located on very diverse and unusual locations within a software development process.

Take the „classical“ software engineering scenario as an example. A behavior and its concern is described in requirements documentation. You can find different, mostly edgy details of the same concern in UML diagrams and Use Case documents. Of course, tests reflect the concern again. Well crafted, tests most likely specify the concern at its best. Naturally, the concern is in production code, implanted as final functionality of the system. And what’s the result now? Straight answer: The result is a mess. Most often, a developer finding himself in such a situation is faced with puzzle pieces everywhere – but not on the table.

Hence, for me it’s obvious that partitioning tests and implementation in separate projects is not helping me to strive towards „Completeness of Concern“. Moreover, splitting up tests an implementation is not related to Separation of Concerns. Both tests and implementation care about the same concern, that’s the simple truth.

BDD lovers in the wild will clap their hands. The abovementioned is more or less the same they proclaim over and over. They don’t talk about tests; they care about “specs”. They don’t talk about verification; they care about “behavior”. Yes, they even care about concerns, drivers and observations. Altogether, this is even for beginners quite a good hint towards a mindset, where tests and implementation build a chained, inseparable pair.

Feels just like it should

Let’s face it. Once developing a reasonable time in TDD/BDD style, you clearly realize one thing: Whenever you need to change or extend the system, you have at least two „changepoints“. First, you change tests. Right afterwards, you change your implementation. One single behavior, one single concern. But two perspectives, two edits. That’s the case for „far specs“ (that is, tests located in a separate project) as well as for “near specs” (that is, tests residing in the same project along with the implementation “side-by-side”).

The difference: With near specs, you change and develop the system faster, & easier. It’s simply more efficient and intuitive. Near specs foster „Completeness of Concern“. This essentially contributes to better readability, maintainability and flexibility of the overall system.

It’s been more than 3 months now since I started to structure my unit tests strictly side-by-side along to my implementation. For me, this “different” style of code organization is absolutely pleasant and effective. Right now, I can’t think of switching back. In my opinion, putting tests and implementation as near as possible is in favor of the “TDD spirit”. With tests and implementation being at the same place, for me TDD now more and more “feels just like it should” ;-)

In vielen Kommentaren und Blog-Posts wurde die jüngste Bewegung über .NET Coding Dojo’s als „für die Community nicht hilfreich“ tituliert. Jetzt, wo es zwei verschiedene „Stile“ von .NET Coding Dojo’s gäbe, sei auch noch ein entscheiden und ein „was ist nun besser“ hinzugekommen. Den Meinungen kann ich mich größtenteils anschließen. Doch ich möchte noch etwas hinzufügen: Das philosophische, frenetische, ja fast religiöse Reden und Ausarbeiten dieser „Stilunterscheidung“ zwischen Schwarm und Latifa ist mir doch deutlich zu krass und hat mich über die letzten Tage mehrheitlich nur dazu gebracht, beim Lesen der Meinungen immer wieder zu denken: „Hääh, oder wie oder wat?“

Eine Bereicherung

Insofern finde ich es ein schlechtes Signal und eine besorgniserregend überspannte Kommunikation, von „der Teilung der Dojo-Welt“ oder der „Trennung der Community in zwei Lager“ zu sprechen. Das Gegenteil ist der Fall, die „Community“ wird bereichert. Sie wird bereichert um andere Sichtweisen, um andere Vorgehensweisen und andere Menschen – ganz unabhängig davon, ob die Bereicherung nun als gut oder schlecht zu bewerten ist.

Darüber hinaus ist es schlichtweg überzeichnet, wenn man sich so massiv mit der „Gestaltung von Coding Dojo’s“ auseinandersetzt und die „Stilrichtungen“ oder “Schulen“ miteinander in fast religiös ausufernder Manier differenziert. Coding Dojo’s sind bei weitem nicht das einzig wichtige für einen Software-Entwickler, zumindest für mich. Ich mache Coding Dojo’s aus Spaß – in meiner Freizeit. Andere machen es vielleicht aus einer anderen Motivation heraus. Aber das in letzter Zeit ist mir deutlich zu viel des Guten, wenn es überhaupt dem Attribut gutwillig genüge träge. Es gibt auch noch andere Dinge, also sollte man das ganze Tohuwabohu um die .NET Coding Dojo’s relativieren.

Ich bin mir durchaus bewußt, das die Erhebung meines „Latifa“-Stils ein Treiber in dieser Entwicklung war, wenn auch nicht der einzige. Jedoch war es nicht meine Motivation, irgendwelche „Lagerschaften“ zu erarbeiten. Nein, vielmehr ist diese Formalisierung der Regeln aus der Erfahrung des Coding Dojo’s bei den dotnetpro.powerdays entstanden. Meine Wahrnehmungen waren nämlich deutliche Divergenzen zwischen dem Verhalten einzelner Teilnehmer und den als „Latifa“ titulierten Werten.

Latifa ist tot, es lebe Latifa

Ich denke auch, dass die Werte-Prinzipien sowie auch andere Prinzipien, auf die ich hier nicht näher eingehen werde, nicht als spezifisch für ein Coding Dojo reduziert werden können. Ich denke, die „Latifa-Werte“ sind über ein Coding Dojo hinaus auch im täglichen Miteinander und Arbeiten beachtenswert. Deswegen – und wegen der für mich zu konterkarierenden Darstellung der Stilisierung von Dojos – werde ich die Latifa-Werte nicht mehr ausschließlich im Kontext von Coding Dojo’s anwenden. Es gibt kein „Latifa-Coding-Dojo“ mehr. Weil für mich diese Werte & Prinzipien nicht nur für Coding Dojo’s gelten, sondern in meiner Welt Anspruch auf Allgemeingültigkeit erheben.

Schwarm drüber?

Also, alles wieder gut, alles wieder lustig und soz. „Schwarm drüber“? Nein, ist meine klare Antwort. Jedenfalls nein für mich. Es ist ja auch meine Perspektive, die ich hier schildere. Ich habe für mich erkennen und lernen dürfen, dass ich offensichtlich eine eingeschränktere Menge an Gemeinsamkeiten mit Meinungen, Verfahrensweisen, und Prinzipien anderer habe. Besonders ist mir aufgefallen, dass ich – für mein eigenes Bedauern – mit Ralf und Stefan weniger Gemeinsamkeiten habe als ich zunächst vermutete.

Ich habe den Eindruck, dass meine Ansichten & Werte sich von den Werten & Prinzipien von Ralf & Stefan auf fachlicher Ebene deutlich unterscheiden. Meine Wahrnehmung ist weiterhin, dass die Unterschiede zwischen mir und Ralf/Stefan auf persönlicher Ebene noch deutlicher sind. Für mein Empfinden ist für diese Relation der Begriff des „diametralen entgegen stehens“ durchaus treffend.

Das .NET Coding Dojo für „Profi’s“ ist Schwarm ?!?

Ein Beispiel dafür ist für mein Empfinden die Zielsetzung bei Coding Dojo’s. Ich mache Coding Dojo’s in meiner Freizeit und ich möchte in meiner Freizeit Spaß haben. Das ist für mich soetwas wie ein Primärziel. Diesen Eindruck habe ich von der Zielsetzung von Ralf nicht. Für mich stellt sich die Zielsetzung von Ralf als zielorientiert und leistungsorientiert dar. Bei Ralf geht aus meiner Sicht deutlich mehr um „professionelles Lernen“.

Ein weiteres Indiz ist sicherlich die unterschiedliche Betrachtungsweise von „professioneller & moderner Softwareentwicklung“. Für mein Empfinden genügen doch eine ganze Menge an Ansichten und „Lehren“ von Ralf & Stefan nicht mehr meinem Anspruch der professionellen & modernen Softwareentwicklung.

Das fängt für mich schon bei unnötigem Sauberkeitsfetisch wie dem Trennen von Tests und Produktionscode in verschiedene Projekte an. Das ist für mich ja schon fast wie jeden Tag das Auto durch die Waschanlage zu fahren. Zum Einen, weil der Code ein kleines Code Kata im Coding Dojo ist und keine Mission-Critical-Anwendung. Zum Anderen, weil es schlichtweg nicht mehr zeitgemäß ist, Tests vom SUT zu trennen. Je näher sie zueinander stehen, um so besser.

Frankreich wird Fußballweltmeister

Ich könnte jetzt weitermachen und „weiterwettern“, z.B. das für mein Dafürhalten das von Ralf & Stefan transportierte „TDD“ mit der Anleitung des „vorher die Lösung auf Papier erfassen“ und dann „gestärkt und mit klarem Kopf Tests programmieren“ so viel mit TDD zu tun hat wie Frankreich mit der Fussballweltmeisterschaft (Anmerkung des Autors für den “ernsthaften” Leser: Das war ein kleiner übertriebener Witz am Rand. Bitte schmunzeln, Danke.)

Doch ich werde dieser Versuchung widerstehen, denn ich habe für mich erkannt, dass es eben verschiedene Ebenen und subjektive Wahrnehmungen von professioneller & moderner Software-Entwicklung gibt. Ich hatte schon im meinem Artikel über „mein .NET Coding Dojo“ (ergo: meine Perspektive eines Coding Dojo’s) schon angedeutet, dass ich mich gerade mit dem Thema TDD & Planung noch deutlich sowie ausführlich äußern möchte und werde. Zurück zur Professionalität & Modernität.

Meine Wahrnehmung der unterschiedlichen Grade und Auffassungen von fachlicher sowie persönlicher Professionalität & Modernität zwischen dem nun nicht mehr vorhandenen „Latifa-Dojo“ und dem „Schwarm-Dojo“ ist es auch, die mich dazu veranlasst, ab heute auch bestimmte Begriffe bei meiner Kommunikation mit .NET Coding Dojo’s explizit auszuschließen. Dazu zählen „Lerne & Lehre“, „Professionell“ & „Modern“.

Das heisst nun keineswegs, dass es keine Coding Dojo’s gibt, die moderne & professionelle Software-Entwicklung fokussieren. Das heisst vielmehr, dass ich mir moderne & professionelle Methoden bei einem Coding Dojo wünsche, aber sie eben nicht bei allen erfüllt werden.

Fun as fun in fun

Abschließend kann ich für mich als folgendes Fazit ziehen: Ich werde weiter .NET Coding Dojo’s besuchen. Vor allem, weil sie mir Spass machen. Wenn sie mir keinen Spass mehr machen, dann werde ich sie auch nicht mehr besuchen. Der Spass steht bei mir im Vordergrund, denn es ist für mich eine Freizeitaktivität. Diese Freizeitaktivität hat mir viele Erkenntnisse beschert. Und das ist gut so.

Aber ich werde mich auch von Coding Dojo’s distanzieren, die dieses Primärziel für mein Dafürhalten nicht erfüllen. Dazu zählt für mich das „Schwarm-Dojo“. Es mag andere Meinungen dazu geben und auch andere Entwickler, die eben mehr Wert auf andere Komponenten legen. Für diese mag viellecht auch ein „Stil“ wie der Schwarm-Dojo schön, gut, frisch und fröhlich sein. Gut. Für mich ist es eben nicht so.

Selbst wenn die inhaltliche Substanz eines Schwarm-Dojo’s für mich attraktiv wäre (was sie für mich nicht ist), ja selbst dann würde ich mich auf Grund der momentan für mein Empfinden zu großen persönlichen Diskrepanz zu Ralf & Stefan mit großer Wahrscheinlichkeit nicht dazu motivieren können, ein Dojo mit Ralf & Stefan zu besuchen.

Auf dem Eisberg

Ich werde weiter auf dem Eisberg sein. Wenn meine Werte, meine Prinzipien und meine Arbeitsweise mein Eisberg sind, dann bleibt mein Name ist zwar Ilker, aber auf dem Eisberg bin ich so ähnlich wie Kalle. :-) Na juuud juuuud juuud juuud juuud…

Doch nicht nur die Location war ganz besonders, sondern auch das “Line-up” der Teilnehmer. Es hatten sich mehr als 20 Teilnehmer für das Dojo auf der Xing-Gruppe angemeldet – und es gab „on top“ noch ein gutes Dutzend Interessierter, die nach einem ganzen Tag geballter C#-Wissensvermittlung noch „Power“ genug hatten, beim Dojo dabei zu sein.

19:00 Uhr – es geht los, das Dojo wurde von mir mit einleitenden Worten eröffnet. Ich habe für die Neulinge in der Runde noch kurz die „Rahmenbedingungen“ abgesteckt: Lösen eines Code Kata per TDD, aktiv und gemeinsam. Alle coden, einer tippt (wir waren wieder im Prepari-Modus). Es gibt kein Falsch und kein Richtig, es gibt keine dummen Fragen und keine dummen Antworten. So einfach ist das.

Ich habe dann auf Grund der großen Teilnehmerzahl den Vorschlag der Gruppenbildung unterbreitet und zur Abstimmung vorgelegt. Wir haben uns gemeinsam für eine große Gruppe statt zwei kleiner Gruppen entschieden.

Danach ging es auch schon zur Vorstellung der Kata’s: Ich hatte mit Pete gemeinsam eine Vorschlagsliste erarbeitet: KataTennis, KataRomanCalculator und KataBankOCR. Ein seltenes, aber schönes Erlebnis waren diesmal die Alternativ-Vorschläge der Teilnehmer, darunter Sudoku oder FizzBuzz. Nach einer kurzen Abstimmungsrunde war es soweit: KataBankOCR wurde gewählt.

Wie wird morgen das Wetter?

Die übliche „Anforderungsrunde“ wurde damit eingeleutet. Ich habe das Kata näher vorgestellt und nach offenen Fragen abgefragt. In dieser Phase haben wir uns auf besondere Dinge wie z.B. Zeilenhöhe und Ziffernabstand geeinigt und die Anforderungen klarer umrissen. Nach ca. 15 Minuten war es dann soweit, auf meine Frage „Noch offene Fragen?“ gab es nur noch die Gegenfrage „Wie wird morgen das Wetter?“. Damit war die Anforderungsrunde abgeschlossen.

Es konnte also losgehen. Aber wie legt man jetzt denn los? Das war die nächste Frage. Pete hatte Visual Studio schon offen, das Projekt war angelegt, das Test-Framework eingebunden. Die Tools waren bereit. Doch waren es die Teilnehmer auch? Eine geteilte Stimmung machte sich breit. Während die einen am Grübeln über den ersten Test waren, waren die anderen mit der Vorgehensweise nicht einverstanden und wollten erst mal „generell eine Architektur herausarbeiten“. Auch hier half die Abstimmung weiter. Mit äußerst knapper Mehrheit ließ man sich auf die Erarbeitung des ersten Tests ein, ohne eine „Lösungsanalyse“ im klassischen Sinne gemacht zu haben.

Test schreiben heisst nachdenken

Das herausarbeiten des ersten Tests war garnicht so einfach wie es viele vielleicht vermutet hatten. Es gab Diskussionen über die Datenstruktur (string vs. List<string> vs. IEnumerable<string>) und wir taten uns schwer, einen richtigen Namen für unseren Test zu finden. Doch nach knapp 10 Min. hatten wir endlich den ersten Test, der das „Digit 0“ testet, rot. Und schon ging es an die Implementierung: „return 0;“! Ach, wie schön, das erste Erfolgserlebnis ist da!

Das motiviert schon gleich zum nächsten Test, der Erkennung von „Digit 1“. Schnell wurde der Test geschrieben und dann ging es wieder an die Implementierung. Diesmal war es natürlich schon schwerer, denn schließlich musste jetzt erkannt werden. Aber jetzt fingen auch die Neulinge an, aktiv an der Lösung zu arbeiten und brachten Vorschläge und Kommandos in die Runde ein. Es dauerte nicht lange, und man hatte mit einem einfachen String-Vergleich die Implementierung fertig.

Red-Green-Maybe<Refactor> ?

Doch irgendwie war man nicht ganz mit dem Ergebnis zufrieden, denn der Ruf nach Refactoring wurde lauter. Golo mahnte an: „Es heisst Red-Green-Refactor und nicht Red-Green-Vielleicht-Refactor“. Sein Standpunkt: wenn man Refactoring nicht „im Kleinen“ und von Anfang an betreiben würde, dann würde der Aufschub noch mehr Probleme schaffen.

Andere wiederum sahen das nicht „so steif“, sondern beriefen sich auf den berühmten „Smell“. D.h. wenn eine Implementierung offensichtlich „Bereinigung verlangt“ um die Funktionalität weiter vorantreiben zu können, dann werde refaktorisiert. Auch hier die Abstimmung. Auch hier ein ganz knappes Ergebnis für den Aufschub des Refactorings.

Gibt es ein ABS beim TDD ?

Also ging es weiter zum nächsten Test, der im Übrigen wieder von einem Neuling angeregt wurde. Was tun mit „Leerstellen“? Also wie kann man überprüfen, dass *keine* Ziffer an einer Stelle des „virtuellen Displays“ dargestellt wird. Raunen machte sich breit beim erarbeiten des Tests. Einige Stimmen waren für „einfach 0 zurückliefern“ („Vollgas“ weiter machen), andere wiederum wollten den Test nicht machen stellten den derzeitigen Lösungsansatz in Frage („Vollbremsung“).

Eine kleine Randgruppe wollte den Test durchführen, aber den Target (also die zu testende Methode) wechseln ( „Ausweichen“). An dieser Stelle gingen die Meinungen und Ansichten wieder auseinander. Eine etwas heftigere Diskussion wurde entfacht, doch leider konnte Sie nicht weitergeführt werden, denn unsere „Dojo-Zeit“, die wir uns als Timebox festgelegt hatten, war abgelaufen. Doch die Frage war im Raum und verlangt natürlich auch nach einer Antwort: Gibt es ein “ABS” (Anti-Blockier-System) beim TDD?

Die Moral von der Geschichte…

Die abschließende Retrospektive war wie immer sehr aufschlußreich und gab einen bunten Mix an Feedback zurück. Unter anderem wurde die TDD Vorgehensweise gelobt und kritisiert, die Gruppengröße bemängelt, das Ergebnis sowohl als „sehr gut“ und „sehr schlecht“ attributisiert, die „Planlosigkeit“ kritisch betrachtet, das vernachlässigte Refactoring angemahnt. Alles in allem jedoch, war es für jeden erkenntnisreich, denke ich.

Doch ganz besonders war dieses Dojo eine Lehre für mich. Ich konnte in diesem Dojo wieder vieles Lernen. Ich lernte z.B. dass „Neulinge“ sehr wertvoll für eine Gemeinschaft sein können, weil sie unvoreingenommen, ja man mag fast sogar sagen „positiv naiv“ auf Dinge blicken. Das ist nicht nur frisch, sondern auch konstruktiv. Dazu gab es noch eine Reihe weiterer Erkenntnisse, die mich zum Nachdenken gebracht haben. Ich will hier auch auf diese Erkenntnisse und die Konsequenzen daraus eingehen.

Die einfachste Lösung gewinnt

Da wäre zum Beispiel die immer wieder aufkeimende Diskussion in Coding Dojo’s, ob man nun nach der Anforderungsanalyse über einen generellen Lösungsweg nachdenken sollte (Knobler) oder „einfach“ sich auf den Code stürzen sollte (Coder). Ich habe zu diesem Thema einen besonderen persönlichen Standpunkt, den ich noch in einem gesonderten Artikel im Detail niederschreiben werde – hier würde solch ein Exkurs den Rahmen deutlich sprengen.

Fakt ist, dass wenn eine solche Diskussion im Dojo auftaucht, diese Diskussion auch geführt werden muss. Hier zählt der Erfahrungsaustausch, hier zählt der Lernwille, der das führen der Diskussion bedingend macht. Generell ist es natürlich so, dass beim Coding Dojo „Test-First“ entwickelt wird. Ob das per TDD, BDD oder ATDD geschieht, sei erstmal dahingestellt. „Test-First“ ist im Sinne der agilen Methoden, besonders aber im engeren Sinne XP wörtlich zu verstehen. Um den TDD-Neulingen oder TDD-Zweiflern das etwas näher zu bringen, zitiere ich Uncle Bob:

“The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function.”

Also ganz klar: Nein, es soll beim Coding Dojo keine „gesamte Lösung“ erarbeitet werden, bevor man das programmieren anfängt. Sondern: Ja, beim Coding Dojo wird nach klarer Anforderungsanalyse sofort der erste Test in Angriff genommen. Dazu muss man natürlich auch nachdenken. Keiner wird daran gehindert, sich für diesen Test (und manchmal sogar den nächsten) eine Strategie zu überlegen. Es ist eher so, dass man sich gegenseitig zu einer klaren Testdefinition motiviert.

Chief Operating Development Engineer Lead Executive Senior Sensei

Darüber hinaus gab es in diesem (sowie auch in den vorangegangenen) Dojo vermehrt Stimmen, die eine “Führungsrolle”, eine “bewertende und entscheidende Instanz“, einen „Chefentwickler“ oder ähnliches eingefordert haben. Auch hierzu gibt es für das Coding Dojo eine klare Vorgabe. So gibt es beim Coding Dojo z.B. verschiedene Formate, wie das Prepari oder Randori oder andere. Ich möchte hier nur kurz anmerken, dass ich in einem separaten Artikel auch auf diese verschiedenen Verfahren und Modi in Dojo’s eingehen werde. Für’s erste soll es reichen, dass es verschiedene Arten gibt.

Je nach Format gibt es auch verschiedene Rollen. In den Münchener Dojo’s haben wir oft – wie auch dieses Mal – das einfachste Format gewählt: Prepari. In diesem Format gibt es 3 Rollen: den „Hacker“ (von mir öfter flapsig als „CodeMonkey“ bezeichnet), den „Operator“ (der Organisator und Moderator, manchmal etwas irreführend auch „Leiter“ des Dojo’s) und natürlich die „Contributor“, die aktiven Teilnehmer des Dojo’s.

Im Prepari-Format (sowie auch in allen anderen) gibt es keine CODELESS-Rolle. Es gibt also beim Coding-Dojo niemanden, der die Rolle des „CODELESS“ einnimmt. Das Gegenteil ist der Fall: es wird explizit beim Coding Dojo eine CODELESS-Rolle vermieden. Und für diejenigen, die die Rolle nicht kennen:

Definition:
CODELESS = “Chief Operating Development Engineer Lead Executive Senior Sensei”

Im Coding-Dojo die “Anti-Rolle” der führenden, leitenden, entscheidenen Person(en). Kann von einer oder mehreren Personen erfüllt werden. Sobald die Gefahr für so eine Rolleneinnahme besteht (ein „Smell“ sozusagen), darf (und soll) jeder zur Vermeidung der Rolle folgenden Satz sagen:

„We don’t want (to) CODELESS, we want (to) code more !“

Sobald also die Rolle eingenommen wird, sind alle anderen dazu verpflichtet, die Rolle der oder den Personen wieder zu entziehen. Im Coding Dojo gilt das Prinzip der Gleichstellung. Alle Meinungen haben per se den gleichen Wert. Die Auswertung der Meinungen geschieht gemeinsam. Entscheidungen werden gemeinsam getroffen. Diskussionen werden gemeinsam gestartet und gemeinsam beendet. Keiner darf sich besser stellen, keiner soll sich schlechter stellen.

Rei

Jeder ist in dieser „Coding Dojo“-Gemeinschaft nun gleichgestellt – ein schönes Recht. Doch gibt es auch Pflichten für die Teilnehmer? Oft werde ich nach „Voraussetzungen“ für die Teilnahme des Dojo’s gefragt. Ich antwortete auf diese Frage meist mit folgenden Sätzen:

„Nicht viel. Interesse, Wissbegierde, Neugier für .NET und moderne, professionelle Software-Entwicklungs-Methoden. Aktive Teilnahme & Beitrag zur Lösung der gestellten Programmieraufgabe.“

Das hat den meisten Fragestellern ausgereicht, um sich ein Bild machen zu können. Aber dennoch haben wir immer wieder Probleme mit dem Selbstverständnis der Teilnahme am Dojo. Ich denke, dass es dafür mehrere Gründe gibt. Manche denken, ein Dojo sei so „informell“, dass es keine Regeln gäbe. Andere wiederum vergleichen es mit anderen Formaten, wie z.B. einem Workshop, Vortrag oder Fishbowl. Um diesen „Interpretationen“ etwas mehr Linie und Substanz zu geben, stelle ich die Teilnahme-Voraussetzungen auf eine etwas formalere Ebene. Die folgenden Regeln sind Grundregeln (Rei bzw. Reishiki), die für die Teilnahme an einem Coding Dojo bedingend sind:

§1 – Aktivität
Der ehrliche Wille, einen aktiven, fokussierten Beitrag zum „Lernen & Lehren“ zu leisten.

Es gibt beim Coding Dojo niemanden, der sich nicht einbringen darf. Das hört sich ein wenig nach „zur Aktivität gezwungen sein“ an. Und ganz offen: Ja, so ist es auch. Mitdenken, Mitwirken, Mitreden – das ist eine Pflicht für den Teilnehmer im Coding Dojo. Dennoch gibt es natürlich „Interessierte“, die sich „das Mal anschauen“ möchten. Das war bisher immer möglich und das wird es auch weiterhin. Aber: es darf nicht zur Gewohnheit werden. Deswegen folgende Regelzusätze:

• Falls jemand „Spectator“ sein möchte, muss er es bei Dojo-Beginn allen mitteilen. Zuschauer haben keine Pflichten, aber auch keine Rechte. Im Gegensatz zu den Teilnehmern dürfen sie keinen Beitrag leisten, sondern nur „beobachten“. Sie werden auch vom Abstimmungs- und Feedback-Recht befreit.
• Eine Person darf nur einige Male – sagen wir mal bis zu dreimal – „Spectator“ sein. Spätestens beim 4. Dojo-Besuch muss er aktiv werden. Sollte er es weiterhin nicht wollen, muss er alle Teilnehmer um Beobachtungserlaubnis bitten. Bei Erlaubnis bleibt er „Spectator“, bei Verweigerung muss er das Dojo verlassen.

§2 – Respekt
Der ehrliche Wille, sein Gegenüber anzunehmen wie er ist.

Sie oder ihn, seine Haltung, seine Meinung und sein Wissen zu würdigen um damit das „Lernen & Lehren“ zu stärken. Einher geht dabei auch Höflichkeit bei Kommunikation und Kollaboration. Adequate Wortwahl, konstruktive Beiträge und kultivierte Gemeinsamkeit sind die Pflicht jedes Dojo-Teilnehmers. Um dies zu Gewährleisten, gelten folgende Regelzusätze:

• Jeder einzelne Teilnehmer ist verpflichtet, andere auf mögliche Respektsverletzungen hinzuweisen. Er kann sich jederzeit dem „Operator“ zuwenden. Es obliegt dann der gesamten Dojo-Gruppe, sich gemeinsam zu besinnen. Das kann durch auflockernde Übungen, eine kurze Pause oder andere Besinnungstechniken geschehen.
• Bei einer offensichtlichen Respektsverletzung, ob willentlich oder nicht, wird das Dojo sofort abgebrochen. Es gibt keine Retrospektive, keine Diskussion. Die Beteiligten an der Respektsverletzung werden durch die anderen Teilnehmer oder den Operator auf Ihr Fehlverhalten höflich und respektvoll hingewiesen und dazu aufgefordert, Ihr Verhalten zu reflektieren und eine Lösung zu erarbeiten. Das Dojo wird nach Abbruch nicht wieder begonnen. Alle Teilnehmer verlassen das Dojo.

§3 – Optimismus
Der ehrliche Wille, mit Freude und positiver Einstellung zum „Lernen & Lehren“ beizutragen.

Die positive, offene Grundhaltung eines jeden Teilnehmers ist bedingend für eine gute Unterstützung des „Lernen & Lehren“. So ist es für jeden Dojo-Teilnehmer eine Freude, dabei zu sein und die anderen bei sich zu haben. Sollte „mal einer einen schlechten Tag haben“ ist es nicht so schlimm. Aber man sollte auch im Sinne des Dojo’s offen zu sich selbst sein. Ist die Laune im Keller, so macht es für einen selbst nicht viel Sinn – und damit für die Gemeinschaft auch nicht. Niemand im Dojo nimmt es Übel, wenn man mal „keine Lust“ hat, dabei zu sein. Um die positive Einstellung im Dojo zu unterstützen, gelten folgende Regelzusätze:

• Ein Lächeln ist der Botschafter der Optimismus. Jeder Teilnehmer ist dazu aufgefordert, seine positive Grundhaltung auszudrücken. Manche Lächeln, manche machen kleine Witze, manche suchen Nähe und das Zwischengespräch. Trotz aller Aktivität und Fokus, die man beim Dojo hat (siehe „Regel 1“), ist Optimismus eine Voraussetzung, der man auch als Teilnehmer nachkommen soll.
• Stellt ein Teilnehmer für sich fest, nicht mehr positiv Beitragen zu können, sollte er aus freien Zügen – auch ohne Angaben jedweglicher Gründe, wenn nötig – das Dojo verlassen dürfen. Denken andere Teilnehmer, dass jemand in der Gemeinschaft keine positive Grundhaltung mitbringt, sind sie dazu aufgefordert, demjenigen mit ermutigenden und positiven Worten ihre Wahrnehmung mitzuteilen. Das kann persönlich in der Pause geschehen, oder aber indirekt durch Beteiligung des Operators.

§4 – Zwanglos
Der ehrliche Wille, freiwillig, ohne Druck, Wettbewerb oder Leistungsziel das „Lernen & Lehren“ zu verfolgen.

Diese Regel ist besonders wichtig, denn sie nimmt jeglichen Druck von allen. Keiner ist dazu verpflichtet, eine Sache „richtig“ oder „fertig“ zu machen. Niemand zwingt die Teilnehmer, sich an eine bestimmte Technologie, Meinung oder Vorgehensweise zu richten. Wenn überhaupt, dann sind es die Teilnehmer, die selbstbestimmt, freiwillig und gemeinsam sich selbst Verbindlichkeiten zusprechen. Um dies im adequaten Rahmen zu gewährleisten, gelten folgende Regelzusätze:

• Es gibt keine Leistungsziele und keine Leistungsmessung. Weder von Einzelnen, noch von der Gemeinschaft. Ausschließlich Bewertung im Sinne des Feedbacks und des Meinungsaustausches sind für die Teilnehmer möglich. Teilnehmer mit Leistungsanspruch sind von den anderen Teilnehmern von diesem Anspruch freizustellen.
• Selbstbestimmt heisst nicht selbstautoritär. Trotz der Zwanglosigkeit gelten für jeden Teilnehmer die Grundsatzregeln, die Grundsatzvorgehensweise sowie die Regel des kollektiven Entscheids. So ist es verpflichtend und selbstverständlich, wenn ein Teilnehmer einer anderen Auffasung ist die Mehrheit der Teilnehmer, dass dieser sich der kollektiven Meinung beugt bzw. nach dem gemeinsamen Entschluß zu richten hat. Ist die eigenee Meinung mit der gemeinschaftlichen Meinung fundamental nicht vereinbar, so bleibt es jedem frei, das Dojo zu verlassen.

Diese oben genannten vier Grundregeln sind für mich essentielle Voraussetzungen für die Teilnahme an einem Dojo. Oftmals ist es garnicht so schwer, diesen Bedingungen gerecht zu werden, doch wir durften in der Vergangenheit auch erleben, wie sich der eine oder andere Teilnehmer mit diesen Werten schwer tat.

Make it simple

Es gibt noch vieles mehr, das ich über das Coding Dojo, die Regeln und Werte des Coding Dojo und auch die Dynamik und Magie des Coding Dojo schreiben könnte, und ich werde es wohl nach und nach auch tun. Doch bei all diesen Hintergrundinformationen und den eben etwas formaler beschriebenen Regeln gilt es den Grundsatz der Einfachheit zu wahren. Solange es nicht wirklich notwendig ist, wird es keinen weiteren „Ballast“ oder „Verkomplizierung“ der Sache geben. Weder mit weiteren Formalismen oder irgendwelchen Hierarchien, unnötigen Gedankenwindungen oder theoretischen Methodenspielchen. Das gilt für Software, das gilt für TDD, das gilt für gemeinschaftliches Arbeiten, also gilt es auch für das Coding Dojo. Frei nach Albert Einstein:

„Make it simple, but not simpler“.

Für die Interessierten sei noch das Original-Zitat erwähnt:
“It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.”

Ich, der Ilker

Nach diesem regelrechten Aufsatz an Regeln und Bestimmungen gibt es einen weiteren wichtigen Punkt, der unbedingt erwähnt werden muss. Alle die o.g. Regeln beziehen sich auf meinen Eindruck, meine Meinung und meine Anschauung. Es ist also „Ilker’s Coding Dojo“, welches sich diesen Rechten und Pflichten unterwirft.

Warum erwähne ich das? Ganz einfach, weil jeder auf dieser Welt das gute Recht hat, Coding Dojo’s zu machen. Jeder hat so gar das gute Recht, Coding Dojo’s so zu machen, wie er sich das vorstellt. Das ist auch gut so, denn Diversität ist ein wichtiger Faktor für Fortschritt. Aber es birgt auch Potenzial für Missverständnis und Verkennung. Der eine macht Coding Dojo’s mit dem Streben nach Kampf und Perfektion. Ein weiterer macht Coding Dojo’s um neue Sprachen zu erleben und zu erforschen. Ein anderer macht Coding Dojo’s, um anderen zu zeigen, wie man was macht und die Richtung vorzugeben. Aber ich mache Coding Dojo’s nicht (nur) deswegen. Meine Motivation ist das Motto, welches ich immer wieder versuche zu transportieren: „Lerne & Lehre“.

Bei „meinem“ Coding Dojo steht der lockere Erfahrungsaustausch im Vordergrund, gebunden durch eine konkrete, kleine, realisierbare Aufgabe. Doch es geht nicht um einen netten Plausch oder Brainstorming, sondern um Lernen und Lehren. Wer nicht genau weiß, wie herausfordernd und anspruchsvoll diese beiden Disziplinen sind, dem rate ich, sich damit ein wenig auseinanderzusetzen.

Weiterhin mache ich Coding Dojo’s aus freien Stücken, weil es mir Spaß macht und ich weiter Spaß damit haben möchte. Ich mache es, weil ich eine tiefe, feste Überzeugung habe, dass jeder von anderen lernen kann und jeder den anderen lehren kann.

Ich respektiere diejenigen, die Coding Dojo’s „anders“ sehen, die etwas anderes darunter verstehen oder es anders kennen. Wie gesagt, jedem steht es frei, selbst Coding Dojo’s zu machen und sie so zu machen, wie er es für richtig hält. Ich habe die „Coding Dojo’s“ nicht erfunden, ich bin nicht der Coding-Dojo-Oberlehrer, ich bin kein Kata-Mönch und auch kein Dojo-Messias. Ich bin der Ilker, der Coding Dojo’s macht. Punkt.

Latifa-Dojo

So, und als genau dieser Ilker, der diese Coding Dojo-Bewegung in die .NET-Welt getragen hat, als der Ilker, der Erfahrung mit Coding Dojo’s verschiedener Formate hat, als der Ilker, der das „Lernen & Lehren“ mit Code Kata’s und TDD/BDD & Design Patterns sowie Best Practices in den Vordergrund stellt, als genau dieser Ilker stelle ich die oben genannten Regeln für die Art der Coding Dojo’s auf, die ich mir vorstelle.

Diejenigen, die sich für Coding Dojo’s interessieren, schon mal bei dem einen oder anderen dabei waren, sogar den Weg mit mir „mitgegangen“ sind oder einfach mal gerne dabei sein möchten – ja euch alle – bitte ich um Vertrauen. Bitte, vertraut mir und geht den Weg, den ich hier beschreibe, wenn ihr Coding Dojo’s macht und mitmacht. Verlangt Aktivität, Respekt, Optimismus und Zwanglosigkeit. Verfolgt das Ziel des Lernen & Lehrens. Fordert genau diese Art von Coding Dojo’s, denn diese Coding Dojo’s sind es, die uns alle weiter bringen. Fordert von Coding Dojo’s diese Werte und diese Ziele – von Veranstaltern, von Operatoren, von Teilnehmern, von euch selbst. Ich werde es tun.

Im Sinnbild der asiatischen Kampfkünste, welches unschwer erkennbar auch mit dem Coding Dojo transportiert wird, möchte ich hiermit das oben geschilderte „Format“ als einen „Dojo-Stil“ etablieren. Es widerspricht natürlich dem gemeinschaftlichen Denken, nun von „Ilker’s Dojo-Stil“ zu sprechen oder es so zu kommunizieren. Personifizierung ist nicht zielführend. Wie gesagt, keiner ist besser gestellt als die anderen, keiner ist schlechter gestellt als die anderen.

Dennoch ist es ein stückweit meine Handschrift und meine Vorstellung eines Coding Dojo’s. Deswegen möchte ich bei der Schaffung dieses „Dojo-Stils“ noch eine kleine persönliche Note einbringen. Ich mache das jetzt mal einfach und gebe „meinem“ Dojo-Stil einen Namen: Latifa.

Latifa kommt vom arabischen latif, welches frei übersetzt “höflich, freundlich, sanft” bedeutet. Ich habe es gewählt, weil es im türkischen (latife) für „zuvorkommend, manierlich“ und manchmal sogar „gentlemen-like“ angewendet wird. Es spiegelt für mich die Grundvoraussetzung für gemeinsames Tun & Wirken wider, die auch für ein erfolgreiches Lernen & Lehren notwendig ist.

Es gibt so vieles, welches wir von anderen, unseren Ahnen und anderen Kulturen lernen können. Doch eine Sache ist allen gemeinsam, der Respekt und die Höflichkeit. Wer sich intensiver mit dieser Werte-Einstellung auseinandersetzen möchte, dem Rate ich das Studium (das meine ich wörtlich, also „studere“) des Shoto-Niju-Kun, der 20 Verhaltensregeln von Funakoshi für das Karate-Do.

Feedback im Mittelpunkt

Ein zentrales Element des fortschreitens und verbesserns ist das Feedback. Nach geleisteter Arbeit ist Feedback wichtig, um daraus Erkenntnisse zu gewinnen und damit sein Handeln zu adaptieren. Das ist eigentlich ein Naturgesetz.

Ich möchte diesem Naturgesetz auch hier folgen und möchte abschließend um euer Feedback bitten. Bringt euch ein, macht mit und gestaltet mit. Schreibt mir, was ihr denkt und was ihr machen würdet. Ich freue mich über jedes Feedback.

Doch bei all dem Wirken & Tun rund um das Coding Dojo stelle ich klar und und kommuniziere es mit deutlichen Worten: Ich werde weiter Coding Dojo’s machen, genauer gesagt Coding-Dojo’s im Latifa-Stil. Ich werde das Lernen & Lehren verfolgen und stärken. Das werde ich mit Freude und Spass machen, denn nur so ist es wertbringend und nachhaltig. Für den Latifa-Stil gelten die Voraussetzungen der Gleichheit, der Aktivität, des Respekts, des Optimismus und der Zwanglosigkeit. Die Modi im Latifa-Stil sind frei wählbar, solange sie keinen Kampfcharakter haben. Im Dojo wird gemeinsam an dem Kata gearbeitet und geübt. Es steht die Übung mit dem Code im Vordergrund, deswegen heisst es Coding Dojo.

Wege sind zum gehen da

Es soll klar sein: Für alle, die sich mit diesem, dem Latifa-Stil des Coding Dojo auseinandersetzen möchten und diesen Stil in den Coding Dojo’s erleben möchten, gibt es die wunderbare Möglichkeit sich in der Xing-Gruppe zu melden oder auf die Facebook-Seite zu schauen, um so auch die nächsten Event-Termine mitzubekommen. Ihr seid herzlich eingeladen, mit uns gemeinsam zu lernen & zu lehren.

Weiterhin soll klar sein: Für alle, die sich mit dem Latifa-Stil nicht anfreunden können oder unter Coding Dojo’s etwas anderes verstehen, kann ich folgendes entgegenbringen: Ich werde euch nicht in einem Latifa-Dojo akzeptieren. Ich werde euch nicht für die Werte des Latifa-Dojo ermutigen. Ich werde euch nicht vom Latifa-Dojo überzeugen. Ihr müsst das alles selbst tun. Ihr könnt jederzeit zu Coding Dojo’s im Latifa-Stil kommen, solange Ihr euch an die Regeln und Werte des Dojo’s richtet.

Und wenn sich im Ergebnis keiner für den Latifa-Stil interessiert, dann ist das gut, denn dann habe ich immer noch meine Überzeugung. Und wenn sich im Ergebnis einige für den Latifa-Stil interessieren, dann ist das gut, denn dann habe ich immer noch meine Überzeugung. Und wenn sich im Ergebnis alle für den Latifa-Stil interessieren, dann ist das gut, denn dann habe ich immer noch meine Überzeugung.

Gleich vorneweg: Es war super! Nein, noch mehr, es war richtig super! Eine mehr als gelungene Veranstaltung. In diesem Wochenende habe ich vieles gelernt und mitgenommen. Die Eindrücke dieser wahnsinnigen .NET-Veranstaltung wirken bei mir noch so immens, dass ich sie hier in einem Blog einfach niederschreiben muss.

Mittendrin statt nur dabei!

Samstag, 9:45 Uhr, ich gehe durch eine unscheinbare Tür, es gibt nur ein kleines Schild „.NET Openspace Süd 2010, 4. OG“. Ich laufe die Treppen hoch und werde von einem lächelnden Gesicht überrascht: „Na, ganz schön sportlich!“ rief die freundliche Check-In-Lady (neudeutsch für Empfangsdame ?!? ;)) mir entgegen. Wohl eher aus Höflichkeit, schließlich tat ich mir nach geleisteter Stufenarbeit merklich schwerer als sonst, das mir entgegengebrachte Lächeln mit einem Zurücklächeln zu erwidern.

Nach dem obligatorischen Check-In mit Teilnehmerkarte und Event-Infos finde ich mich mittendrin in der Sessionplanung für den ersten Tag wieder. „Wahnsinn“ dachte ich mir, endlich sehe ich viele, die ich nur per Twitter, Blog oder anderweitig online kenne. Gleichzeitig freute ich mich, wieder in Gesichter zu blicken, die ich schon kannte. Und ich war gespannt, welche neuen Bekanntschaften ich mit dieser „Erfahrungsaustauschplattform“ Open Space machen würde. Doch zunächst galt es, die Sessionplanung konzentriert umzusetzen. Auf geht’s!

WTF is a Monad?

Die Antwort auf diese Frage hat mir auf anschauliche Art und Weise Steffen gegeben. Er folgte der Aufforderung von Björn, uns allen mal dieses komische „Monad-Ding“ in verständlicher Form widerzugeben. Ich ertappte mich selbst dabei mich nicht daran erinnern zu können, wie lange es her ist, so gespannt und magnetisiert einem Thema und seinem Vortragenden zuzuhören.

Er erklärte unter Anderem, dass die Uhr ein Monoid sei und es nur 3 essentielle Kriterien für das in sich geschlossene System eines Monaden gibt. Das neutrale Element, die „SelectMany“ und „Id“ Methoden (also Bind & Return) [Anmerkung: Das ist mit großer Wahrscheinlichkeit mathematisch total falsch und wahrscheinlich auch nicht richtig - aber so habe ich es verstanden :-/ - Korrektur willkommen.]. Es ging weiter mit der Vorstellung der Population in der Monaden-Welt: Identity, Maybe, Continuation, State.

Ich habe es sicherlich noch nicht richtig begriffen und bin selbst erst am Anfang, die funktionale Programmierung wieder in meine tägliche Programmier-Praxis einzuführen. Doch diese Session war für mich wie ein Paukenschlag zum Auftakt! Super.

3D in your Pocket

„Hmm, das ist schwer zu toppen“, dachte ich mir, noch gedanklich verworren in Monaden, als ich mich plötzlich in der 2. Session über XNA & Windows Phone 7 von Tom wieder langsam aus der Monadenwelt lösen konnte. Doch meine Skepsis erwies sich als unberechtigt. Tom zeigte uns, das XNA keine Abkürzung für Spieleentwicklung ist, sondern eine Abkürzung ist für effektive & professionelle Spieleentwicklung – mit einer für mein Empfinden niedrigen Lernkurve.

Tom ist ein Verfechter von Fakten, also waren auch keine trockenen Slides angesagt – statt dessen gab es Visual Studio, Source Code und den Windows Phone 7 Emulator zu sehen. Ich durfte lernen, dass es gar nicht so schwer ist, Windows Phose 7 „anzuprogrammieren“ und sich auch kein Hexenwerk hinter „Worlds“, „Matrices“, „Meshes“ und „Shadern“ verbirgt. Macht Laune auf mehr.

Design Drivers

Und schon ging es weiter mit den Erkenntnissen in der von Sergey angetriebenen Session über “TDD vs. BDD vs. ATDD”. Es war unerwarteterweise keine trockene Gegenüberstellung von „methodischen Religiösitäten“. Ganz im Gegenteil. Die Session war wohl eine der konstruktivsten Diskussionen über „Erwartungsgetriebene Softwareentwicklung“, bei denen ich dabei sein durfte.

Der Erfahrungsaustausch fand auf breiter Ebene statt, fast jeder konnte irgendwie dazu beitragen. Highlights waren sicherlich die Vorstellung von Fitnesse als Werkzeug für ATDD sowie die anschauliche Erklärung der Agile Testing-Quadranten von Sergey.

Im Übrigen hatte wohl Sergey noch mehr „feine Info’s“ mitgebracht, denn er war es auch, der die „RX – Reactive Extensions Hands On“-Session kräftig mitgestaltete. Ach, ich könnte womöglich noch stundenlang über die weiteren, hochinteressanten Sessions auf diesem .NET Open Space schreiben.

Know How Rollercoaster

Zum Beispiel über die unglaublich erkenntnisreiche Session über „TDD/BDD Do’s and Dont‘s“ – das war geballtes Know-How über testgetriebene Entwicklung. Oder die Session über „verteilte Architekturen“ sowie die Session über „Skalierung & Caching im Web“, die anschaulich die Best Practices dieser Themen an mich, den Teilnehmer transportieren konnten.

Das „Daily Life“ wurde wertwoll angereichert durch die Sessions „Smart Tools for Smart People (Part I + II)“ von Daniel. Das meistern spielerischer Herausforderungen wurde in der AntMe!-Session von Tom gezeigt, einen Kickstart von 0 auf 100 für ASP.NET MVC2 lieferte der Albert. Die weise Erkenntnis der vielen Gemeinsamkeiten und wenigen Unterschiede von xUnit.BDDExtensions zu MSpec zu NaturalSpec wurde in der „United BDD“-Session deutlich. Unüberhörbar waren auch die Berichte von einer spannenden Session über die Erfahrungen mit und um DDD herum von Gregor.

Ach ja, es gab ja auch noch ein Coding Dojo. Ich als „Session-Host“ möchte nicht viele Worte darüber verlieren. Ich möchte viel mehr, dass jeder, der dabei war, seinen Eindruck mitnimmt und seine Meinung dazu bildet. Ich kann nur sagen: mir hat das Dojo mit so vielen interessierten und erfahrenen Entwicklern sehr viel Spass gemacht und ich konnte wieder einiges dazulernen.

Environment.Cool();

Doch dieses gesamte „Excitement“, der Erfahrungsaustausch, die Bekanntschaften, die wunderbar leichten Unterhaltungen am Mittagstisch, die Diskussionen über Vergangenheit, Gegenwart und Zukunft der Software-Entwicklung am gemütlichen Abend, die Betrachtungen über den eigenen Tellerrand hinaus – all das wäre nicht möglich gewesen, ohne die Motivation & Organisation zum .NET Open Space Süd in Karlsruhe. Vielen Dank an die DNUG Karlsruhe, Alex, Ralf, Frank, Aydin und alle, die dabei waren! Ich bin beim nächsten Mal sicher wieder dabei!

Doch eine wichtige Frage bleibt nach dem .NET Open Space Süd immer noch offen: Planen Steffen, Björn, Sergey, Alexander eine Verschwörung? Bildet sich ein verschworene Monaden-Mafia? Welche Rolle spielt dabei „Jean Closure“ – ist er der neue Pate der testgetriebenen Untergrundgeschäfte? Vielleicht hat Christian auch etwas damit zu tun?

Maybe Some<IsTrue>, Maybe None<IsTrue> … to be Continuation-Monad! ;-)

Ralf wird im Mai-Dojo mit uns den Schwerpunkt Architektur & Design trainieren. Einerseits ist das untypisch für ein .NET Coding Dojo, denn schließlich ist im Coding Dojo das „Coding“ nicht nur im Titel verankert, sondern auch das A und O eines jeden Dojo’s. Andererseits sind Anwendungs-Architektur und –Design wichtige Themen, denen besonders im Kontext der testgetriebenen Entwicklung Beachtung bemessen werden sollte. Umso besser und spannender ist es bei diesem Dojo, wie wir alle gemeinsam von der Idee, der Anforderung über die Architektur und bis zum Test-Driven-Design und der Implementierung gelangen werden.

Ein besonderes Thema verlangt auch eine besondere Location. Dank der tatkräftigen Unterstützung von Microsoft und dem Evangelisten mit dem Hut haben wir einen wirklich exklusiven Standort für dieses Dojo gefunden: Das Microsoft-Technology-Center in Unterschleißheim öffnet der .NET-Coding-Dojo-Crew die Pforten für diesen „Extra-Workout“. Danke!

Kühl sag‘ ich, kühl!

Wo wir gerade dabei sind: Die Idee und das Konzept des .NET Coding Dojo’s ist erfreulicherweise schon in einige Städte Deutschlands vorgedrungen. Dennoch – oder gerade deswegen – kommt es immer öfter vor, dass ich angesprochen werde und man mich frägt wie das denn im Coding Dojo so abläuft. Die ALT.NET-Crew in Berlin hat auf ihren Coding-Dojo-Seiten eine ziemlich gute Beschreibung, doch jetzt gibt es eine noch anschaulichere Alternative: MSDN TV war bei einem Dojo in München zu Gast und hat ein paar interessante Impressionen mitgenommen!

Eine Überasschung, aber für mich eines der Highlights in dieser Folge ist die Nahaufnahme von zwei „.NET Coding Dojo Core‘s“, sozusagen dem ideelen Fundament der Münchener Coding-Dojo-Crew, Philipp (aka. Fuip) und Olaf (aka. Nurph). Natürlich gibt es mittlerweile viele tragende Stammgäste und immer wieder neue Teilnehmer, die alle dazu beitragen, ihr eigenes Dojo zu dem zu machen was es ist und mit uns gemeinsam weiter zu trainieren, um so immer mehr und deutlicher an die professionelle Softwareentwicklung heranzukommen. Euch allen vielen Dank! Ach ja, Jan hat in der Folge auch mich zum Thema interviewt. Alles in Allem: Kühl… sehr kühl! :-)

.NET-Coding-Dojo-Chillout

Und weil in München gerade .NET Coding Dojo-Workout-Wochen sind geht es nach der Denk-Design-Diskussions-Orientierung im Mai im Juni wieder direkt an den Code! Das Münchener .NET Coding Dojo wird im Juni wieder ein Dojo erster Klasse veranstalten: Am 22. Juni sind wir zu Gast beim dotnetpro.powerday für C# Profis! Tagsüber wird von Golo und Albert (dem Online-Dojo-Virtuosen) C# Know-How kompakt und verständlich vermittelt, abends wird im .NET Coding Dojo gechillt eine Code-Kata mit dem neu gewonnenem Wissen gelöst. Chillen, Programmieren und Lernen geht nicht? Dann überzeuge Dich vom Gegenteil im .NET Coding Dojo bei dem C#-Profi-dotnetpro-powerday! Anmelden und gechillt coden!

Doch zunächst möchte ich auf die nächsten .NET Coding Dojo-Termine hinweisen, denn der Mai wird ein regelrechter Coding-Dojo-Workout-Monat werden!

Coding Dojo Berlin: Round II

Gong! Die zweite Trainingsrunde für das .NET Coding Dojo in Berlin steht kurz vor der Tür! Morgen schon, am 04.05. werden die Hauptstädtler so richtig die Bude rocken. Ich zitiere: „Strukturiertes Vorgehen, schnelle Finger und messerscharfe Logik sind unsere Waffen!“ So ist es richtig, und die Berliner Crew braucht nicht nur diese Eigenschaften, sondern auch weitere Unterstützung von .NET Entwicklern, TDD-Jüngern und CCD-Freunden. Gemeinsam das Code-Kata lösen, welches Mike schon durch das Sparring gepfercht hat. Sei dabei: Anmelden und Mitmachen!

Coding Dojo Online: Weinert’s 2. Sinfonie

Beim letzten Online Coding Dojo haben der Albert und die Online-Teilnehmer alles gegeben, um das Code Kata zu lösen. Es hat wieder einmal jede Codezeile gezählt. Die Kata und der Albert als virtuos auf der Tastatur fegender Kunst-Coder waren so fesselnd, dass nach dem Fall des ersten Online-Dojo-Vorhangs schon fest stand: Es muss eine 2. Sinfonie geben! Diese Woche ist es soweit. Am Donnerstag, den 06.05. findet das zweite .NET Online-Coding-Dojo statt. Es wird wieder eine Herausforderung erster Klasse werden, also nicht zögern und zaudern, sondern gleich anmelden und mit Albert und der geballten Know-How-Power der .NET-Online-Community das Code-Kata im Online-Coding-Dojo lösen! Auf geht’s!

Coding Dojo Wien: MVC FTW!*

Andreas, Adrian und die Wiener Dojo-Fraktion machen weiter an ihrem ASP.NET MVC Fundament und verknüpfen exemplarische Anwendungsentwicklung geschickt mit dem Coding Dojo und den darin gestellten Herausforderungen des Test-First, TDD & CCD. Das und vieles mehr qualifiziert die Wiener Gruppe zur Avangarde und Vorreitern der Coding Dojo-Szene in Österreich. Sei dabei, wenn es am 14.05. wieder heisst: MVC-Training im Coding Dojo – Anmelden! (*Update!)

Coding Dojo Hamburg: Die Premiere

Vorhang auf, meine Damen & Herren. Die .NET-Community in Hamburg präsentiert das erste .NET Coding Dojo in Hamburg, am 19.05.2010! Es wird eine ganz besondere Premiere, eine würdige Premiere der Coding Dojo Begeisterten in Hamburg werden, denn Hamburger sind bekannt für den hohen Anspruch, den sie an sich selbst stellen. Gleich das erste Coding Dojo wird ein Randori werden. .NET Entwickler im Norden Deutschlands, lasst euch gesagt sein, wer dieses Highlight verpasst, ist selber schuld! Auf geht’s zum .NET Coding Dojo Hamburg: Anmelden!

Coding Dojo München, Dojo Deluxe

Das Münchener .NET Coding Dojo macht weiter und trainiert weiter hart und unermüdlich. Modernste Software-Entwicklungs-Methoden, TDD im Hochleistungsbereich und CCD Eleganz treffen sich in München zum Coding Dojo der Extraklasse. In München geht es im Mai heiß her! Ralf Westphal wird mit der .NET Coding Dojo Gemeinde in München ein Dojo der Extraklasse abhalten und das D in Dojo dick und fett unterstreichen. Denken, Designen, Diskutieren!

Als Sahnehäubchen “On-Top” wird es eine besondere Location geben, die wir eine Woche vor dem Dojo bekanntgeben werden! Freut euch, dieses „Dojo Deluxe“ darf man nicht verpassen! Sei dabei, wenn die .NET Community mit modernsten Software-Entwicklungs-Methoden das Code-Kata von Ralf löst! Auf geht’s: Anmelden!

Coding Dojo Bei Dir!

Nach diesen Dojo-Highlights komme ich wieder zum Anfang meines Posts zurück. Wir, die .NET Coding Dojo Community aus München sind überzeugt von den Vorteilen, die ein .NET Coding Dojo mit sich bringt. Immer wieder freuen wir uns, gemeinsam eine Aufgabe zu lösen, neue und bekannte Gesichter wiederzusehen und uns auszutauschen. Über kleine Dinge, wie z.B. Resharper-Shortcuts. Aber auch über große Dinge, wie z.B. Template Method vs. Higher Order Functions. Das ist es aber nicht, was Pete und mich als Initiatoren der .NET Coding Dojo-Bewegung nun dazu veranlässt, einen Haken hinter unser erstes Etappenziel zu setzen. Es ist etwas anderes.

Mittlerweile gibt es viele Interessierte, die die Idee und das Konzept des .NET Coding Dojo’s gut finden und selbst implementieren. Es gibt .NET Coding Dojo’s nun nicht mehr nur in München, sondern auch in Berlin, Hamburg, Wien, Augsburg, Ingolstadt, Karlsruhe und sogar ortsunabhängig Online! Auch wenn nicht viel darüber geredet wird oder darf, ich kenne mittlerweile eine handvoll Unternehmen, die intern regelmäßig Dojo’s durchführen, und das mit sensationellen Erfolgen. Doch auch diese Verbreitung und das allgemein steigende Interesse für .NET Coding Dojo’s ist es nicht, was unsere erste Etappe als erledigt markiert. Es ist etwas anderes.

Goto Dojo Considered Helpful

Es ist der einfache, ungeschriebene, stille aber dennoch treibende und gedeihende Gedanke, dass die .NET Entwickler-Gemeinde Coding Dojo’s als eine hilfreiche und gleichzeitig unterhaltsame Maßnahme akzeptiert und implementiert. Es ist die Bewegung und Bereitschaft der Community, eigenständig Coding Dojo’s zu organisieren und zu veranstalten. Es ist der schlichte Umstand, dass mittlerweile „.NET Coding Dojo“ nicht mehr nur mit „Pete“ oder „Ilker“ oder diesen Blog hier assoziiert wird, sondern vielmehr mit gemeinsamer Entwicklungsleistung, mit Code-Kata’s, der Clean-Code-Developer-Bewegung und mit den vielen Gesichtern und .NET-Enthusiasten in der Community. Das ist es, was uns dazu veranlässt ein „Check“ zu machen und uns auf schon auf die nächsten Coding Dojo’s zu freuen.

An dieser Stelle möchte ich jeden .NET Entwickler, TDD-Interessierten und CCD-Freund dazu motivieren, selbst an einem .NET Coding Dojo teilzunehmen oder aber ein .NET Coding Dojo zu gründen. Wie man aus der Ankündigungsliste unschwer ableiten kann, ist es garnicht so schwer, ein .NET Coding Dojo zu gründen. Die gesamte Coding-Dojo-Community kann und wird euch dabei unterstützen mitzumachen. Die besten Anlaufstellen sind hier die Xing-Gruppe und die Facebook-Page! Sei dabei, mach mit, es lohnt sich!

Goto Dojo Considered Helpful!

Thomas stellt zur Debatte, ob man aus Repository-Methoden ab und zu auch mal null zurückgeben darf/kann/soll. So z.B. bei so einer Methode:

User GetUserByName(string name);

Mache das Unmögliche möglich?!?

Einige Leute finden das garnicht besonders gut. Sie bevorzugen lieber soetwas wie einen “nicht-existenten” User zurückzugeben. Also eine Instanz einer Klasse, die eigentlich garnicht möglich wäre (weil sie ja die nicht exsistierende Instanz darstellt). Programmtechnisch ist das sicherlich recht einfach lösbar – oftmals mit einer statischen Property, die sich wiederum eines privaten Konstruktors bedient. In dem obigen Beispiel könnte eine derartige Implementierung ungefähr so aussehen:

public User GetUserByName(string name)
{
  if (!repository.UserExists(name))
    return User.NotExistent;

  //user laden und zurückgeben
}

Eine zweite, nicht minder bevorzugte Alternative zur Rückgabe von NULL ist die beliebte Exception. Falls also kein Benutzer unter dem angefragten Namen existieren sollte, dann soll eine Ausnahme signalisiert werden. Ganz einfach implementiert:

public User GetUserByName(string name)
{
  if (!repository.UserExists(name))
    throw new UserNotFoundException(name);

  // user laden und zurückgeben
}

Beides sind sicherlich mögliche und sogar gute Alternativen zu der Implementierungsvariante, die Thomas zur Diskussion gestellt hat:

public User GetUserByName(string name)
{
  if (!repository.UserExists(name))
    return null;

  // user laden und zurückgeben
}

Um es kurz zu fassen: Alle drei Varianten sind möglich, alle drei Varianten sind gut, alle drei Varianten sind schlecht. Es kommt auf den Anwendungsfall an. Die beliebte “It-Depends”-Weisheit streckt das Thema mit geballter Kraft nieder. Dennoch ist es eine Untersuchung wert, denn ungewöhnlicherweise wird die NULL-Variante kategorisch als falsch und “böse” bewertet.

Nullbivalenz

NULL ist ein besonderer Wert. Er ist der Wert, der eigentlich nicht zugewiesen werden kann. Genauer genommen ist er kein Wert, sondern nichts anderes als die knapp in vier Buchstaben formulierte Aussage “Ein für eine bestimmte Werteklasse belegter Ort wurde mit keinem Wert belegt”. Ergo: Null ist kein Wert. Ja, aber ist das denn nicht genau das, was GetUserByName ausdrücken und zurückgeben muss, wenn es keinen Benutzer für den gegebenen Namen findet?

Schaut man sich die erste Alternative zu NULL an (also das User.NonExistent-Konstrukt), dann kann man sagen: Joa, ok – ist aber das Gleiche. User.NonExistent ist sicherlich expliziter als NULL. NULL ist aber schon da und genau für solche Dinge gedacht. Die Aufgabe von NULL ist ja genau die, keinen Wert darzustellen.

Und wie sieht es mit Alternative Zwei – der UserNotFoundException aus? Die Excpetion ist auch explizit. Mehr noch, die Exception ist flexibel und rigoros gleichermaßen. Flexibel, weil sie jederzeit aus dem Nichts auftauchen kann. Rigoros, weil sie eine Fülle von Informationen über den Kontext sammeln und mitgeben kann. Die Exception sagt hier klar und deutlich: “Es gibt keinen Wert, weil der Benutzer {name} nicht gefunden wurde.”. Scheinbar ein Vorteil gegenüber den anderen Varianten. Im Ergebnis ist es jedoch nicht wesentlich von den anderen Herangehensweisen unterscheidbar.

Null Sicherheit

Nun, offensichtlich ist die sprechendere Variante der Exception vorteilhaft und damit dem NULL vorzuziehen. Doch beim zweiten Blick entpuppt sich der Vorteil als nicht so deutlich als zunächst vermutet. Denn in der Praxis kann sich die “unklare” und “unexplizite” Art von NULL wieder als erwünscht erweisen.

So muss man bei Exceptions, um den Mehrwert zu kennen, auch deren Typ genau kennen. Man muss also Wissen, das es sich um eine UserNotFoundException handelt. Erst dann kann man auch erfahren, welcher ominöse Benutzer unauffindbar ist. Das kann durchaus problematisch werden, wenn man also im höheren Callstack wissen muss, um welche Exception es geht, denn schliesslich schafft man sich dadurch eine Abhängigkeit auf den niedrigeren Code.

Null ist also eine unsichere, uninformative, aber immer verfügbare und unabhängige Variante, dem Aufrufer zu sagen: “Es gibt keinen Wert für das, was Du von mir verlangst”. Wenn man sich mit der Anwendung von NULL jahrelang auseinandergetzt hat und auch ein wenig die ungeliebten Interna von Speichermanagement & Datenstrukturen hineinblickt, dann wird NULL schnell zu einer praktikablen Lösung für schwierige Situationen.

Doch vor Allem bei NULL stellt man immer wieder fest: praktikabel und elegant sind zwei verschiedene paar Schuhe. Denn NULL ist genauso nichtssagend wie vielseitig. NULL zwingt den Aufrufer zum Abwägen: Soll ich das Ergebnis gleich auswerten oder lieber überprüfen? Ein wunderbares Beispiel dafür ist sicherlich der “if (x != null)”-Check – die Null-Prüfung. Das wird vor Allem dann zum Problem, wenn man mit (gewollt oder ungewollt) unbekannten Komponenten arbeitet. Im Interface oder in der Typsignatur steht es jedenfalls sehr selten erkennbar drin, ob nun in Einzelfällen NULL zurückgeliefert wird oder nicht.

Null ist nicht gleich Null

Für mich gibt es beim Umgang und bei der Anwendung von Null keine Faustregel. Ich gebe in einigen Methoden NULL zurück. Meistens genau dann, wenn ich wirklich damit ausdrücken möchte, dass etwas katastrophales passiert ist. Ich finde es sehr schwerwiegend, NULL als Zuweisung oder Rückgabe stehen zu lassen – aber ich mache es manchmal ganz bewusst. In einer Anwendung, in der ich z.B. Benutzer über einen Authentifizierungsdienst identifizieren muss, bevor ich überhaupt etwas anderes machen kann, kann die folgende Signatur NULL zurückliefern:

interface IAuthenticationService
{
  Account SignIn(string user, string password);
}

Es kann alles mögliche passiert sein – keine Verbindung zum Server, falscher Server, Verbindungsfehler, Connection Timouts, Benutzer nicht gefunden, Benutzer gesperrt, Passwort abgelaufen, falsches Passwort – all dies würde ich versuchen über Exceptions oder Return-Codes zu erledigen. Die meisten der Exceptions gibt es ja schon frei Haus vom Framework. Aber für das mich Unbekannte und Unerwartete gibt es immer noch eine Rückgabe, und die heisst NULL.

Null-Summen-Spiel

Generell kann ich für mich nur sagen, dass ich gelernt habe mit NULL sehr vorsichtig umzugehen. Ich vermeide es so gut wie möglich. Exceptions sind ein gutes Mittel – allerdings setze ich sie auch nicht sehr oft ein. Die Bürde der Abhängigkeit ist schon da – obwohl es natürlich in der Contract-Assembly definiert ist. Bei Repositories habe ich (fast) immer Ergebnisse die nicht NULL liefern. Andererseits setze ich NULL als Rückgabe auch öfter ein, wenn ich nur eine “schwere” Ausnahme in meinem Code feststelle.

Im obigen Beispiel hätte ich wohl NULL als Rückgabe toleriert, vor Allem, wenn ich davon ausgehen kann, dass es oft – oder sehr oft – dazu kommen kann und diese Tatsache ein schwerwiegendes Problem darstellt. Ein schönes Beispiel sind immer wieder die Brute-Force und DOS-Attacken auf Webportale.

Ich hätte wahrscheinlich nicht NULL zurückgegeben, sondern eine Exception ausgelöst, wenn ich das Ganze als wiederverwendbare, allgemeine Kompontente entwickeln würde.

So oder so – beides ist machbar und beides hat seine Berechtigung. Klar und deutlich soll aber abschließend erwähnt sein: NULL zu vermeiden ist eine gute Sache. Es macht den Code expliziter, offensichtlicher und lesbarer.

Der Pate unter den Test-Frameworks

So ist es auch nicht weiter erstaunlich, dass man nahezu überall, wo das Wörtchen “Test” fällt, auch “NUnit” zu sehen bekommt. Sei es nun bei den Codeassistenten, bei Build- oder CI-Tools, Addins und sogar weiteren Test-Frameworks. Die Verbreitung und Unterstützung von NUnit ist hier einfach nicht zu toppen. Aber auch die vielen Kontakte und Beziehungen des “Paten der Test-Frameworks” helfen nicht viel beim Meta-Test mit dem FizzBuzz-Kata! Auf geht’s!

Der Code

FizzBuzz ist mit NUnit und den “Standard-TDD-Regeln” schnell implementiert. Referenz hinzufügen, Testklasse inklusive Testmethode aufbauen, noch schnell ein using NUnit.Framework; und die beiden Attribute [TestFixture] (für Klassen) sowie [Test] hinzugefügt – und schon kann man fröhlich testen!

Wer jetzt einen Codeassistenten wie Resharper oder Coderush hat, ist praktisch nur ein Klick bzw. Tastenschlag von der Testausführung entfernt. Doch auch ohne “Code-Beschleuniger” gehen NUnit-Tests elegant, z.B. mit dem TestDriven.NET Addin. Mal von diesen “Integrationstüren” abgesehen, bietet NUnit auch eigenständige Runner für die Konsole sowie auch als Windows-Anwendung an. Passt!

using NUnit.Framework;

namespace KataFizzBuzzNUnit
{
    [TestFixture]
    public class FizzBuzzTest
    {
        private FizzBuzz target = new FizzBuzz();

        [Test]
        public void Multiples_Of_Three_Returns_Fizz()
        {
            Assert.That(target.Translate(6), Is.EqualTo("Fizz"));
        }

        [Test]
        public void Multiples_Of_Five_Returns_Buzz()
        {
            Assert.That(target.Translate(10), Is.EqualTo("Buzz"));
        }

        [Test]
        public void Multiples_Of_Three_And_Five_Returns_FizzBuzz()
        {
            Assert.That(target.Translate(15), Is.EqualTo("FizzBuzz"));
        }

        [Test]
        public void No_Multiples_Of_Three_Or_Five_Returns_Number()
        {
            Assert.That(target.Translate(7), Is.EqualTo("7"));
        }
    }
}

Bei der Implementierung fühlt man sich schon fast wie bei MS-Test, jedoch mit einem ganz gewaltigen Unterschied: Die Assert-Klasse im Allgemeinen sowie die Assert.That() Syntax von NUnit sind mächtig – und mächtig hilfreich. Das mit NUnit 2.4 eingeführte Constraint Model ist nicht nur besser lesbar, sondern auch intuitiver. Kennt man mal die wichtigsten Constraints, vergisst man sie auch nicht mehr so schnell. Alles in Allem ist TDD mit NUnit eine runde Sache. In weniger als 5 Minuten strahlten meine 4 Tests und ich uns gegenseitig an.

Bewertung

• Dauer
  Zackig, Knackig, ohne Trärä und Tamtam. FizzBuzz-Regeln in 5 Minuten. Mit Codebeschleuniger geht’s sogar noch schneller. Passt.
• Größe
  Ähnlich wie bei MS-Test. Eine kompakte Testklasse mit 4 Testmethoden.
• Tooling
  MS-Test war schon sehr gut – doch NUnit ist sogar noch besser! Die Verbreitung in der OSS-Gemeinde macht sich hier bemerkbar. Top.
• Usability
  Sehr gut. Assert’s schön mit Constraints. Wenn man möchte sogar noch beschleunigt über das Erben von AssertionHelper. Angenehm.
• Support
  Unmengen an Material im Internet. Open-Source, stabil, große Gemeinde, aktive Entwicklung. Zufrieden.

Hmm, es fällt mir schon schwer, etwas “negatives” an NUnit zu finden. Es mag den einen oder anderen stören, wie die Test-Projekt-Struktur von NUnit aufgebaut ist. Auch der GUI-Runner ist jetzt nicht der Augenschmaus schlechthin. Doch die Kernkompetenzen werden von NUnit bravourös gemeistert.

NUnit – Die Referenz

Als kleines Fazit kann ich für mich schon mal sagen – NUnit hat die Messlatte ganz schön hochgelegt. Effektiv betrachtet ist NUnit als Test-Framework derzeit die Referenz, mit der sich alle anderen messen lassen müssen. Das ist auch gut so, denn NUnit ist durch die jahrelange, stetige Entwicklung viele Schritte gegangen – manchmal auch einige Schritte voraus. Bleibt die Frage offen: Gibt es noch bessere Test-Frameworks für C# und .NET als NUnit? Abwarten, meine Test-Serie geht in Kürze weiter. Stay tuned!

Los geht’s mit Projekten

Aber zurück zur Sache. Es muss ja schließlich das mittlerweile mehr als bekannte FizzBuzz-Kata als Fingerübung implementiert werden.

Da tut sich schon interessantes am Anfang auf: Durch die nahtlose Integration in Visual Studio fügt man keine Referenz auf irgendeine Framework-DLL hinzu, sondern startet die Tests mit der Erstellung eines Testprojektes. Für mich persönlich ein wenig gewöhnungsbedürftig – ich schreibe man Tests und Code für gewöhnlich in der selben Assembly und lagere es nur auf ausdrücklichen Wunsch aus.

Nach Abschluß der durch den (eigentlich um die Arbeit zu beschleunigen konzipierten) Projekt-Wizard durchgeführten Vorbereitungen und der manuellen Abschlussvorbereitungen kann es nun endlich losgehen.

Straight-Forward mit Attributen und Asserts

Die Test-Methoden gehen schnell von der Hand, man braucht nur das [TestMethod] Attribut hinzufügen. Die Assert-Klasse deckt alle notwendigen Prüfungen ab, bietet aber im Vergleich zu anderen Frameworks wie z.B. NUnit wesentlich weniger “methodische Expressivität”. In unserem Fall brauchen wir nur die AreEqual-Methode. Schon nach dem ersten Test fällt allerdings die lange Testdauer des Testrunners ein wenig negativ auf. Das kann auch wesentlich schneller gehen.

Das Test-Ergebnis sieht relativ unspektakulär aus:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace FizzBuzzMSTest
{
    [TestClass]
    public class FizzBuzzTest
    {
        [TestMethod]
        public void Multiples_Of_Three_Returns_Fizz()
        {
            FizzBuzz target = new FizzBuzz();
            string translation = target.Translate(6);
            Assert.AreEqual("Fizz", translation);
        }

        [TestMethod]
        public void Multiples_Of_Five_Returns_Buzz()
        {
            FizzBuzz target = new FizzBuzz();
            string translation = target.Translate(10);
            Assert.AreEqual("Buzz", translation);
        }

        [TestMethod]
        public void Multiples_Of_Three_And_Five_Returns_FizzBuzz()
        {
            FizzBuzz target = new FizzBuzz();
            string translation = target.Translate(15);
            Assert.AreEqual("FizzBuzz", translation);
        }

        [TestMethod]
        public void No_Multiples_Of_Three_Or_Five_Returns_Number()
        {
            FizzBuzz target = new FizzBuzz();
            string translation = target.Translate(7);
            Assert.AreEqual("7", translation);
        }
    }
}

Bewertung

• Dauer
  Die FizzBuzz-Implementierung ging relativ zügig von der Hand. Ich habe ca. 15 Minuten gebraucht. Der “lahme” Testrunner hat mich etwas gestört. Die meiste Zeit ging für das Projekt, die Referenzverweise und das hin und her zwischen den Projekten drauf.
• Größe
  Die Testgröße ist überschaubar. Eine kompakte Testklasse mit 4 Testmethoden. Eine klassische Class-Per-Class Struktur. Das Testprojekt ist isoliert vom Code.
• Tooling
  Ein regelrechtes Heimspiel mit der VS-Integration. Auch Code-Assistenten wie Resharper oder Coderush kennen den MSTest. Alles in Allem eine sehr gute Unterstützung.
• Usability
  Durch den Projekt-Wizard und die entsprechende Dokumentation komfortabel für allgemeines Testing. Speziell für TDD/BDD allerdings etwas hakelig. Immer gleich die Test/Code-Separation. Die Asserts sind sicherlich ausreichend.
• Support
  Was soll man hier schreiben, außer MS? Das Framework wird direkt von Microsoft mit Visual Studio ausgeliefert. Die Dokumentation ist gut, Online-Material ist sicherlich vorhanden. MSTest ist in der Community (vor allem für Open Source oder kleinere Projekte) nicht so weit verbreitet wie andere Frameworks.

MS-Test ist ein solides Framework, mit dem sich sicherlich auch gut TDD betreiben lässt. Man merkt dem Featureset an, dass es nicht nur für Unit-Testing ausgelegt ist. Der integrierte Runner ist schick, das Reporting ein Highlight. Ich sollte nicht unerwähnt lassen, dass vor Allem die Kombination TFS/MSTest ein sehr gutes Reporting/Monitoring-Werkzeug darstellt.

Zu den Tests selbst gibt das Framework wenig Hilfestellung bzw. Guidance zur Strukturierung und Anwendung der Tests. So wird wohl am meisten die Class-Per-Class Struktur angewendet werden, mit den üblichen TDD Best Practices.

MS-Test leider nur für “Profis”

Ein absolutes Manko ist die nicht-freie Verfügbarkeit des Frameworks und damit auch das Fehlen des Features in der Express-Edition. Einfach mal Tests/Code schreiben und veröffentlichen ist somit unmöglich. Für bekennende TDDler ein No-Go. Mit den 15 Minuten Fizzbuzz ist die Umsetzungsgeschwindigkeit in Ordnung – wobei ich zugegebenermaßen Fizzbuzz auch schon wesentlich zügiger implementiert habe. Das bringt mich dann auch zum nächsten Test-Framework unter meiner Meta-Test-Lupe… stay tuned!

Ein Bereich, den ich mir dabei näher angeschaut habe ist das Tooling. Ich wurde in der Vergangenheit schon öfters gefragt, welches Test-Framework ich denn einsetze. In letzter Zeit werde ich aber auch ab und an gefragt, welches Test-Framework denn jetzt besser sei. Als Hilfestellung zur Findung einer Antwort auf diese Fragen sowie einen Überblick über die gängigsten Test Frameworks soll dieser Artikel beitragen.

Die Kandidaten

Mit diesem Artikel beginnt die kleine Blog-Serie “Meta-Test”, die Stück für Stück die populärsten Test-Frameworks für .NET und C# unter die Lupe nimmt, sie bewertet und natürlich auch vergleichen wird. Bisher gab es schon folgende Tests:

• MS Test – Visual Studio On Board Test-Framework
• NUnit – All-Time-Hall-Of-Fame-Most-Valueable-Tester
• NSpec – der spezifizierende BDD-Veteran

Die Hypothese

Vorab möchte ich allerdings noch eine – für mich wichtige – Anmerkung äußern. Beim Test der Testframeworks habe ich mehrere Code Kata’s mit allen Frameworks geschrieben. Am häufigsten habe ich wohl FizzBuzz geschrieben, gefolgt von Replacer, LineCounter und ein paar Mal Minesweeper. Ich habe dabei schon deutliche Unterschiede nicht nur in den Frameworks, sondern auch in der Adaption selbst festgestellt. Für den hier gezeigten Vergleich gelten folgende Hypothesen:

• TDD & BDD sind gleichwertig.
• TDD & BDD sind prinzipiell das Gleiche, mit Unterschieden in Benennung und Teststruktur
• TDD & BDD wendet man für die selbe Aufgabe an, zum Software-Design

So, und jetzt der Disclaimer:
Achtung: Die genannten Hypothesen sind nicht meine Meinung über TDD bzw. BDD!

Ganz im Gegenteil. Ich habe zu TDD ein gefestigtes Meinungsbild. Ich habe auch Erfahrung mit BDD. Gerade deswegen bin ich sehr vorsichtig mit beiden Begriffen. Ich denke, TDD und BDD sind nicht das Gleiche. Doch eine weitere Vertiefung in das Thema lenkt nur von den Frameworks ab. Deswegen wieder schnell zurück zu den Test-Frameworks.

Die Anforderungen

Als Entwickler möchte man ein möglichst effektives und intuitives Test-Framework als Werkzeug, um testgestriebenes Softwaredesign durchzuführen. Beim programmieren mit Visual Studio zum Beispiel, wenn man die Tests für die gerade zu entwickelnde Klasse oder Methode formuliert, da gehört die Unterstützung von Tools wie Resharper, CodeRush oder Gallio heutzutage schon zum guten Ton.

Ebenso geht es bei dem Vergleich um die Anwendbarkeit und Effizienz. Also wie expressiv, wie deutlich kann ich meine Tests formulieren und wie intuitiv ist die Umsetzung der Tests. Die Umsetzungsgeschwindigkeit spielt dabei genauso eine Rolle wie die Lesbarkeit, Wartbarkeit und gutes Reporting. Dazu noch später mehr.

Das Ziel

Um auch eine konkrete, relativ faire Vergleichssituation zu erreichen, stelle ich alle Frameworks an einem einzigen Beispiel vor, nämlich dem KataFizzBuzz. FizzBuzz ist eine sehr einfache Kata, die gerade genug “Widerstand” bietet, um die Grundzüge des treibenden Software-Designs sowie des Test-First zu vermitteln. Ich habe mich bei der Programmierung der Kata sogar nur auf das Teilproblem der “Fizz”- und “Buzz”-Übersetzung konzentriert. Es gibt unzählige Implementierungen von FizzBuzz. Bei dem Vergleich der Test-Frameworks habe ich mich für die “triviale” und “zügige” Implementierung entschlossen. Konkretisiert bedeutet dies, das es mein Test-Ziel war, das ich mit allen Test-Frameworks ungefähr folgenden Code produziere:

    public class FizzBuzz
    {
        public string Translate(int number)
        {
            if (number % 15 == 0)
                return "FizzBuzz";

            if (number % 5 == 0)
                return "Buzz";

            if (number % 3 == 0)
                return "Fizz";

            return number.ToString();
        }
    }

Die Metriken

Um nun die einzelnen Frameworks untereinander vergleichen zu können, braucht es nicht nur einer gemeinsamen Basis & Ziels, sondern auch einer gemeinsamen Messmetrik. Um es nicht zu theoretisch zu gestalten, habe ich einige ganz einfache, aber wie ich finde dennoch aussagekräftige Metriken ausgewählt:

• Die Dauer der Implementierung
• Die Größe der Test-Artefakte (Klassen usw.)
• Das Tooling, also die Unterstützung durch VS / Frameworks / Codetools
• Die Usability, also handbuchnachschlagefreie Handhabung der API / Tools
• Der Support durch Hersteller, Community und User

Doch die wichtigste Metirk ist mit Abstand die Bewertung des Ergebnisses der Test-Frameworks – also der Tests ansich. Die Tests werden unter die vier Grundmerkmale Intuitivität, Expressivität, Lesbarkeit und Wartbarkeit gestellt. Natürlich bleibt da meine eigene subjektive Note an der ein oder anderen Stelle hängen, schließlich habe ich die Frameworks eigenständig getestet und habe auch keinen Anspruch auf gestelzte Objektivität :-).

So, damit sollten die Vorbereitungen und Rahmenbedinungen für den ultimativen Vergleich der Test-Frameworks für das .NET Framework & C# abgeschlossen sein. Dieser gigantische Vergleich von einer Unmenge an Test-Frameworks – für den ich keine Kosten und Mühen gescheut habe :-) – wird als Blog-Post-Serie in den nächsten Tagen veröffentlicht.

Stay tuned!

Massiv Sportlich

Schon das letzte Münchener .NET Coding Dojo im Februar war wieder eine spannende und anregend erkenntnisreiche Veranstaltung. Das Lösen des KataTennis hat sich als eine wunderbare Übung für den überlegten, soz. “wohl bedachten” einsatz von Test-Driven-Design und -Development herausgestellt.

TDD kann viel im Design und in der Implementierung bewirken. Es fördert lose Kopplung, gestaltet aktiv die Trennung der Verantwortlichkeiten mit und unterstützt das minimalistische “DRY“-Denken. Es gibt auch frequentiven Feedback in der Entwicklung. Sei es nun, dass man sich auf dem grünen Pfad bestätigt fühlt – oder aber frühzeitig “riecht”, das da etwas nicht ganz ausgereift ist. In jedem Fall war KataTennis im Februar-Dojo eine schöne Aufgabe, die all diese Faktoren präsentierte. Mehr noch, das Dojo zeigte, dass es sich lohnt, die Analyse der Problemdomäne nicht außer Acht zu lassen. Der Code lässt sich wie immer auf dem Codeplex-Projekt einsehen.

Massiv Interessant

Doch das war noch lange nicht alles, was sich zum Thema .NET Coding Dojo im Februar getan hat! Vorreiter war schon im Januar die .NET User Group Karlsruhe mit einem .NET Coding Dojo der “Schwarzgurt-Klasse”. Es wurde KataPotter angegriffen. Die DNUG hat gespürt, dass ein Coding Dojo schweißtreibend ist – aber auch spannend und fesselnd. Denn schon einen Monat später gab es in professionell agiler Manier eine Retrospektive zum Coding Dojo. Die DNUG Karlsruhe bleibt also am Ball!

Auch ich konnte noch einen kleinen Beitrag zur Coding Dojo Idee leisten, in dem ich auf der diesjährigen VSOne das Format und die Ziele des .NET Coding Dojo vorgestellt habe. Doch bei der Vorstellung alleine bleibt es bei Dojojanern natürlich nicht – in der Session wurde demonstrativ ein “Mini-Dojo” mit KataFizzBuzz gestartet. Es war eine wunderbare Erfahrung, wie interessiert und motiviert unvoreingenommene Teilnehmer im Coding Dojo mitmachen. Danke für das zahlreiche Interesse!

Im Übrigen möchte ich dabei noch betonen, dass die diesjährige VSOne eine wirklich gelungene und qualitative Veranstaltung gewesen ist.

Last but not least: Die .NET Coding Dojo-Idee ist grenzübergreifend! Angespornt und motiviert durch die Events in Deutschland gab es im Februar auch ein eigenständig von Andreas organisiertes .NET Coding Dojo in Wien! Es wird also auch schon in Österreich kräftig trainiert. Kurzum: Massiv Interessant!

Massiv Im März

Natürlich steht auch schon das nächste Münchener .NET Coding Dojo vor der Tür. Am 10. März erwartet die Teilnehmer ein Coding Dojo der Extra-Klasse. Im März-Dojo werden die gebündelten Kräfte und Kompetenzen von .NET Enthusiasten, Software-Entwicklern & TDD-Interessierten gebraucht. Soviel sei schon vorab verraten: dieser Coding Dojo wird eine Herausforderung!

Im “Massiv-Im-März” Coding Dojo werden wir drei spannende Code Kata’s im Angebot haben, die wieder besondere Techniken sowie Praktiken fordern und fördern. Es geht dabei um Analyse, Design und Implementierung gangbarer, nachhaltiger, effektiver Lösungen zu einem kleinen Programmierproblem. Kurzum: Gemeinsam lernen & lehren von profesioneller Software-Entwicklung mit TDD, CCD und Design Patterns.

Was heißt das? Ganz einfach – auf geht’s zum Dojo! Anmeldung per Xing Event oder Facebook Event!

Übrigens, ein schöner Zufall will es, dass das Münchener .NET Coding Dojo parallel zu den Tagen des dotnetpro.powerday stattfindet. Wer es noch nicht weiß, in den dotnetpro.powerday zeigen Ralf & Stefan auf Ihre gewohnt einprägsame Weise, welche Werte, Prinzipien & Praktiken es bedarf, um nachhaltigen, wartbaren und erweiterbaren – also Clean Code zu schreiben. Die frisch gewonnen Erkenntnisse kann man dann natürlich bei uns im Coding Dojo einsetzen! :-)

Viele werden schon davon gehört haben, und viele werden es auch schon kennen: Code Contracts. Obwohl Code Contracts noch nicht offiziell veröffentlicht wurden, sind Code Contracts mittlerweile keine neue Sache. Im Gegenteil, Durch die massive, jahrelange Forschungsarbeit von Microsoft sind Code Contracts seit über einem Jahr sehr stabil und zuverlässig. Interessanterweise wurden Code Contracts nicht spezifisch erforscht, sondern sind als “Nebenprodukt” der Forschungen zu Boogie/Clousot (der statischen Verifikationskomponente von Spec#) entstanden.

Man findet mittlerweile sehr viele Beispiele und Casts zu Code Contracts und all den Features, die Code Contracts mit sich bringen. Ein aktuelles Video und eine wirklich sehenswerte, einfache Einführung in die Features ist die PDC09 Session über Code Contracts und PEX (dem automatisierten Unit Testing Tool). Es ist konsequenterweise nicht verwunderlich, dass Code Contracts seit über einem halben Jahr in den DevLabs zur Verfügung gestellt werden und mit .NET 4.0 in der mscorlib integriert sein werden (also in .NET 4.0 mit enthalten sein werden).

Parameterverifikation mit Stil

Eine besondere und herausstechende Eigenschaft der Code Contracts ist jedoch, dass es sich wunderbar einfach in eine existierende Code-Basis einführen lässt. Dadurch das Code Contracts viele Vorteile mit sich bringen, kann man eine stufenweise Integration anstreben. So ist es eine gangbare Methode, Code Contracts im ersten Schritt für die Dinge einzusetzen, die man sowieso schon jahrelang macht, wie z.B. Parameterprüfungen in Methoden (Vorbedingungen):

//...
public void ProcessOrder(IOrder order)
{
  if (order == null) throw new ArgumentNullException();
  //...
}
//...

Diese “Contracts” werden mittlerweile von Tools wie ReSharper oder CodeRush auf Wunsch automatisch generiert, um dem Entwickler den Tippaufwand zu ersparen. Es gibt in manchenvielen Anwendungen und API’s auch nette Hilfsklassen, die diese Prüfungen beschleunigen:

//...
public void ProcessOrder(IOrder order)
{
  Argument.MayNotBeNull(order);
  //...
}

public static class Argument
{
  public static void MayNotBeNull(object o)
  {
    if (o == null) throw new ArgumentNullException();
  }
}

Genau dieser, ich möchte schon fast sagen tagtägliche Anwendungsfall kann mit Code Contracts sofort umgesetzt werden:

public void ProcessOrder(IOrder order)
{
  Contract.Requires(order != null);
  //...
}

Lesbar, einfach und effektiv gesehen exakt das selbe, was man schon seit Jahren “per Hand” programmiert. Das Schöne ist hier allerdings, das es die Tür für die weiteren Tools (z.B. statische Verifikationsanalyse) öffnet. Mit der Zeit kann man auch nicht nur die Preconditions mit den Code Contracts umsetzen, sondern auch die Postconditions und Invariants einsetzen.

In einem späteren Schritt kann man zu den Prüfungen zur Laufzeit auch die statische Verifikation noch mit einführen, um kritische Anwendungsteile in der Stabilität zu stärken. Es gibt noch viele weitere Vorteile, die Code Contracts mit sich bringen (z.B. Verifikationsdefinitionen auf Schnittstellen), auf die ich hier nicht näher eingehen werde. Ich denke jedoch, dass jeder, der sich ein wenig mit den Code Contracts auseinandersetzt, die klaren Vorteile erkennen wird.

Weihnachten ohne Geschenke?

Die Frage ist nun: würde man Code Contracts in eine bestehende heute schon Codebasis integrieren wollen? Die aktuelle Version der Code Contracts muss man separat referenzieren, denn die Contracts werden erst mit .NET 4.0 ein fester Bestandteil der BCL sein. Man stelle sich nun ein agiles Projekt vor, in dem wöchtenliche Releases keine Seltenheit sind. Würde man in so einer Situation den Einsatz von Code Contracts befürworten oder eher abwarten, bis es .NET 4.0 veröffentlicht wurde. Lizenzteichnisch gäbe es keine Probleme, zumal die Code Contracts in der aktuellen Version schon über eine Going-Live-Lizenz verfügen.

Dafür spricht, dass die Code Contract API schon seit über einem Jahr stabil ist. Die Contract-Assembly wurde sehr sorgfältig über einige Jahre hinweg entwickelt. Ein weiteres Pro-Argument ist sicherlich die definitive Integration mit .NET 4.0. Schon heute steht fest, dass System.Diagnostics.Contracts eine fester Bestandteil der neuen .NET-Version sein wird. Die Vorteile, die die Code Contracts selbst mit sich bringen (also verbesserte Verifikation zur Laufzeit, statische Verifikation, erleichterter Einsatz von weiterführenden Tools wie z.B. PEX) erwähne ich nur nebenbei.

Dagegen würde wohl momentan nur die Tatsache sprechen, dass die Contracts noch nicht Final sind. Die API kann sich in den einigen Monaten bis zur Veröffentlichung von .NET 4.0 noch ändern (obwohl es lt. Aussage der Entwicklungsmannschaft wohl unwahrscheinlich ist). Ein weiteres Gegenargument für den sofortigen Einsatz ist wohl das Deployment. Abhängig vom Anwendungstyp muss man da einige Parameter berücksichtigen. Doch für den jetzigen Anwendungsfall möge man von einem agilen Software-Projekt mit frequentiven Releases ausgehen, z.B. ganz klassisch bei einer Web-Anwendung. Hier muss man abwägen, ob man die Contracts-Assembly auf den Webservern im GAC installiert oder mit den eigenen Assemblies mit ausliefert.

Nach dieser kurzen Pro-Contra-Gegenüberstellung würde mich Eure Meinung interessieren. Was meint Ihr? Wer setzt es heute schon ein? Wer möchte es noch vor dem .NET 4.0 Release einsetzen? Wer möchte lieber abwarten bis .NET 4.0?

Die Frage ist: Das Geschenk “Code Contracts” heute schon annehmen und einsetzen? Ja oder Nein?

Ich hatte mir für das erste Experten-Dojo zwei Dinge auf der Agenda. An erster Stelle stand nochmals die Implementierung des FizzBuzz-Katas auf dem Programm. Nach dem Dojo hatte ja auch schon Ralf das FizzBuzz Code Kata implementiert. Also dachte ich mir, zum aufwärmen ist das bestimmt eine gute Aufgabe.

Wir haben uns an die Aufgabe im Modus “Randori” herangewagt. Ich muss sagen, für diesen allerersten Versuch, eine Code Kata per Randori zu lösen lief es erstaunlich gut. Schnell haben alle Teilnehmer festgestellt, dass es eine Übereinstimmung über die Herangehensweise der Implementierung geben muss. Die Tests waren trivial und dementprechend weniger Gegenstand der Diskussion.

Darüber hinaus war es interessant zu beobachten, dass auch bei der geballten Ladung an Kompetenz und Erfahrung die Implementierungsgeschwindigkeit sich nicht daramatisch verkürzt. (Zum Vergleich: Im Einsteiger-Dojo wurde FizzBuzz in ca. 2 Stunden gelöst, die Experten Runde hat knapp 1 Stunde gebraucht). Der Grund dafür sind vorrangig weiche Faktoren wie Teamfindung und -bildung. Aber auch fachliche Bremsspuren waren zu beobachten: Die Teilnehmer haben sich z.T. bei der Implementierung um Designfragen gekümmert – wohl mit den Gedanken der Wierderverwendbarkeit und Generalisierung im Hinterkopf. Dieser Hauch von “Design-Upfront” wurde aber schnell erkannt und ausgeräumt.

Nach einer kurzen Denk- und Verschnaufpause haben wir uns an das zweite Code Kata “RPN Calculator” herangewagt. Dabei geht es um die Simulation eines Taschenrechners, welches mit umgekehrt polnischer Notation arbeitet.

Nach der Vorstellung des Kata und der dazu gehörigen Akzeptanzkriterien ging es wieder mit Schwung los. Unterschied zum ersten Mal: Es wurde nicht sofort mit den Tests losgelegt, sondern in der Runde eine grundsätzliche Einigung über das Verständnis der Aufgabe und damit “grobe” Design der Implementierung herbeigeführt. Erst dann ging es los mit dem klassischen TDD. Test – Rot – Implementieren – Test – Grün – Refaktorisieren – Test – Grün.

Nach der Implementierung der Grundfunktionalität (die Addition und Subtraktion waren funktional korrekt), ging es ans Refaktorisieren. Hier wurden zur Beseitigung von Code-Redundanz in mehreren Methoden einer Klasse zwei Lösungsansätze verfolgt.

Template Methode

Der zweite Lösungsweg war im Gegensatz zum ersten ein ein äußerst effektiver: Die Übergabe einer Lamda-Funktion auf eine private “Template Methode”. Im Endeffekt die selbe Lösung, halt funktional statt orientiert an der “reinen” OO-Lehre:

...
public void Add()
{
    this.Calculate((x, y) => x + y);
}

private void Calculate(Func<decimal, decimal, decimal> op)
{
   /* get x somewhere */
   /* get y somewhere */

   decimal result = op(x, y);

   /* put result somewhere */
}
...

Ich möchte jetzt nicht zu sehr ins Detail eingehen – jedoch war deutlich erkennbar, dass die Teilnehmer für beide Lösungswege offen waren – abhängig vom gegebenen “realen” Kontext würde man die eine oder andere Verfahrensweise bevorzugen.

Abschliessend kann ich nur sagen, war dieser erste .NET Coding Dojo für Experten ein gelungenes Event – nicht zuletzt wegen der regen und aktiven Beteiligung der Teilnehmer. Ich finde diese Art des Lernens, Informationsaustausches und “Networkings” zunehmend attraktiv und spannend. Das macht Lust auf mehr!

Ich freue mich schon auf das nächste .NET Coding Dojo! Hier nochmal die nächsten Termine für die Dojo’s in München: am 7. Oktober das .NET Coding Dojo für Einsteiger und am 21. Oktober das .NET Coding Dojo für Experten! Auf geht’s: jetzt anmelden via Ning oder Xing! Ich bin dabei!

Besonders gut fand’ ich persönlich das Pete am Anfang besonderen Wert auf die Unit Tests gelegt hat. Dies hat allen gezeigt, wie gut und produktiv testgetriebene Entwicklung funktionieren kann. Ein weiterer dicker Pluspunkt war die Offenheit der Teilnehmer – alle waren von Anfang an bei der Lösungsfindung dabei. Es war wirklich interessant festzustellen, wie verschiedene Ansätze zum lösen der Aufgabe gesucht und gefunden wurden.

Nachdem die Grundfunktionalität des “FizzBuzz”-Generators implementiert war, hat Pete den 2. Gang eingelegt und uns alle zu ein wenig mehr OO-Design aufgefordert. Die Anforderung, “schreibe den Generator so, dass beliebig viele Bedinungen hinzugefügt werden können” hat am Anfang schon ein wenig Kopfschmerzen verursacht. Dennoch war das Team schnell auf der richtigen Fährte und hat die einzelnen Bedingungen in eigene Filter-Klassen refaktorisiert.

Ach was soll ich sagen, es war ein gelungener Coding-Abend, vor allem weil die Atmosphäre gestimmt hat und das Thema immer spannend blieb.

Danke an alle Teilnehmer, er hat wirklich Spass gemacht! Hoffentlich auf Bald in einem der nächsten Dojo’s, am 23. September 2009 Meijin für Experten oder am 07. Oktober 2009 Shinzan für Einsteiger! Ich freue mich schon auf das erste Experten-Dojo.

Let’s Code In Dojo!

Steve Sanderson beantwortet diese Fragen in seinem Unit Test Best & Worst Practices Artikel äußerst anschaulich. Ich möchte hier dennoch einen kurzen Abriss über die Fragestellung und seine Antworten geben.

Zunächst einmal sollte die Eingangsfrage geklärt werden: Wozu Unit Tests? Ganz einfach: Um konsequent stabile Software entwickeln zu können. Bei Unit Tests geht’s also nicht um Fehlerfindung (jeglicher Art), sondern um eine Entwicklungsmethode, von vornherein Komponenten einer Software funktional korrekt und technisch stabil zu entwickeln. Unit Tests helfen auch deutlich bei der Verwaltung und Veränderung von Komponenten (z.B. durch Extensions oder Refactoring), um Instabilitäten während Refactorings zu erkennen und zu beheben.

Gute und schlechte Unit Tests

Damit kommt man auch unweigerlich zur nächsten Problemstellung. Wie kann ich Unit Tests anwenden, dass Sie mir dabei helfen, stabile Software zu entwickeln? Einfacher grafragt Was sind “gute”, und was sind “schlechte” Unit Tests? Steve beantwortet diese Frage aus der TDD-Sicht. Für ihn sind Unit Tests besonders dann gut, wenn sie ausschliesslich eine funktionale Beschreibung der Software-Komponente abbilden. Das kann man natürlich besonders dann gut machen, wenn man nichts über die Art und Weise der Implementierung der Funktionalität kennt, also klassisches TDD Test-First betreibt.

Ein ebenso guter Test (welches man mit Unit Testing Werkzeugen abbilden kann) ist ein echter Integrations-Test. Bei dieser Art von Tests wird nicht die Software in ihren einzelnen Bestandteilen (Klassen, Komponenten) betrachtet, sondern als Ganzes aus der Sicht des Benutzers. Es werden funktionale Bereiche getestet, ohne die Implementierung der Software zu kennen. Diese Integrations-Tests sind besonders hilfreich Regressionen des Systems festzustellen.

Damit ist auch beantwortet, welche Unit Tests nun schlechte sind: alle anderen. Im Alltag spiegelt sich das durch Tests wieder, die zu sehr auf die Implementierung eingehen (z.B. ein *Returns_Not_Null Test), auf die technischen Elemente (z.B. ein *Db_User_Created Test) oder eine komische Mischung aus reinem Unit Test und Integrations-Test sind.

Unit Tests sind Katalysator für komponenten-orientierte Software

Die Beurteilung über schlechte und gute Unit Tests ist im täglichen Einsatz von Unit Tests immer wieder in den Vordergrund zu rücken, denn dadurch lässt sich auch einiges über das System-Design und die Software-Architektur sagen. Ein System, welches das schreiben und verwalten von Unit Tests leicht ermöglicht, bei dem die Unit Tests reine Funktionalitäten testen, bei dem Unit Tests nicht von anderen Tests oder sogar der Laufzeitumgebung abhängig sind ist ein deutlich auf den Grundkonzepten der Objekt- und Komponentenorientierung aufgebautes System. Die Kohäsion ist im Mikro-System sehr hoch, um Makro-System sehr niedrig. Ein Austausch einer Komponente ist problemlos, aber funktional immer wirkend.

Sind die Symptome jedoch, dass man für die Erstellung der Unit Tests schon Zielbereiche suchen muss, das Unit Tests nur rudimentäre fachliche Aussagen treffen oder das Verwalten der Test Suite mit zunehmender Test-Anzahl immer aufwendiger und schwieriger wird, dann kann man daraus ableiten, dass das System-Design der Software tendenziell nicht auf Komponentenorientierung ausgelegt ist. Überdies lässt sich weiter schlußfolgern, dass das System mit hoher Wahrscheinlichkeit die Prinzipien “Single Responsibility” und des “Divide & Conquer” missachtet.

Schmerztherapie Unit Tests

Besonders bei existierenden Systemen, bei denen die Weiterentwicklung strategisch wichtig ist und die ökonomische Effizienz gesteigert werden soll, sind echte, gute Unit Tests ein mittelfristig starkes Werkzeug, um das gesamte System effizienter und stabiler zu gestalten. Damit ist nicht nur die Funktionalität (Integrity) oder Defekt-Quote (Defect Rate) gemeint, sondern im Besonderen der Verwaltungsaufwand (Maintenance), die Weiterentwicklungskosten (Features) und die hochgelobte niedrige Reaktionslatenz zum Markt (Time To Market). Manchmal ist es schwer Unit Tests zu schreiben, weil man grundlegende Systemkomponenten anders aufbauen und strukturieren muss, um diese testbar zu machen.

Manchmal ist es schwer, Tests für Dinge zu schreiben, deren Implementierung nicht bekannt ist. Manchmal ist es schwer, die geänderte Grundfunktionalität in dutzenden Tests nochmals zu adaptieren. Doch am Ende wird man belohnt mit schnellerer Feature-Entwicklung und einer besonders vertrauenswürdigen, stabilen Software.

Unit Testing tut gut, auch wenn es weh tut.

Dark-G-Blue

Am Arbeitsplatz verliere ich leider die Settings immer wieder durch das Hopping von Rechner zu Rechner. Da hilft nur eines – konsequent nachinstallieren bzw. die Settings immer griffbereit haben.

Letztens war es wieder einmal soweit – das grell-weisse Visual Studio hat meine Augen zu sehr penetriert. Also Farbschema laden und – endlich! Ruhe am Screen. Kurzerhand habe ich gleich mal ein paar kleine Optimierungen an den Farben vorgenommen – so habe ich auch das Highlighting und debugging verbessert.

Das Farbschema zum Download: Dark-G-Blue Visual Studio 2008 Color Scheme.

PS: Jep, nach langen Wochen wieder ein Blog-Eintrag. Ich habe mir eine etwas längere Pause gegönnt – schliesslich sind Geeks auch Menschen. Die Pause ist vorbei und ich freu’ mich schon wieder auf .NET, Entwicklung, Architektur und die restlichen digitalen Finessen :-)

Session 1: Dariusz zu Besuch in Oslo

Abstrakte Kost zum Wachwerden für müde Entwickler-Hirne präsentierte Dariusz mit der ersten Session des zweiten TS-Tages: Oslo – Modellgetriebene Entwicklung. Was ist denn Oslo?

Zunächst einmal wäre da die grundsätzliche Definition einer Entwicklungs-Umgebung und entsprechenden Tools, die eine modellgetriebene Software-Entwicklung ermöglichen sollen. Microsoft verfolgt hier den Ansatz des “neu erfindens”. Mit Oslo wird eine komplett neue Landschaft angeboten, statt bestehende Systeme zu erweitern.

Zum einen wäre da die “textuelle Modellierungssprache” M – M wie Modell. M ist natürlich keine klassische Programmiersprache, sondern dient der Beschreibung von DSL’s. Im Fokus ist nicht die Objektorientierung, sondern Daten- und Strukturorientierung. M hat eine Reihe von eigenen DSL’s (also Untertypen zu M), darunter MGrammar, um Grammatiken und Syntax für die eigene Textsprache zu definieren, MEntity um verhaltens- und modellbezogene Objekte zu modellieren, sowie MSchema, eine Sprache zur Definition von (relationalen) Datenstrukturen. Dariusz zeigte ein paar Beispiele mit dem neuen “Intellipad” (dem M-Editor), der schon seit einiger Zeit im Netz als das “Emacs.NET”-Gerücht verbreitet wurde.

Modellierung geht natürlich auch – oder besser primär – visuell. Dafür hat Microsoft einiges an Entwicklungsarbeit investiert und die neue Anwendung “Quadrant”. Quadrant ist so etwas ähnliches wie ein flexibler Diagramm-Designer. Die Flexibilität erreicht es zum einen über M selbst sowie auch über eigene “Meta-DSL’s”. Quadrant hat im wesentlichen eine Office-Style-Ribbon-Bar und eine “Workspace” genannte Zeichenfläche. Je nach definierten Modell oder DSL kann man verschiedene Entitäten und Objekte erstellen, auch neue Menü’s und der Kontext ist änderbar. Auf den ersten Blick sieht das Tool ganz nett aus – die Power, die in Quadrant stecken soll, konnte mir Dariusz in den 5 Minuten leider nicht ganz vermitteln.

Ein wesentlicher Teil von Oslo ist “Dublin”. Dublin soll eine Hosting Runtime für Oslo MDA’s werden. Realisiert als Erweiterung für den IIS ist es ein Quasi-Application-Server. Intern werkeln WCF & WF kräftig auf dem Metadaten-Modell und sollen die mit den Oslo-Tools entworfenen Anwendungen ohne weiteres Zutun ausgeführt und zur Verfügung gestellt werden können. Dublin selbst ist noch in der Entwicklung – mal abwarten, wie es am Ende aussehen wird.

Am Rande erwähnt wurde auch, das die gezeigten Oslo-Komponenten (also M und Quadrant) wohl auch irgendwie mit Visual Studio gekoppelt werden – natürlich noch nicht zum VS10er-Release, aber eine Integration sei in Planung.

Fazit: Oslo ist in einer noch sehr frühen Phase, deutet aber schon an, wie MDD in Zukunft aussehen kann. Danke Dariusz.

Session 2: Christian mit Rosario

“Rosario” ist der Codename der neuen Version von Visual Studio Team System / TFS. Wer schon heute mit VSTS mit TFS verwendet, der weiß, das da noch einiges an Platz für Verbesserung vorhanden ist. Das scheint auch Microsoft erkannt zu haben, wenn man den Worten von Christian glauben darf. Bei den Worten wollte er es natürlich nicht belassen und zeigte ein paar Slides und Demos zu den Verbesserungen.

Zunächst einmal werden Kernelelemente wie Skalierungsfähigkeit, Maintenance und das Build- bzw. SCCS-Management verbessert. Wie hinlänglich bekannt, ist Installation und Administration von TFS / VSTS ja keine besondere Meisterleistung von Microsoft. Mit Rosario soll laut Chrisitan TFS innerhalb einer halben Stunde installiert und konfiguriert werden können – da lehnt er sich meiner Meinung nach ziemlich weit aus dem Fenster – aber ich will nicht von vornherein darüber urteilen.

Für den Continuous Build wird Build Agent Pooling und das “Gated Check-In” integriert. Das “Gated Check-In” erlaubt einen serverseitigen Buildrun mit den Änderungen, die eingecheckt werden sollen. Das neue “Branch Management” ist eigentlich nichts anderes als ein Backtracking und eine Visualisierung der Branches auf dem SCCS. Diese Features sind bei der Konkurrenz (siehe z.B. TeamCity) z.T. schon lange Standard – wenigstens schließt hier Microsoft ein wenig auf.

Im Project Management Bereich soll das Reporting und Templating besser ausgebaut werden. Interessant ist die Integration der Kernelemente von Scrum, wie z.B. das Dashboard und Excel Listen für Product Backlog, Sprint Backlog, Sprint Planung, Burndown Charts oder die User Story Work Items. Die Beziehungen der Work Items zueinander wird in Rosarion weiter verbessert. Man kann eine komplette Hierarchie aufbauen, aber auch andere “Link Relations” setzen, wie z.B. Predecessor (Vorgänger) oder Dependency (Abhängigkeit). Auch die Organisation der einzelnen Projekte wird überarbeitet. Über die schon existierenden Team Projects sollen nun organisatorisch mit “Team Project Collections” ganze Anwendungsfamilien verwaltet werden können.

Für das Qualitätsmanagement sollen die Tools für das Unit Testing weiter verbessert werden. Interessant ist, das ein komplett neues “Test Quality Center” aufgebaut wird (Codename: Camano). Neue Features wie Test Impact Analyse, Test Suites und ein neuer “Test Plan Manager” sollen den Testalltag vereinfachen. Auch die Test Cases sind als Work Items gespeichert und können mit Changesets, Tasks und Requirements verbunden werden. Gut gelungen finde ich die Verwaltung der Test Cases mit Test Runs und Test Settings. Ziel dieser feinen Testorganisation soll die Eliminierung der “No Repro Bugs” sein.

Dieses Ziel wird vor Allem durch den neuen “Manual Test Runner” unterstützt, mit dem manuelle oder explorative Tests durchgeführt werden können. Besonders prickelnd: Die Tests können mit einem Test Recorder aufgenommen und automatisiert werden. Weitere Test Tracking Features sind die Videoaufnahme, Log Sampling und Umgebungsanalyse. Übrigens, der Test Recorder soll eine Reihe von UI-Typen unterstützen können, wie z.B. Windows Forms, WPF, die IE Engine und sogar die Firefox Gecko Engine. Ein Highlight beim Qualitätsmanangement ist das “Environment Provisioning”, mit dem eine virtuelle Testumgebung angeboten werden kann. Wie das eben so ist mit virtuellen Maschinen, sind Checkpoints und Flashbacks auf ältere Stände möglich.

Abschließend ging Christian noch auf die neuen Diagramme und Analyse-Möglichkeiten von VSTS 2010 ein. Standard UML die Use Case, Activitiy, Sequence und das bekannte Class Diagram sind nun in VS direkt umsetzbar. Es wird zusätzlich noch das “Laer Diagram” und ein “Architecture Explorer” angeboten. Das Layer Diagram soll eine Tiered Architecture widerspiegeln. Durh Verknüpfung der einzelnen Elemente mit Namespaces ist sogar eine automatische Validierung zur Einhaltung der Layer-Regeln möglich. Der Architecture Explorer ist die visualisierte Fortführung des Object Explorers. Ausgehend von einem “Bird-Eye View” kann man in die einzelnen Namespaces, Klassen und Methoden navigieren und sich besondere Konstallationen näher ansehen. Ein NDepend-Ersatz ist es bei weitem nicht, aber ermöglicht zumindest eine nette und schnelle Analyse.

Fazit: Die neuen Quality-, Test- und Diagramm-Features sind wirklich beeindruckend. Die Verbesserung von TFS ist längst überfällig. Vielversprechend!

Session 3: Nochmal Dariusz mit WCF & WF in .NET 4.0

Da bin ich nun wieder in einer Session mit Dariusz gelandet. Diesmal: WF & WCF in .NET 4.0. Wie immer zu Beginn ein Abriß der Themen. Generell wurde bei der Weiterentwicklung von WF und WCF an der Performance geschraubt. die Workflow Foundation Engine soll eine mindestens 10-fache Geschwindigkeitssteigerung erfahren haben. Doch nicht nur unter der Haube der WF wurde gewerkelt. Die API wurde verbessert, um noch einfacher mächtigere Activities entwickeln zu können. So werden mit 4.0 auch “Variablen” (besser: State Parameter) im Workflow unterstützt, die man relativ elegant mit den Klassen InParameter<T> und OutParameter<T> ansprechen kann.

Besonders hob Dariusz den komplett neu aufgebauten Designer von WF hervor. Er wird nun komplett in WPF umgesetzt, bietet dementsprechend eine ansprechende UI und ist vor Allem besonders gut anpassbar. Auch die Verwendung des Designers in eigenen Programmen (das sog. Rehosting) wird deutlich verbessert und vereinfacht.

Auf der WCF-Seite werden die QoS-Merkmale Konfiguration, Monitoring und Deployment weiter verbessert. Das eigentlich Neue ist aber die engere Verzahnung mit der Workflow Foundation. Zwar ist es schon jetzt möglich, eine WF-Anwendung per WCF in wenigen Schritten zur Verfügung zu stellen – doch ein weiterer Ausbau sei geplant. Diese “Vereinigung” hat auch einen höheren Sinn, nämlich die Entwicklung von Dublin (siehe auch Session 1: Oslo).

Fazit: Kurz & Knackig. Das Zusammenspiel von WCF & WF war hervorzusehen, die Neuigkeiten über WF hören sich gut an.

Session 4: Oliver Scheer über die Zukunft von ASP.NET

Die Zukunft von ASP.NET – das interessiert mich. Also auf zur letzten Session der Technical Summit mit Oliver Scheer. Nach 5 Minuten dachte ich mir: Ups – schon wieder eine Themaverfehlung? Denn Oliver gab ein Überblick über das, was er in einer Stunde zeigen möchte: ADO.NET Data Services, Dynamic Data Sites, ASP.NET MVC, ASP.NET AJAX und AJAX Control Toolkit. Toll – Wo ist JQuery, wo sind die neuen HttpHandler und -Modules, wo sind die MVC-Controls? Anscheinend nicht auf der Technical Summit. Naja – vielleicht zeigt Oliver ein paar Minuten noch neue Features für ASP.NET MVC.

Zunächst zeigte Oliver eine Demo von ADO.NET Data Services. Schön einfach über das Entity Framework die Tabellen zusammenklicken, den Data Service erstellen und die Configzeilen reinschreiben. Fertig. Nix Neues. Punkt.

So – jetzt mal endlich etwas neues für ASP.NET – ASP.NET MVC. Oliver beschreibt die Grundlagen und zeigt die bekannten Getting-Started-Samples. Er geht flüchtig auf die Konventionen ein und beschreibt sehr oberflächlich die Idee des MVC. So, noch kurz das Routing gezeigt und ein wenig erklärt. Ok. Nix Neues. Punkt.

Oh – Oliver holt aus zum nächsten Thema – ASP.NET Dynamic Data Websites. Ich wundere mich jedes Mal, wenn ich das sehe, wer zum Teufel im Alltag den Anwendungsfall für so eine Art Website hat. Es scheint wohl einige zu geben, sonst hätte man nicht so eine Art von Website-Projekt wohl nicht realisiert. Egal – ich jedenfalls kenne niemanden der sowas brauchen kann. Nix Neues. Punkt.

Zu guter Letzt noch ein Ausflug in ASP.NET AJAX und ein Verweis auf das AJAX Control Toolkit. Oliver zeigt wieder mal die gewohnte Extender-Demo. Ok. Nix Neues. Halt! Zu guter Letzt doch noch JQuery! Zu schade – nur ein Hinweis auf die Integration und die Auslieferung mit ASP.NET 4.0. Als Entschädigung dafür zeigt Oliver in seiner letzten Demo, das die neuen, von Microsoft geschriebenen JS-Klassen einen Aufruf von WCF Diensten ohne jegliches serverseitiges Zutun durchführen können. Ok. Wenigstens ein wenig Neu. Punkt.

Fazit: Nahezu Nix Neues. Punkt.

Eine Anmerkung noch: ich finde es wirklich sehr Schade, das gerade die zwei Sessions über ASP.NET für mein Dafürhalten so schwach ausgefallen sind. Man kann ASP.NET mögen oder nicht – aber auf einer Konferenz wie der Technical Summit ASP.NET derart zu vernachlässigen ist spricht nicht gerade für technologische Überzeugung.

That’s it

So, das war also die Technical Summit 08, so wie ich sie erlebt und verstanden habe. Ich denke jetzt muss ich erstmal die Infos und die ganze Veranstaltung noch auf mich wirken lassen und verarbeiten. Im Großen und Ganzen war es eine gute und z.T. sehr aufschlußreiche Konferenz. Das absolute Highlight war für mich die Parallels-Session mit Steve, dicht gefolgt von den beeindruckenden VSTS-Demos von Christian und der hochinteressanten Microsoft-MDD-Interpretation Oslo mit Dariusz.

• Oslo – Model Driven Development, Dariusz Parys
• Visual Studio 2010 (Codename Rosario), Christian Binder
• WCF & WF in .NET 4.0, Dariusz Parys
• ASP.NET Futures, Oliver Scheer

Die erste Session über Oslo habe ich schon hinter mir. Ein Log dazu gibt’s nach der Summit, es sei nur kurz erwähnt: interessante Abstraktionen! Mal sehen, wie die restlichen Sessions werden.

Session 1: Steve Teixeira über Multi-Core Software-Entwicklung

Steve Teixeira ist Program Manager beim Parallel Developler Tools / Visual Studio Team in Redmond und hatte in seiner Session neben der grundlegenden Einführung der neuen API für Multithreading auch einige Neuigkeiten über die nächste Visual Studio Version zu berichten. Doch alles der Reihe nach. Zunächst einmal schilderte Steve, wieso man sich eigentlich Gedanken über Parallele Ausführung von Code machen sollte. Der Grund ist natürlich bei der Hardware-Entwicklung vergraben, denn mittlerweile gelangt man an die Leistungsgrenzen im CPU-Design mit einem Kern. Der Hauptgrund ist die inzwischen fast unkontrollierbare Wärmeleistung, die die Chips von sich geben. Der Trend ist zu Multi-Core-CPU’s ist eindeutig auch im Alltag angekommen.

Das wiederum macht es erforderlich, die Software auf die neuen Gegebenheiten anzupassen. Steve zeigte ein schönes Beispiel mit Hilfe von PLINQ um die Unterschiede zwischen sequentiellem und parallelisiertem Code deutlich zu machen. Was heißt das für den “Alltags-Entwickler”, wie ich es z.B. bin? Nun, zunächst einmal bedeutet es eine Schärfung der Coder-Sinne auf das Thema Performance. Ich fühle mich zwar in diesem Thema schon heute gut aufgehoben, aber es dürfen ruhig noch ein wenig mehr Details sein.

Unterstützt wird dies im Besonderen durch das neue Visual Studio 2010. Es kommt mit neuen Tools wie Performance und Concurrency Profilern, die deutlich, graphisch anschaulich zeigen, wieviel Zeit die Software für bestimmte Aktionen verbraucht und mit welchen Ressourcen diese Leistung erreicht wurde. Auffällig dabei sind auch die Optionen, die das neue Performance-Tool bietet: CPU-basiertes Sampling, komplette Instrumentation, also Analyse aller Zeiten und Zyklen von Methodenaufrufen und das schon eben erwähnte Concurrency Profiling, mit dem man in der Lage ist zu erkennen, wie die Threads mit den Aufgaben ausgelastet sind.

Eine “Performance Debugging Suite” also, die im neuen Visual Studio verankert sein wird. Voraussetzung ist jedoch die Installation auf Windows Vista oder Windows 2008, da die Monitoring-Tools intern eng mit der seit Vista erweiterten Windows Eventing API (ETW) zusammenarbeiten.

Für so passionierte .NET-Entwickler wie mich ist die Verwendung der neuen API einfacher als erwartet. So lassen sich z.B. LINQ-Abfragen elegant mit dem “Anhängsel” .AsParallel() parallelisieren. Mindestens genauso einfach lassen sich auch Codebestandteile für die Parallel-Ausführung trimmen. Eine einfache for-Schleife ist mit Parallel.For() im Nu für die Parallelisierung umgesetzt. Die Nebeneinanderausführung von separaten Codeteilen mit Parallel.Invoke() ist zügig definiert und intuitiv. All diese Dinge sind fest im neuen .NET Framework 4.0 verankert. Interessant in diesem Zusammenhang ist, das Steve explizit auf deutliche Verbesserungen “unter der Haube” hingewiesen hat. So ist z.B. die ThreadPool-Klasse intern mit neuen Strategien wie dem Work Stealing ausgestattet worden, um die Verteilung der Aufgaben in Multi-Core Umgebungen zu optimieren.

Ein helles Ohr hatte ich auch bei den vielen kleinen Anekdoten und Anmerkungen von Steve. So ging er flüchtig auf die Entwicklung von Visual Studio ein und verriet, das der Visual Studio Code mehrheitlich in C++ und C# geschrieben ist und derzeit mehr als 45 Millionen Codezeilen umfasst. Interessant ist auch die Tatsache, dass das Visual Studio Team bei der Entwicklung von neuen Komponenten und UI verstärkt WPF im Einsatz hat. Steve begründet das mit der schlichten Tatsache, das WPF schnell genug ist und eine wesentlich effizientere UI-Entwicklung ermögliche als mit der klassischen GDI.

Fazit: Ein absolutes Highlight – Visual Studio 2010 in Aktion und Insider-Wissen. VS10, Parallels & .NET 4.0, ich warte auf euch…

Session 2: Holger Schwichtenberg und AJAX Services

AJAX ist nicht nur in aller Munde sondern heutzutage schon fast auf jeder Website in irgendeiner Form im Einsatz. Das man AJAX auch in ASP.NET einsetzen kann, ist spätestens nach dem .NET Framework 3.5 keine besondere Neuigkeit mehr. So auch der Inhalt der Session von Holger. Er machte einen knapp einstündigen Rundflug über die Möglichkeiten des AJAX-Einsatzes in ASP.NET, darunter das berüchtigte UpdatePanel (aka. AJAX für Arme), das AJAX Control Toolkit (aka. Atlas) und die kleinen Tools, die mit den ADO.NET Data Services einhergehen.

Auf AJAX-Spezifische News für .NET 4.0, den JQuery-Support mit ASP.NET 4.0 oder Visual Studio 2010 ging Holger garnicht oder nur am Rande mit einem Keyword aus einem Slide ein. Schade, aber aus meiner Sicht eine sehr schwache und fachlich “äußerst überschaubare” Session. Besonders die Argumentationen von Holger für so manche Technologie sind in meinen Augen etwas zu oberflächlich. So geschehen bei einer Frage eines Zuhörers:

Zuhörer: Bei den ADO.NET Data Services verzichten Sie auf eine gewohnte 3 bzw. N-Tier Architektur. Dies wurde lange als “Best Practice” vermittelt und nun wird das mißachtet. Was meinen Sie?

Schwichtenberg: Nun, ich sage Ihnen ja nicht, das eine N-Tier Architektur nicht empfehlenswert ist. Aber – mit ADO.NET Data Services ist der Betrachtungswinkel ein anderer. Während “klassische” Web Services nur die Daten und Funktionen herausgeben, die wirklich benötigt werden – also praktisch die Daten schon serverseitig Filtern – wird bei den ADO.NET Data Services zunächst der gesamte Datenbestand im Web Service angeboten. Der Client kann nun über die REST-Query entscheiden, was er konkret benötigt. Aus meiner Sicht ist diese Herangehensweise ein Produktivitätsgewinn.

Na, das ist ja eine feine Aussage! Sichereitsbedenken scheint Holger nicht zu haben, wenn er alle Daten frei verfügbar macht. Des Weiteren ist die Konstellation AJAX + ADO.NET Data Services + Entity Framework sehr wohl eine “Tiered Architecture”, Das Entity Framework löst den klassischen Data Layer ab. Die Data Servies können als “Business Layer” durchgehen (man kann ja selbst noch einiges dazu entwickeln und der Zweck eines “Data Providers” kann in meinen Augen auch als “Business” definiert werden). Zu guter letzt ist AJAX bzw. die Website die UI bzw. das Frontend. Naja, vielleicht habe ich es auch nicht richtig kapiert, was Holger damit gemeint hat.

Fazit: Eine der schwächeren Sessions, die fachliche Tiefe und vor Allem Neuigkeiten bzw. Best Practices vermissen ließ.

Session 3: Dariusz quatscht hessisch, und zwar “Windoos Äschär”

Der Name ist Programm: Dariusz wagt sich in die neue blaue Windows-Welt: “Windoos Äschär” – so meint er könnte man es zumindest versuchen, die neue Service-Familie auszusprechen. In wohl bekannter Manier stieg er fröhlich in die Thematik mit einem Überblick ein.

Da wären zunächst die .NET Services “Access Control”, “Service Bus” und “Workflow”. Der Access Control Dienst so etwas vergleichbares wie ein etwas besserer, Claims-basierter Single-Sign-On Service mit Authorisierungsmanagement. Über eine Claims-Challenge können sich Nutzer und Dienste gleichermaßen authentifizieren. Dabei kann man aus der gewohnten Variabilität der Authentifizierungsart wählen – ob nun UserNamePassword, Zertifikate, Windows Live ID – Claims bleibt Claims. Der Service Bus ist der aus größeren Unternehmen bekannte ESB portiert auf die “Cloud”. Mittelfristig soll mit dem Service Bus eine “orchestrierte” Gemeinde von Diensten zur Verfügung gestellt werden. Das Pattern ist jedenfalls nicht neu. Der dritte im Bunde ist der Workflow Dienst. Basierend auf der WF kann er als “Schaltzentrale” verwendet werden. Momentan ist dieser Baustein noch sehr rudimentär, soll aber weiter ausgebaut werden.

Eine weitere Service-Gruppe ist die “SDS” – die SQL Data Services. Gleich zu Beginn klärt Dariusz hier den Unterschied zwischen “Azure Storage” und den “echten” SQL Diensten. Während die Storage eher eine “einfache, sqlfähige Datenablage” ist, sollen die SDS mittel- bis langfristig wesentlich mehr Features anbieten wie z.B. Reporting, Data Mining oder ETL Dienste. Gewöhnungsbedürftig bei den SDS ist die Organisation der Daten: Man hat nicht mehr die klassischen, relationalen SCHEMA TABLE ROW Strukturen. Statt dessen befinden sich die Daten in sog. “Containern” (vergleichbar mit Datenbanken oder Schemata). Die Daten wiederum sind als “Entities” strukturiert. Eine Entity hat mindestens einen Typ (also den Entity-Namen), eine EntityID und den EntityKind, welche Aussage über die Art oder Klasse der Datenstruktur geben soll. Weitere Felder sind frei definierbar. Die Feldtypen beschränken sich derzeit nur auf einfache Datentypen.

Auf weitere Dienst-Gruppen ist Dariusz nicht eingegangen – wie sollte er auch – er hatte während der Session mit anderen Problemen zu kämpfen. Jede zweite Demo ging nicht oder brach mit irgendwelchen Exceptions ab. Tja, er musste selbst zugeben, das “Äschär” noch nicht ganz fertig ist und an der einen oder anderen Stelle die notwendige Reife für den produktiven Einsatz vermissen ließ.

Der erste Eindruck den Windows Azure und die “SOA-Diensten” hinterlassen ist das Interesse an Neuem mit einer großen Portion Skepsis. Auch wenn irgendwann einmal Azure stabil und schnell wird bleibt abzuwarten, ob die Plattform attraktiv und intuitiv genug ist, um echte Anwendungen darauf laufen zu lassen.

Fazit: Mal sehen was daraus wird!

Session 4: Dirk Primbs schreibt effizienten Code in C# 3.0

Dirk ist eines der bekanntesten Gesichter auf Konferenzen – kein Wunder, schließlich ist er seines Zeichens Developer Evangelist bei Microsoft. Die heutige Session hatte die Überschrift “Effizienter Code in C# 3.0″ – das hörte sich vielversprechend an. Also dachte ich mir, wenn ich schon nicht in die Session von Berndt gehen kann (er war leider nicht anwesend und wurde durch Dariusz vertreten), dann höre ich mir mal an, was Dirk mir über Effizienz mit C# 3.0 zu erzählen hat.

Leider war nicht ganz in dem Paket drin was draufstand. Dirk verbrachte über die Hälfte der Zeit damit, die Geschichte von .NET und C# zu erzählen. Angefangen bei C# 1.0, über C# 2.0 bis zum aktuellen C# 3.0. Die aktuelle 3.0-Version kam dabei für meine Begriffe viel zu kurz. Dirk vermittelte in seiner Retrospektive über C# 2.0 sehr gut, was Generics, Anonymous Methods und Discrete Property Accessors sind. Doch besonders prickelnd war es nicht gerade, mittlerweile gängige Konstrukte nochmals vorgekaut zu bekommen. Mit C# 3.0 hatte das wenig zu tun, und mit effizientem Code auch nicht.

Wahrscheinlich habe ich mir unter dem Titel “Effizienz” etwas anderes vorgestellt als Dirk. Er ging auf Syntax und “eleganten” Code ein, wo ich eher Effizienz-Vergleiche zwischen konkrekten und anonymen Typen erwartet hätte. Dennoch war es nicht langweilig – wer Dirk schon öfter erleben durfte, der weiß warum.

Es blieb am Ende doch noch eine gute Viertelstunde übrig, um auf neue Sprachkonstrukte und Features von C# 3.0 einzugehen. Type Inference und das var Keyword, Object Initializer und Automatic Properties. Wie zu erwarten war, wurde die Verwendung des var Keywords “angeregt” diskutiert. Ich hatte mich in einem Post ja schon über den Sinn und Zweck von var geäußert. Äußerst bedauernswert fand ich allerdings, das kein Sterbenswörtchen über C# 4.0, die DLR, das dynamic keyword oder Duck Typing verloren wurde. Zumindest ein Ausblick und ein kurzer Rundflug wäre schön gewesen.

Fazit: Eine Mischung aus “Basics Workshop”, Human FxCop und OpenSpace Talk – locker, bekömmlich, bekannt.

Soviel zum ersten Tag. Mal sehen, was der zweite bringt… :-)

Meine Session-Auswahl für den ersten Tag:

• Bringing out the best in Multicore Systems, Steve Teixeira
• AJAX-Live im Services Zeitalter, Holger Schwichtenberg
• Software-Entwicklung mit Windows Azure, Dariusz Parys
• Parallel Extensions für Microsoft .NET, Bernd Marquardt

Mal sehen, welche Erkenntnisse bis zum Abend gewonnen werden können.

Anfangs war ich vom Einsatz und den Möglichkeiten, die durch var entstehen sehr angetan. Ehrlich gesagt bin ich das heute noch. Aber mein Enthusiasmus ist doch deutlich gedämpft, jetzt wo ich es im Einsatz sehe und selbst einsetze. Mein “Problem” (wenn man das so überhaupt sagen kann) mit var ist nicht die Typ-Inferenz die es ermöglicht, sondern eher der zuweilen exzessive Einsatz.

Besonders betrübt bin ich, wenn ich z.B. in populären Blogs wie dem von Jeff Adwood lesen muss, das var das Allheilmittel schlechthin ist und so oft wie nur irgendmöglich eingesetzt werden sollte. Bei solchen Aussagen liegt bei mir die Vermutung nahe, das Jeff gerade nicht sehr große Projekte in C# stemmt. Schließlich wurde var nicht erfunden um die Deklarations- bzw. Konstruktionssyntax in C# zu verschönern, sondern dient einem dedizierten Zweck.

Umso erfreulicher ist es, das ich mich mit meiner Meinung in bester Gesellschaft vorfinde. So erklärt z.B. Richard sehr gut, das es beim var Keyword nicht um die Verkürzung von Codezeilen geht sondern bei exzessivem Einsatz eher in die Kategorie Programmierfaulheit einzustufen ist. Ich persönlich befürworte vollständig seine Meinung, wonach var dort eingesetzt werden sollte, wo es benötigt wird, und nicht überall wo es möglich ist.

Setzt man var überall ein, wo es möglich wäre, kommt solcher Code zustande:

public object GetMatchingCode(object[] codes, string matchPattern, bool ignoreInvalid)
{
  var bestMatch = FindBestMatch(matchPattern);
  var blackList = codelists.GetBlackList(codes);

  foreach(var c = in blackList.GetConfirmedCodes())
  {
    var matchPoint = bestMatch.CompareCode(c, ignoreInvalid);
    matchPoint.Combine(c.ParentCode);
    if (matchPoint.IsUnique(bestMatch)) return matchPoint;
  }

  return null;
}

Du als Leser dieser Codezeilen hast kein Visual Studio und keine Intellisense. Weißt Du, worum es bei diesen Codezeilen eigentlich geht? Ich wüßte es jedenfalls nicht.

Zugegeben, das Beispiel mag überspitzt sein. Jedoch übertreibe ich nicht, wenn ich sage, das ich “echten” Code schon lesen (und verstehen) musste, der mindestens den gleichen Grad von “konsequentem var Einsatz” aufwies wie obiges Beispiel.

Auf der anderen Seite ist var natürlich auch notwendig und äußerst sinnvoll. Die Paradedisziplin dabei ist sicherlich LINQ:

var persons =
  from customer in db.Customers
  where customer.State = 1
  select new { Id = customer.Id, Name = customer.Name };

Ich für meinen Teil finde var und Typ-Inferenz eine gelungene, sogar notwendige Bereicherung in C# – aber nur dort, wo es wirklich gebraucht wird. Obwohl Soren in seinem Blog mit “the C# keyword var is evil” sicherlich übertreibt, ist es eine besonders empfehlenswert seinem Beispiel zu folgen und die geradezu unsinnige “Benutze immer var”-Funktion im ReSharper einfach abzuschalten.

Mein Fazit: var ist nur dann cool, wenn ich es wirklich brauche – ansonsten bleibe ich bei expliziter Typdeklaration und dem mächtigen Visual Studio Intellisense/Autocomplete.

public class AType
{
  private static readonly CType c;
  private static readonly ReaderWriterLock locker = new ReaderWriterLock();

  static AType()
  {
    locker.AquireWriterLock(Timeout.Infinite);

    try
    {
      c = BType.CreateCType();
    }
    finally
    {
      locker.ReleaseWriterLock();
    }
  }
}

Kaum hatte ich den Konstruktor auf dem Schirm gezeigt, kam unisono ein Kommentar der Reviewer: “Das Locking im statischen Konstruktor ist überflüssig, der statische Konstruktor gewährleistet die threadsichere Ausführung schon durch implizites Locking”.

Tatsächlich ist es so, das im obigen Beispiel das Locking im Typinitialisierer (statischer Konstruktor) über den ReaderWriterLock quasi überflüssig ist, denn das .NET Framework (genauer die CLR) gewährleistet, dass

• Typinitialisierungen nur ein einziges mal pro Typ aufgerufen werden, und
• Typinitialisierungen innerhalb eines Threads bis zur Vollständigkeit ausgeführt werden.

Konsequenterweise lässt sich das obige Beispiel damit auch wesentlich einfacher formulieren:

public class AType
{
  private static readonly CType c;

  static AType()
  {
    c = BType.CreateCType();
  }
}

Im Code Review musste ich zugeben, das mein initialer Code etwas zuviel des Guten gewesen ist. Ein Physiker, der auch am Code Review teilnahm, kommentierte den Code folgendermaßen: “Es ist eigentlich unnötig, aber schaden kann es nicht”. Diese Aussage hat mich zum Grübeln gebracht – und damit zu der Analyse, ob das Locking innerhalb des statischen Konstruktors wirklich überflüssig ist oder nicht.

Test 1: Typinitialisierung wird nur einmal und in einem einzigen Thread ausgeführt

Zunächst einmal wollte ich überprüfen, ob es tatsächlich so ist, das der statische Konstruktor nur einmalig von einem Thread aus aufgerufen wird. Dazu habe ich ein einfaches Testprogramm geschrieben:

public class Foo
{
  static Foo()
  {
    Console.WriteLine("Begin Foo .cctor on thread {0}", Thread.CurrentThread.Name);
    Thread.Sleep(5000);
    Console.WriteLine("Exit Foo .cctor on thread {0}", Thread.CurrentThread.Name);
  }

  public static void Message()
  {
    Console.WriteLine("Foo on thread {0}", Thread.CurrentThread.Name);
  }
}

public class Program
{
  static void Main(string[] args)
  {
    ThreadStart ts = new ThreadStart(() => Foo.Message());

    for (int i = 0; i < 10; i++)
    {
      Thread t = new Thread(ts);
      t.Name = String.Format("Thread {0}", i);
      t.Start();
    }

    Console.ReadKey();
  }
}

Im statischen Konstruktor der Klasse Foo wird 5 Sekunden gewartet, bevor die Initialisierung fertiggestellt wird. Die Message()-Methode von Foo wird von 10 separaten Threads aufgerufen - also 10 Threads, die potenziell eine Typinitialisierung durchführen könnten. Führt man das Testprogramm aus, so stellt man in der Tat fest, das der statische Konstruktor nur ein einziges Mal aufgerufen wird. Alle anderen Threads, die den Typ benötigen, sind so lange blockiert, bis die Ausführung des Konstruktors beendet wurde.

Fazit Test 1: Der Typinitialisierer (statische Konstruktor) wird nur ein einziges Mal von einem einzigen Thread pro Typ ausgeführt.

(Anmerkung: Das gilt natürlich nur "pro AppDomain", denn die Deklarationskontexte von zwei AppDomains sind voneinander getrennt.)

Test 2: Typinitialisierung von generischen Typen

Als nächstes war es für mich von Interesse zu untersuchen, wie sich die Typinitialisierung bei speziellen Typen, nämlich den generischen Typen verhält. Auch dafür habe ich ein kleines Testprogramm geschrieben:

public class Foo<T>
{
  static Foo()
  {
    Console.WriteLine("Begin Foo .cctor on thread {0}", Thread.CurrentThread.Name);
    Thread.Sleep(5000);
    Console.WriteLine("Exit Foo .cctor on thread {0}", Thread.CurrentThread.Name);
  }

  public static void Message()
  {
    Console.WriteLine("Foo on thread {0}", Thread.CurrentThread.Name);
  }
}

public class Program
{
  static void Main(string[] args)
  {
    ThreadStart ts1 = new ThreadStart(() => Foo<string>.Message());
    ThreadStart ts2 = new ThreadStart(() => Foo<int>.Message());
    ThreadStart ts3 = new ThreadStart(() => Foo<double>.Message());

    ThreadStart[] tsx = new ThreadStart[] { ts1, ts2, ts3 };

    for (int i = 0; i < 10; i++)
    {
      Thread t = new Thread(tsx[i%3]);
      t.Name = String.Format("Thread {0}", i);
      t.Start();
    }

    Console.ReadKey();
  }
}

Im Endeffekt ist das obige Testprogramm nur eine kleine Variation des ersten Testprogrammes. Statt der Klasse Foo gibt es nun eine Klasse Foo<T>. Wieder werden 10 Threads zum Aufruf der Message()-Methode angeworfen, allerdings mit 3 unterschiedlichen Typinstanzen, also Foo<string>, Foo<int> und Foo<double>.

Führt man dieses Programm nun aus, stellt man fest, dass der statische Konstruktor des generischen Typs Foo<T> 3 Mal aufgerufen wird, und das sogar von 3 unterschiedlichen Threads! Wieso?

Die Erklärung liegt in der "Implementierung" (besser der Definition) von generischen Typen. Eine Typinstanz Foo<AnyType> wird vom Compiler als eigenständiger Typ emittiert und damit von der CLR als eigenständiger Typ verstanden. Demzufolge ist es durchaus valide, das der statische Konstruktor des generischen Typs 3 Mal (von 3 verschiedenen Threads) aufgerufen wird, denn es sind ja schlußendlich 3 verschiedene Typinstanzen des generischen Typs, die verwendet werden.

Das ist in vielen Fällen kein besonderes Problem, kann aber in besonderen Fällen doch problematisch werden. Ein Beispiel wäre eine Initialisierung oder ein Zugriff eines statischen Feldes einer Oberklasse (Basistyps) von Foo<T>.

Fazit Test 2: Der Typinitialisierer (statischer Konstruktor) von generischen Typen kann mehrfach von unterschiedlichen Threads aufgerufen werden (wobei gilt: pro Typinstanz nur einmal) und ist damit mit besonderer Sorgfalt zu implementieren.

Test 3: Typinitialisierung bei Deadlock-Szenario (gegenseitige Blockade)

Nach dem zweiten Test war mir klar geworden, dass statische Konstruktoren mit Vorsicht zu genießen sind. Diese Erkenntnis führte mich zum dritten Test. Ich wollte untersuchen, wie die Typinitialisierung reagiert, wenn es zu einem Deadlock-Szenario kommt. Was passiert also, wenn zwei Threads zwei unterschiedliche Typen initialisieren, wobei sich deren Initialisierung untereinander bedingt? Ein weiteres Testprogramm soll diese Frage klären:

public class Foo
{
  private static string text = "blank Foo";

  static Foo()
  {
    Console.WriteLine("Begin Foo .cctor on thread {0}", Thread.CurrentThread.Name);
    Thread.Sleep(5000);
    Console.WriteLine("Foo needs message from Bar: \"{0}\"", Bar.Text);
    text = "Hello From Foo";
    Console.WriteLine("Exit Foo .cctor on thread {0}", Thread.CurrentThread.Name);
  }

  public static void Message()
  {
    Console.WriteLine("Foo got message from Bar: \"{0}\" on thread {1}", Bar.Text, Thread.CurrentThread.Name);
  }

  public static string Text
  {
    get { return text; }
  }
}

public class Bar
{
  private static string text = "empty Bar";

  static Bar()
  {
    Console.WriteLine("Begin Bar .cctor on thread {0}", Thread.CurrentThread.Name);
    Thread.Sleep(5000);
    Console.WriteLine("Bar needs message from Foo: \"{0}\"", Foo.Text);
    text = "Hello From Bar";
    Console.WriteLine("Exit Bar .cctor on thread {0}", Thread.CurrentThread.Name);
  }

  public static void Message()
  {
    Console.WriteLine("Bar got message from Foo: \"{0}\" on thread {1}", Foo.Text, Thread.CurrentThread.Name);
  }

  public static string Text
  {
    get { return text; }
  }
}

public class Program
{
  static void Main(string[] args)
  {
    Thread t1 = new Thread(new ThreadStart(() => Foo.Message()));
    t1.Name = "Thread 1";

    Thread t2 = new Thread(new ThreadStart(() => Bar.Message()));
    t2.Name = "Thread 2";

    t1.Start();
    t2.Start();

    t1.Join();
    t2.Join();

    Console.ReadKey();
  }
}

Im Programm werden zwei Typen durch die Klassen Foo und Bar definiert. Deren statische Konstruktoren enthalten einen Aufruf zum anderen Typ - Foo greift auf Bar.Text zu und Bar auf Foo.Text. Durch die eingebaute Wartezeit (Thread.Sleep) werden beide Threads für die Initialisierung reichlich Zeit haben. In letzter Konsequenz wird also der erste Thread darauf warten, das der zweite mit der Konstruktion des zweiten Typs fertig ist. Dieser aber bedingt, das der erste Typ konstruiert ist, welches ja beim ersten Thread noch auf Vervollständigung wartet. Beide Konstruktionen bedingen sich, es entsteht eine gegenseitige Blockade - der Deadlock.

Beim Ausführen des Testprogrammes kann es sein, das man seinen Augen kaum trauen wird. Denn beide Typen werden erfolgreich initialisiert und das Programm komplett ausgeführt - es kommt zu keinem Deadlock, obwohl es doch theoretisch zu einem Deadlock kommen muss. Wieso?

Die Antwort liegt in den Tiefen der CLI - denn zur Laufzeit des Programmes kommt es tatsächlich zu einem Deadlock. Jedoch ist die CLI so klever und erkennt das. Nach der Erkennung des Deadlocks löst die CLI eigenständig das Locking eines der beiden Threads auf, um somit die Vervollständigung der Typinitialisierung zu ermöglichen. Die Runtime macht das nicht aus Spass, sondern weil es eine Durchführung der Typinitialisierung garantieren muss.

Das Resultat einer solchen Garantie ist eine mögliche Fehlinformation innerhalb des statischen Konstruktors - und damit auch eine mögliche Fehlfunktion. Um diese potenzielle Fehlerquelle zu verhindern, müsste man tatsächlich innerhalb des statischen Konstruktors nochmals ein explizites Locking durchführen. Damit würde man den Deadlock regelrecht erzwingen. Ob man das möchte, hängt davon ab, welche Situation erstrebenswerter ist: Entweder man akzeptiert das geringe Risiko das bei der gegenseitigen (meist indirekten) Abhängigkeit seltene "komische Verhaltensweisen" des Programms auftreten, oder man möchte bei einer gegenseitigen Blockade, dass das Programm komplett einfriert.

Fazit Test 3: Voneinander abhängige statische Konstruktoren führen nicht zu einem Deadlock, können aber Fehlkonstruktion und Fehlverhalten nach sich ziehen.

Schlußfolgerungen und Konsequenzen

Die Ergebnisse der Tests sind (zumindest für mich) sehr aufschlußreich. Zu erkennen ist, das die Typinitialisierung in .NET einen ganz besonderen Stellenwert einnimmt. Auf Grund der Besonderheiten bei der Typinitialisierung ist es unbedingt erforderlich, auf die Umgebung und die Laufzeit-Bedingungen näher einzugehen, bevor man die Implementierung eines statischen Konstruktors für eine Klasse durchführt.

Die Tests haben gezeigt, das prinzipiell eine Typinitialisierung nur einmal von einem einzigen Thread pro Typ ausgeführt wird. Es gilt weiterhin, das die Ausführung des statischen Konstruktors threadsicher ist und auf jeden Fall vervollständigt wird - sogar bei gegenseitiger Blockade zweier Typinitialisierungs-Routinen.

Es ist zudem feststellbar, das es unter bestimmten Voraussetzungen dennoch zu einer mehrfachen Ausführung der statischen Initialisierungsroutine kommt, mitunter sogar von unterschiedlichen Threads zu beinaher gleichen Zeit. Dies ist im Besonderen bei statischer Konstruktion von generischen Typen der Fall.

Für mein Eingangs erwähntes Beispiel (der seltsame statische Konstruktor im Code Review) haben diese Erkenntnisse insofern eine Bedeutung, als das die Aussage des Physikers im Code Review bestätigt werden kann: Das explizite Locking im statischen Konstruktor ist eigentlich unnötig, schaden kann es dennoch nicht. Wäre die gezeigte Klasse eine generische gewesen, so wäre das explizite Locking u.U. vertretbar und notwendig gewesen. Da dem nicht so ist, ist es der Korrektheit halber wohl besser, das unnötige Locking rauszunehmen, was ich wohl auch tun werde.

Fazit: Die Typinitialisierung in .NET ist mit einigen Besonderheiten ausgestattet, die man in unter gegebenen Umständen (generische Typen, Multithreading) besonders beachten muss. Für die meisten Anwendungsfälle ist dies jedoch nicht nötig, da die CLR viele interne Maßnahmen ergreift, um eine sichere Typinitialisierung zu gewährleisten - in diesem Sinne: ziemlich de Luxe!

Anbei: Source-Code der Testprogramme (VS 2008, .NET 3.5, ZIP, 12kB)

Aber es gibt Neuigkeiten, denn in jüngster Zeit ist wieder ein wenig Bewegung in das Thema Unit Testing mit .NET gekommen. Das liegt vor Allem an der Veröffentlichung von C# 3.0 / .NET Framework 3.5. Neue Tools wie MoQ, Autofac oder XUnit.net bringen frischen Wind in die Unit-Test-Bude.

Ich habe mich, auch auf Grund der Aktualität in meinem Umfeld, mal näher mit o.g. neuen Tools beschäftigt. Meine daraus gewonnenen Erkenntnisse und Erfahrungen habe ich im Works-Bereich festgehalten:

Unit Testing Revisited – Die Unit Test Evolution mit C-Sharp 3.0 ist ein Artikel über das Unit Testing unter Einsatz von MoQ und Autofac. Für die Code Samples musste natürlich wieder das berühmt-berüchtigte “Calculator”-Beispiel herhalten.