Software-Ratschläge eines Bugtrackingsystemverkäufers

Standard

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.

Leave a Reply

Your email address will not be published. Required fields are marked *