Über die Schönheit von schmutzigem Code

Über die Schönheit von schmutzigem Code

Vermutlich habe ich zu viel bei den TDDlern geschaut (oder heißt es auf deutsch „TGE”?). Jetzt habe ich die Eleganz des „Dirty Hacks” entdeckt.

Ich schon so manchen Meister im TDD gesehen, der z. B. im beliebten Beispiel eines Taschenrechners einen Test schreibt in der Art von

1
2
3
4
public void AddOneAndThreeEqualsFour()
{
    Assert.IsEqual(Calculator.Add(1, 3), 4);
}

und diesen dann löst mit

1
2
3
4
5
6
7
class Calculator
{
    public int Add(int a, int b)
    {
        return 4;
    }
}

🙂

Früher hätte ich mich darüber sehr gewundert. Mittlerweile habe ich über einen unschönen Hack so oft ein Problem gelöst, daß ich im Vorhinein nicht durchschaut habe, daß ich die Vorteile ganz offen erkennen kann.

Wenn ich eine technische Lösung ausprobiere, so landet sie (wenn sie denn mehr als minimal komplex ist) oft an einer völlig falschen Stelle. Ich merke, wie ich in anderen Klassen Funktionen von private auf public ändern muß, wie generell die Information nicht da ist, wo sie hingehört. Kommunikation erfolgt über globale Variablen.. alles, was man eben nicht tun sollte. Und sobald die Lösung dann läuft (also technisch ok ist) fällt dann alles an seinen gerechten Platz – dank der gewonnenen Erfahrung. Änderungen werden wieder rückgängig gemacht, ein wenig refactort, es entsteht eine minimale Lösung. Eine schöne Lösung.

Aber vorsicht: Nicht zu hause nachmachen!!.

Oft wird nämlich der letzte – wichtige – Schritt vergessen.

So habe ich einmal eine Geschichte von einem Projekt gehört, das.. etwas unter Zeitdruck geraten war (eine Textverarbeitung), und dann tatsächlich jemand eine Funktion, die die Schrifthöhe berechnen soll, fix 12 Punkte zurückgegeben hat. In dem Fall hat er es gemacht, um sich (den Regeln der Organisation entsprechend) etwas Luft zu verschaffen, würde ihn die Aufgabe der Implementierung doch erst ereilen, nachdem seine Lösung einmal zum Tester gegangen und danach wieder zurückgekommen ist.

Nun, wo so etwas auftaucht, sollte man sich wohl noch einmal genau seine Prozesse anschaun. Und seinen Zeitplan.

Man sollte immer noch die Zeit haben, sich die nötige Verallgemeinerung vorzustellen (oder im TDD einen passenden Test zu schreiben), so daß die Funktion dann passend aussieht. Insbesondere in den Fällen, die nicht direkt offensichtlich sind.

1
2
3
4
5
6
7
class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }
}

Ansonsten freue ich mich natürlich, wenn andere Leute ebenfalls ihre Meinung zu dem Thema schreiben könnten.

Sitzt bei euch das erste Design immer? Seid ihr begnadete Architekten und Designer? Oder hunzt ihr erst etwas hin und seht zu, daß am Ende immer noch die Zeit für ein Refactoring ist?

Und liest jemand meinen Blog, der hinhunzt, und dann alles so läßt?

Ranting and Raving

Wobei ich auch schon für Kunden gearbeitet habe, wo offiziell das V-Modell benutzt wird (eine Art doppelter Wasserfall), das ganze dann aber als agil verkauft wird. Das waren dann auch diejenigen, die sagten, sie würden CI machen, aber hatten keinen automatischen Build. Wenn die Fundamente fehlen, wie will man dann ein Haus bauen?

One thought on “Über die Schönheit von schmutzigem Code

  1. Genau dazu passend habe ich gerade bei Peter Provost (Program Manager Lead Visual Studio ALM Tools) in seinem TechEd-Talk auf Channel 9 gehört, daß beim TDD das Refactoring die Designphase ist.

    So lange man also noch Funktionalität implementiert kümmert man sich reichlich wenig um ein gutes Design.

    Ohne Frage ist auch ein Design im nachhein oft (immer?) besser. Man stelle sich nur vor: man plant eine Route mit dem Auto bevor man den Weg je gesehen hat oder man plant sie, nachdem man ein paar Wege bereits gefahren ist und mit dem Gelände vertraut ist.

    So oder so haben nur die.. Schlauesten?.. ein Design, das von vornherein steht, alle anderen sollten refactorn. (Übrigens habe ich noch nie jemanden getroffen, dessen Design von vornherein gut ist. Um so schlimmer, wenn es dann jemand geglaubt oder sich so verhalten (Augen und Ohren zu) hat.)

    (Wobei ich mich immer wundere, wie das die E-Techniker machen, die eine neue Platine oft nach wenigen Versuchen brauchbar hinbekommen – aber auch die simulieren ja umfangreich vorher und patchen bedarfsgemäß nachher.)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.