Rash thoughts about .NET, C#, F# and Dynamics NAV.

Legacy code is a problem in all languages, even F#.

The super awesome Ilker Cetinkaya published an excellent article about “test implants”. I really recommend to read his post before you read this one. It’s a really well written story called “The quest of the test”.

I destilled his nice little story to this small F# code:

We have a function a that is part of a third-party API and a function b which is part of our own legacy code base. The problem is: we want to check that b has called a. without changing b’s signature. Ilker suggested to use a “test implant”. Let’s try to do something similar with our small F# code. Since we are in the land of functional programming our idea is to implant another function into b. So let’s rename b into b’ and add the implant to the parameter list of b’.

Of course we restore b’s behaviour by utilizing b’:

As you can see, we didn’t change the signature nor the behaviour of b. This is a typical refactoring in F#. The program runs as before. Now we want to write our test:

I hope you can see the similarity between this and Ilkers solution. The only difference is that we don’t use new constructors here. I really like this since it brings you one step further to nice functional design. What do you think?

Gestern fand das erste .NET Coding Dojo in Hamburg statt und es war aus meiner Sicht ein voller Erfolg. Als erstes möchte ich mich an dieser Stelle bei der Firma masters of arts für die Räumlichkeit und natürlich bei allen Teilnehmer für die aktive Mitarbeit bedanken.

Durchgeführt haben wir das Dojo im Randori-Stil, d.h. es gab einen Entwickler, einen “Co-Piloten” und das Publikum. Nach jeweils 5 Minuten bzw. jedem neuen Testfall wurden die Positionen mit neuen Teilnehmer aus dem Publikum getauscht.

Nach einer kurzen allgemeinen Einführung in das Thema “Coding Dojo” habe ich die Aufgabenstellungen der Kata.FizzBuzz und Kata.DictionaryReplacer vorgestellt. Durch kurze Abstimmung haben wir dann (vermutlich durch meine Wortwahl beeinflusst) die Kata.DictionaryReplacer gewählt.

Mit der Wahl dieser Kata war ich nicht ganz unglücklich, da wir DictionaryReplacer schon im Online Dojo durchgenommen haben und ich deshalb die Fallstricke schon etwas einschätzen konnte.

Kata.DictionaryReplacer

Create a method that takes a string and a dictionary,
and replaces every key in the dictionary pre and suffixed with a dollar sign,
with the corresponding value from the Dictionary.

Tests

input : "",
          dict empty
output: ""

input : "$temp$", 
           dict ["temp", "temporary"]
output: "temporary"

input : "$temp$ here comes the name $name$",
           dict ["temp", "temporary"] ["name", "John Doe"]
output : "temporary here comes the name John Doe"

[codingdojo.org]

Nach kurzer Einführung in die Vorgehensweise des Test-Driven Developments (TDD) und Diskussion über sinnvolles Naming ging es dann auch richtig in die Entwicklung. Die Kata eignet sich in dieser Form auch sehr schön um tatsächlich “Test first” zu arbeiten. Die Implementierung folgt quasi als logische Konsequenz.

Interessant und ungleich komplizierter wurde es dann als wir eine zusätzliche Anforderung eingebaut haben. Da es sich bei der Kata um eine Art Templatesystem handelt liegt es nahe auch in den Values des Wörterbuchs neue Keys zu erlauben und somit eine beliebige Ersetzungstiefe zu erreichen. Diese Anforderung ist ein wunderbares Beispiel dafür wie sehr man mit Aufwandsabschätzungen daneben liegen kann. 😉

Die rekursive Ersetzung wurde noch sehr schnell gelöst, aber richtig schwer haben wir uns dann mit der Erkennung von zyklischen Ersetzungen und der daraus folgenden Endlosschleife getan. Nach und nach wurden immer kompliziertere Lösungsmöglichkeiten genannt, die aber in der gegebenen Zeit nicht fehlerfrei umgesetzt werden konnten. Als Folge haben wir immer noch einen Test “rot”. Wer Lust hat kann sich also die Quellen vom github Repository ziehen und als Hausaufgabe den verbleibenden Test “grün” machen.

In der Nachbetrachtung haben wir noch einige Sachen festgestellt:

Was lief gut?

• Die Rotation der Teilnehmer klappte problemlos
• Lösungsideen sprudelten förmlich aus dem Publikum
• Interessante Edge-Cases wurden gefunden
• Viele kleine Tipps (z.B. Resharper Shortcuts) wurden ausgetauscht
• TDD wurde als erfolgreich für die Kata angesehen
• Die Randori-Form sorgt für Aktivität
• Ganz wichtig: Es hat Spaß gemacht!

Was wollen wir besser machen?

• Schneller den ersten Test schreiben
• Intensivere Diskussion des Interfaces
• Noch mehr Wert auf das Naming legen
• Versuchen die einfachste Lösung zu wählen
• Mehr Wert auf Refactoring legen
  • wurde etwas vernachlässigt, da wir viel Zeit an der Endlosschleife verbraucht haben
• Die Rollen Driver, Co-Pilot und Publikum klarer trennen
• Nach jedem implementierten Testcase bzw. jeder Rotation der Teilnehmer in das git Repository einchecken
• Von Anfang an externe Tastatur und Maus für den Laptop bereit stellen
• Internetverbindung um Syntaxfrage schneller klären zu können

Als möglichen Termin für das Dojo haben wir jetzt grob jeweils den 3. Mittwoch im Monat vorgeschlagen. Über die Xing-Gruppe der .NET User Group Hamburg werden wir natürlich auch wieder entsprechende Einladungen verschicken.

Vom 29. und 30. November 2007 fand im Münchner Arabella Sheraton Grand Hotel das 1. Technical Community Airlift zu Microsoft Dynamics statt. Im Wesentlichen ging es um folgende Themen:

• Microsoft CRM “Titan”
• Technische Fertigkeiten für Dynamics NAV 5.1
• Ausblick auf Dynamics AX 5.0
• Ausblick auf Dynamics NAV 2009 (Codename NAV “6.0”) (Dynamics NAV Server)
• Microsoft Office und Windows SharePoint Services
• Business-Intelligence
• Sure Step, die Implementierungsmethode für Microsoft Dynamics

An dieser Stelle möchte ich gerne etwas über die von mir besuchten Vorträge berichten.

(weiterlesen…)