Software-Ratschläge eines Bugtrackingsystemverkäufers

Von Andreas Schlapsi | Veröffentlicht am: 25. September 2009

Update: Code-Beispiel rausgenommen.

Joel Spolsky hat wieder einmal etwas geschrieben. Sein neuer Blogpost beginnt gut mit dem Wert von Simple Code und geht dann über zu dem üblichen Gejammere, dass Unit-Tests böse sind. Außerdem brauchen Entwickler nicht klug sein, weil blöde Entwickler schön sind, oder so ähnlich. Die Antwort von Robert C. Martin (Uncle Bob) ist viel besser.

Viele Entwickler, die jetzt mit TDD arbeiten, haben vorher auch schon Software geschrieben. Ich erinnere mich nur mit Schaudern daran. Vor vielen Jahren habe auch ich an Projekten mitgearbeitet, wo ohne Unit-Tests gearbeitet wurde. Oft war der Grund, dass mit Technologien gearbeitet wurde, die das Testen erschweren, z.B. VBA. Wenn dann auch noch der Projektdruck dazukommt, entstehen schon mal Word-Makros mit ca. 10.000 Zeilen und seltsamen Kontrollstrukturen. Lesen lässt sich dieser Code dann nicht mehr.

Meistens war ich der Entwickler, der in der Wartungsphase neue Features einbauen musste, bzw. Features ändern musste. Das war selten ein Vergnügen.

Derartigen Code habe ich jedenfalls nicht mehr gesehen, seitdem ich mit TDD arbeite. Natürlich ist die Welt auch mit TDD nicht perfekt, aber der Code ist viel evolvierbarer als der Code, der von Joel Spolskys Isolationsbandentwickler geschrieben wird.

Und ja, es ist wichtig, dass die Software verkauft wird. Aber ich weiß nicht, woher das Märchen vom zusätzlichen Aufwand für Unit-Tests kommt. Ich starte den Debugger meistens nur mehr als Designwerkzeug. Wahrscheinlich ist der Aufwand größer, wenn man die Tests nachher schreibt und noch keine Erfahrung damit hat. Dann verliert man ohnehin den Vorteil von TDD als Design-Tool.

Übrigens, der Entwickler, den Spolsky in seinem Blogpost zitiert, hat anscheinend am Netscape Communicator mitgearbeitet. Wir wissen ja, was daraus geworden ist.

[... etliche 1000 (tausend!!!) Zeilen unlesbarer VBA-Code, alles in 1 Procedure]

Kick It auf dotnet-kicks.de
Dieser Eintrag wurde veröffentlicht in .NET und getagged , . Bookmarken: Permanent-Link. Kommentieren oder ein Trackback hinterlassen: Trackback-URL.
  • http://magerquark.de Uwe

    Haha, dass Ihr nun anfangt zu jammern war ja klar.

    Mir gefällt der Artikel von Joel sehr gut.

  • aschlapsi

    Mir missfallen vor allem folgende Punkte:

    1. Unit-Tests werden so dargestellt, als ob es ein Zusatzaufwand ist. Im TDD ist es das nicht. Ohne TDD wird die Software nicht früher fertig. Ich glaube sogar, dass das Gegenteil zutrifft. Unit-Tests sind kein Feature für den Kunden, aber die Debugging-Session, um den Fehler zu finden, den man irgendwann in den letzten 4 Stunden eingebaut hat, auch nicht. Und im Gegensatz zum Debugging bieten die Unit-Tests auch später einen Nutzen.

    2. Aus Joel Spolskys Blogpost entnehme ich, dass Entwickler Design Patterns, Templates, C++ usw. nicht kennen bzw. nicht kennen müssen, wenn sie nicht klug genug sind. Wenn ein Programmierer nicht klug genug ist, um diese Technologien einzusetzen, wenn er/sie sie braucht, dann hat er/sie nicht die richtige Berufswahl getroffen.

    Ich kann Joel Spolsky in einem Punkt zustimmen: Man soll den Programmcode einfach halten und nicht jede neue Technologie sofort einsetzen, wenn sie keinen Nutzen bringt und den Code komplizierter macht. Deshalb gefällt mir die Antwort von Uncle Bob so gut. Hast du sie schon gelesen? Was hältst du davon?