CCD Reflektion – Roter Grad Tag 4

Gestern kam ich endlich wieder zum Programmieren; und das sowohl beruflich als auch privat.

Bei meinem derzeitigen beruflichen Projekt, der Erweiterung eines vor Jahren von mir erstellten Reporting Tools, konnte ich meine ersten “richtigen” Erfahrungen mit LINQ sammeln und habe dadurch den Input zum heutigen Post erhalten.

Eigentlich beginnt es damit, dass ich den Gedanken, meine vorhandene Datenbankstruktur mit NHibernate zu mappen, aufgegeben habe. Einerseits stand da Zeitdruck dahinter, da ich gewisse Meilensteine zügig erreichen muss, zum Andern musste ich erkennen, dass ich bei einem vollständigen DB-Schema fast zwangsläufig in einem “anemic model” Ende, dass lediglich eine DTO-Schicht über der Datenbank darstellt.

Also habe ich die Umstellung auf ein ORM verschoben. Mittelfristig muss das Modell sowieso komplett umgebaut werden und das ist der geeignete Zeitpunkt, ein Klassenmodell als Ursprung aller Modelle zu verwenden.

Bis dahin muss ich aber trotzdem auf die Daten zugreifen. Ursprünglich hatte ich den Datenzugriff über DataSets realisiert, aber genau diesen Ansatz will ich ablösen. Nacktes ADO.NET (DataReader und Commands) will mir auch nicht recht gefallen, also habe ich alle Tabellen mit Hilfe des VS-Designers in Linq2Sql erstellt.

Vom Ergebnis bin ich hin und her gerissen. Der Code, den auf Basis diesen Ansatzes erstellen konnte, ist kurz und gut lesbar. Beim Bereitstellen der Daten für das Reporting ist der Abgleich von Daten aus verschiedenen Quellen eine Hauptanforderung und Linq2Objects liefert hier mächtige Werkzeuge an die Hand.

Andererseits ist die Vermengung von Linq2Objects und Linq2Sql wiederum sehr komplex und durch die Kopplung an die Datenbank fast unmöglich isoliert zu testen.

Was ist also mein Fazit zu Linq? Linq2Objects ist sehr mächtig und erlaubt effektiv funktionales Programmieren in C#.

Auf Datenbanken werde ich mit Linq in Zukunft aber nur sehr isoliert zugreifen. Hier meine ich vor allem den Ansatz, Repositories zu benutzen, damit es möglich ist, den Datenzugriff in Tests durch Stubs oder Mocks zu simulieren.

CCD Status

Vielleicht lesen einige dieses Blog und fragen sich, ob ich nicht mehr über CCD blogge…

Tatsache ist, dass ich gestern und heute nicht zum Programmieren kam. Andere Prioritäten haben Vorrang, also momentan kein Development und kein CCD.

CCD Reflektion – Roter Grad Tag 3

Mein Arbeitstag war heute relativ ruhig, aber auf der Heimfahrt habe ich noch einen Issue von ActiveRecord abgearbeitet. Dabei bin ich auf die Grenzen der Prinzipien gestoßen.

Es geht um diesen Code:

if (model.HasManyAtt.RelationType == RelationType.Map && model.HasManyAtt.Index == null)

{

    throw new ActiveRecordException(String.Format(

                                        "A HasMany with type Map requires that you specify an 'Index', use the Index property {0}.{1}  ",

                                        model.Property.DeclaringType.Name, model.Property.Name));

}

if (model.HasManyAtt.RelationType == RelationType.List && model.HasManyAtt.Index == null)

{

    throw new ActiveRecordException(String.Format(

                                        "A HasMany with type List requires that you specify an 'Index', use the Index property {0}.{1}  ",

                                        model.Property.DeclaringType.Name, model.Property.Name));

}

Das erste if-Statement war bereits vorhanden, dass zweite ist durch Copy/Paste entstanden. Ich war nun wirklich im Zweifel, ob ich nicht eine private Methode extrahieren soll.

Ich habe mich dagegen entschieden. Es handelt sich um zwei Statements, die ich durch einen Aufruf ersetzen könnte, und dass auch nur, wenn ich die Prüfung in einer Lambda-Expression vornehmen. Da die Klasse sowieso über 20 Methoden hat, hätte die Auslagerung die Lesbarkeit eher verringert als erhöht.

Also habe ich heute gegen DRY verstoßen und (meiner Meinung nach) trotzdem richtig gehandelt.

Ach ja, mein virtuelles Armband trage ich immer noch rechts und habe einen Issue für das Refaktorisieren der semantischen Prüfungen eröffnet.

CCD Reflektion – Roter Grad Tag 2

Dieser Bericht kommt etwas später, da ich gestern keine Zeit hatte, einen Post zu verfassen. Die Reflektion habe ich schon durchgeführt, nur eben ohne Keyboard unter den Fingern.

Zunächst hatte ich mir nur vorgenommen, meine Commitrate weiterhin hoch zu halten, aber im Laufe des Tages wurde DRY ein Thema. Meine Haupttätigkeit war das Erstellen eines Modells für die Persistenz mit NHibernate.

Das hört sich zunächst nach einer relativ schwierigen Tätigkeit an, um DRY zu verletzen. Wäre es auch, wenn da nicht die Tests wären: Ich teste jede Klasse grundsätzlich, ob alle (halb-)öffentlichen (public und protected) Properties persistiert werden, um auszuschließen, dass eine Property beim Mapping vergessen wurde.

Diese Tests gleichen sich bei den Klassen strukturell sehr stark:

1. Objekt erzeugen
2. Objekt persistieren
3. Id auslesen
4. Objekt aus Session-Cache entfernen
5. Objekt mit Id erneut laden
6. Die Objekte Property für Property per Reflection vergleichen

Bei der ersten Klasse habe ich das so geschrieben, bei der zweiten kopiert, gepastet und … nachgedacht: Da war doch was. So schnell kann man in die Clipboard-Falle gehen.

Also habe ich den Test in eine generische, abstrakte Basisklasse ausgelagert. Die einzige Operation, die bei jeder gemappten Klasse unterschiedlich ist, ist das Erzeugen des zu speichernden Objekts. Aber dafür gibt es schließlich abstrakte Methoden.

Was habe ich dadurch gewonnen? Schließlich ist es nur Testcode… ;-)

Spass beiseite, ich bin der Meinung, dass auch auf Testcode die ganze Breitseite von Clean-Code-Techniken angewandt werden muss. Schließlich sind zumindest bis zur Produktivnahme die Tests der am häufigsten ausgeführte Code der Anwendung.

Zumindest wenn man TDD und CI verwendet…

CCD Reflektion – Roter Grad Tag 1

Wie in meinem vorherigen Post versprochen, habe ich mir ein virtuelles rotes Armband übergestreift und begonnen, bewusst auf die Einhaltung der CCD-Prinzipien zu achten. Allerdings nicht nach dem Gießkannenprinzip; dafür sind mir die meisten Techniken und Ideale bereits zu sehr in Fleisch und Blut übergegangen. Stattdessen habe ich mir einen einzelnen Punkt ausgesucht, den ich am heutigen Tag besonders beachtet habe: Die Nutzung des Versionskontrollsystems.

Ich nutze ausschließlich Subversion, also ein zentrales VCS. Mit der Zeit habe ich das regelmäßige Committen immer mehr schleifen lassen. Die Ursache kann ich nur erraten, aber ich denke, dass es mit meiner Arbeit am Castle-Projekt zu tun hat. Ich mache diese Arbeit fast immer offline und kann daher nur selten meine Änderungen committen. Dazu kommt, dass der Castle-Build auf meinem Laptop mehr als 10 Minuten dauert.

Das hat sich auf meine Arbeit übertragen, wo ich diese Probleme eigentlich nicht habe. Dennoch kam ich dort auch nur auf im Schnitt 2 Commits im Monat. Also höchste Zeit, aus dem Trott herauszukommen.

Mein Ziel war also, nicht nach jedem neuen Feature/User-Story, sondern (viel) öfter zu committen. Obgleich ich es (eigentlich) übertrieben finde, habe ich heute also nach jedem TDD-Zyklus committed.

Warum so oft? Damit der Commit genauso natürlich wird wie das Starten der Unit Tests, des lokalen Builds und das Holen von Kaffee. Nach unten wird sich die Commitrate wahrscheinlich von alleine regulieren. Und wenn nicht, ist es auch nicht schlimm… :-)

Fazit .Net OpenSpace Süd 2009

Letztes Wochenende war der .Net OpenSpace Süd in Blaustein bei Ulm. Es war mein erster OpenSpace überhaupt und ich fand es klasse, auch wenn es zu wenig Schlaf gab…

Zu den Slots, die ich besucht habe, gibt es noch ein paar Dinge zu ergänzen, was ich in den nächsten Wochen hier tun werde.

Ansonsten werde ich schauen, wann es wieder Events gibt. Leipzig wohl eher nicht, sondern kleinere Treffen, vielleicht in Köln oder Frankfurt.

Halt: Was ist denn nun mein Fazit?

Hmm…am ehesten, dass auch die “Community-Helden*” nur mit Wasser kochen. Wenn man sich das vor Augen hält und immer neuen Input sucht, kann man auch diesen Level erreichen.

*u. a. Stefan und Albert und die ganzen MVPs

Clean Code Developer

Eine der ersten Folgen aus dem OpenSpace ist für mich, erneut über das Thema Clean Code Developer nachzudenken. Interessiert hat mich das Thema bereits vorher, aber ich bin kein Freund von Plastikarmbändern…

Viele der in CCD verankerten Prinzipien setze ich bereits um, aber ich werde natürlich auch im roten Grad anfangen. Dies hat einen einfachen Grund: ich will mich mit den Prinzipien und Techniken bewusst beschäftigen. Die meisten der im roten Grad angesprochenen Punkte laufen nebenher und werden im täglichen Doing nicht beachtet; und obwohl man sich doch “sowieso” an DRY hält, findet sich der Finger dann doch auf STRG+V wieder…

Also zurück zu den Plastikarmbändern: nein, ich mag immer noch keins tragen. Um meinen Fortschritt festzuhalten, werde ich stattdessen hier im Blog öffentlich reflektieren und meine durch bewusste Beschäftigung mit den Themen erlangten Erkenntnisse veröffentlichen.

Blog reaktiviert

Nach dem .Net OpenSpace Süd letztes Wochenende habe ich mich entschlossen, zusätzlich zu meinem englischen Blog wieder ein deutsches Blog zu führen.

Hier sind wir also. Nach über 1,5 Jahren wieder mal ein deutscher Post von mir.