.NET Open Space 2010 (Leipzig) Review

Vom 16. bis 17.10. fand das diesjährige Leipziger .NET Open Space statt. Insgesamt fand ich es auch diese Jahr wieder gut. Ich besuchte es in meiner Freizeit, aber mein Arbeitgeber zahlte die Reisekosten. Für .NET Softwareentwickler, wie ich einer bin, ist das .NET Open Space eine interessante (Un-)Konferenz, bei der man viele neue Ideen und Eindrücke bekommt, und sich mit anderen aus der Branche austauschen kann. Ich will hier von meinen Eindrücken berichten, wobei sie aus der Sicht unserer Firma (teamaton) sind.

Gegliedert war das Open Space in Sessions – fünf an jedem Tag. Die Teilnehmer schlugen selbst die Themen vor Ort vor. Leider verliefen sich die Massen am Sonntag Nachmittag recht früh, so dass die letzten Sessions zum Teil ausfielen. Hier das, was ich aus den Sessions mitgenommen habe:

Agile Development

Es wurde viel darüber diskutiert, was denn eigentlich agil bedeutet. Dabei wurde auf das Agile Manifest eingegangen. Viele berichteten, wie es bei ihnen in der Firma eingeführt wurde, und worauf man dabei achten sollte. Es wurde deutlich, dass in vielen Abteilungen zwar von Agilität gesprochen wurde, aber die Leute noch weit von agiler Entwicklung entfernt sind. Betont wurde, dass Agile Softwareentwicklung vor allem eine Einstellungssache ist, und Transparenz sehr wichtig ist.

Ich selbst will mir SCRUM, XP (Extreme Programming) und Crystal Clear genauer anschauen. Das sind Prozesse und Richtlinien, die Agiles Entwickeln unterstützen. Mal schauen, was wir an unseren bisherigen, größtenteils agilen Prozessen verbessern sollten.

GIT Workflow

In dieser Session ging es darum, wie man Branches und Merges in GIT sinnvoll einsetzt. Es wurde ein Model vorgestellt. Um dieses Model effizient umzusetzen gibt es eine Software, git flow. Das Model hat mich überzeugt. Ich denke, ich werde git flow mal ausprobieren, und auch das Branching wie in dem Model gestalten. Das hat viele Vorteile für Entwickler, Tester und Deployer.

Testen

Hier wurde sehr viel darüber gesprochen, was eigentlich getestet werden sollte. Wann testet man zuviel, wann zu wenig?

Mir haben sich aus dieser Session heraus einige Fragen ergeben: Brauchen wir ein BDD-Framework? (Viele meinten BDD-Frameworks seien zu kompliziert. Ich denke, wir brauchen vorerst keins.) Sollte man nur Verhalten testen? Testen wir zuviel? Was sollten wir testen? Brauchen wir Mocking? Zudem will ich mir Gabriel Schenkers Screencast anschauen.

Tools & AddIns

Hier wurden viele nützliche Tools vorgestellt – ich habe mir notiert, was ich mir mal anschauen will:

• emaroo (most recently used …)
• SQLCop (Analyse von SQL-DBs – Fehler, Best Practice)
• Toolssession des Open Space in Karlruhe
• Zeichnen, Mockups: Balsamiq, SketchFlow, Pencil (Firefox)
• Screenshots: Snagit, Fasstone Capturer, Screenpresso (nutze ich)
• Videocapturing: Expression Encoder Screencapture 4
• evernote
• statt radmin oder Teamviewer: SharedView, Mikogo
• für Windows XP (habe ich noch zu Hause): launchy, ultramon
• ich sollte endlich man das normale Notepad durch Notepad++ ersetzen
• für Filestorage könnten wir auch Windows Live Skydrive nutzen (25GB, aber kopieren ist nicht so einfach wie bei dropbox)
• xsd2code (.NET Klassen aus xml generieren)
• Paint.NET (Bildbearbeitung)

Visual Studio besser nutzen lernen:

• Snippets
• Extensions (siehe Extensions Manager oder VS Gallery (online)):
  • CodeRush (guter Code)
  • EditorGuidelines (guter Code)
  • NuPack (Referenzen als Pakete hinzufügen, damit es keine Versionsprobleme bei Referenzen gibt)
  • Productivity Power Tools (z.B. Solution Navigator)
  • SnippetDesigner (es. ex. wohl auch jQuery-Snippets)
  • Typemock TestLint
  • ZippyChirpy (css-Dateien minimieren)
• .NET Reflector

DRY ums Verrecken?

In dieser Session wurde viel über Codeduplikation diskutiert. Sollte man knallhart an dem Prinzip festhalten und nie Code duplizieren? Oder ist es in bestimmten Bereichen ok, ähnlichen Code mehr als ein Mal zu haben?

Konsens war, dass man bei Tests nicht auf DRY achten sollte, sondern lieber die Tests einfach lassen. Bei Algorithmen sollte man auf DRY achten. Insgesamt sollte man abwägen, wie oft der Code wahrscheinlich noch angefasst wird (viele waren sich einig, dass bestehender Code bei neuen Anforderungen nach einem Jahr sowieso neu geschrieben wird). Und wie aufwendig die Anwendung von DRY wäre. Dann sollte man entscheiden, ob man den Code abstrahieren sollte, um ihn an verschiedenen Stellen einzusetzen.

DDD (Domain Driven Design)

Hier wurde um die Schwierigkeiten geredet, verschiedene Sichten (z.B. User und Admin) in ein einziges Modell zu vereinen. Man will sie vereinen, da sie auf die selben Daten zugreifen. Es wurde auch über die verschiedenen Aspekte von DDD geredet.

Man sollte das Domänenmodell unabhängig von der Persistenz aufbauen. Viel zu oft lassen wir Entwickler uns verleiten, schon gleich zu weit (in die Persistenz) zu denken, wenn gerade erst die Architektur aufbauen. Der Gegensatz zu DDD wären Architekturen, die nur aus Datenobjekten (mit gettern und settern) bestehen. Bei DDD sollte man versuchen das Hauptaugenmerk auf das Verhalten der Applikation und der Prozesse zu legen, also die reale Welt abbilden. Hier muss man auf das Verhalten der Kunden eingehen. Dies setzt eine gemeinsame Sprache (ubiquitous language) voraus.

Es wurde stark auf Aggregates (Aggregate-Root) eingegangen. Z.B. wäre Order ein Aggregate von OrderItems. In solchen Fällen sollte das Aggregate die volle Kontrolle über seine aggregierten Objekte behalten. Order sollte also der einzige Einstiegspunkt sein (über Methoden), um etwas an den OrderItems zu ändern. (OrderItems sollte auch besser ein IEnumerable statt einer IList sein.) In der Objektarchitektur sollten beidseitige Referenzen vermieden werden. Dies ist aber schwierig, wenn zwei Sichten aufeinandertreffen.

Dann wurde noch über Context Mapping oder Bounded Context gesprochen. Hier geht es um zwei Modelle auch zwei verschiedenen Welten, die aber auf die selben Daten zugreifen. Man kann sich zu einem gewissen Grad mit dem Repositorypattern behelfen. Man hätte also eine Art Core-Domäne und damit verbunden die zwei Kontexte A und B, die von einander unabhängig sind. Grundsätzlich sollte man anhand der Aufgabe zunächst die Sicht modellieren, die vorrangig ist, und danach das zweite Modell integrieren, so dass die zweite Sicht auf die erste zugreift.

Ich bin auf jeden Fall nächstes Jahr wieder dabei.

Anton.