Michaels Blog

Es muss Gründe geben, warum nicht jeder Entwickler bei der Erwähnung von Test Driven Development (TDD) mit „ach klar, genau“ antwortet. Ich möchte dazu mal etwas ausholen. Softwareentwicklung ist ein kreativer Prozess. In diesem Prozess gibt es einige hochbegabte Entwickler, sehr viele im guten Mittelfeld und einige, die jede Kreativität vermissen lassen. Wo der eine mit dem ersten Wurf bereits einen sehr guten Treffer landet, muss sich der andere langsam an das Ziel herantasten. Das ist ganz normal, so sollte es ja auch sein.

In dem man nun TDD propagiert, stellt man alle Entwickler gleich, in dem man sagt, schreibe zuerst den Test, denn was Du entwickelst funktioniert mit hoher Wahrscheinlichkeit nicht. Das ist spannend. Wenn man Unterschiede zwischen Entwicklern macht, und ich hoffe, da gibt es keine Zweifel, dass dem so ist, dann soll es eine Arbeitsmethode geben, die für alle gleich gut funktioniert? Mir fällt kein Beispiel aus anderen Bereichen ein, wo das der Fall ist.

Ich glaube, und das zeigt mir meine Erfahrung, dass für den erfahrenen Entwickler eher das Motto gelten sollte: Teste, wo Du es für wahrscheinlich hältst, dass Du ein Fehler gemacht hast. Und ich habe es bisher nicht als vorteilhaft erachtet (und darum geht es ja hauptsächlich), den Test vor der Funktion zu schreiben. Dann das würde darin enden, dass ich an zwei Stellen gleichzeitig Anpassungen vornehmen muss, bevor überhaupt eine Funktion umgesetzt wurde. Ich weiß nicht, wie es anderen Entwicklern so geht, aber ich passe den Code, der entsteht sehr oft an – wie ein Gemälde, dass sich mit jedem Pinselstrich vervollständigt, aber eben auch Bereiche wieder ausradiert und neu gezeichnet werden müssen. Es ist nicht nur eine Funktion, die so entsteht, sondern gleich ein kleines Lösungsgebilde. Würde ich jedes mal davor einen Test schreiben, würde ich auf diese Weise extrem viel für die Tonne produzieren.

Als Entwickler passt man seine Arbeitsweise so an, dass die eingesetzten Methoden einen persönlichen Vorteil offenbaren. Wenn dieser Vorteil eintritt, ist Überzeugungsarbeit nicht notwendig. Dass es immer wieder Diskussionen zu z.B. TDD gibt, liegt wohl daran, dass es nicht für jeden die beste Wahl ist.

Test Driven Development (TDD) lebt davon, dass vor jeder Funktion ein Test zu schreiben ist, der die Funktion auf Korrektheit prüft. Von diesem Schema gibt es keine Abweichung. Und genau da entsteht ein Problem, dass immer dann entsteht, wenn man glaubt, komplexe Probleme auf genau eine Art lösen zu können. Dabei ist der Ansatz interessant. Aber mit der Dosis, mit der diese Medizin verabreicht wird, wird es zu Gift. Dafür gibt mehrere Gründe, ein paar möchte ich beleuchten.

Nur Hellseher wissen, was später herauskommt und nicht mal die liegen richtig**.**

In dem ich einen Test für die Lösung eines Problems schreibe, lege ich das Endergebnis schon fest. Doch in vielen Fällen trifft diese erste Lösung nicht ins schwarze, sondern nur mit viel Glück überhaupt die Scheibe. Je länger man sich mit dem Problem beschäftigt, desto vielschichtiger werden die Lösungsansätze. Die Schwierigkeit mit einem Test ist dann, das es mit einem vorhandenen Stück Code schwerer fällt, sich von dieser Fehlentwicklung zu lösen.

Mir hat jemand die Zeit gestolen.

Wenn man TDD konsequent Anwendet, dann geht nichts mehr ohne Test. Das führt dazu, dass entweder die zu testenden Funktionen komplexer werden, weil man sich ja doch irgendwie scheut, für alles und jeden Tests zu schreiben. Oder es führt dazu, dass man fein granulierte Funktionen entwickelt, die jede mit einem Test geprüft werden. Man hat also für ein Problem doppelt soviel Code wie nötig geschrieben hat. Wenn man dann das Problem am Anfang auch noch (wie zu erwarten war) falsch eingeschätzt hat, dann sieht die Quote wohl noch schlechter aus, weil dann viel Testcode und Funktionscode durchs Refactoring geschoben wurde.

Die Lösung

Es kommt wie immer auf die Dosis an. Aber es erscheint mir aus den oben genannten Gründen zu riskant, als das man mit einem Test anfangen sollte. Bei einem Problem erstelle ich meist einen minimalen Funktionsprototypen, an dem man dann mit einem geeigneten Test a) die Funktion und vor allem b) die Handhabbarkeit testen kann. Dabei teste ich nur Dinge, bei denen ich davon ausgehe, dass da etwas schief laufen kann. Wenn man entsprechend selbstkritisch ist, entsteht eine gute Mischung aus Test- und Funktionscode, bei dem man dann den Testcode getrost der Problemlösung zurechnen kann, denn er demonstriert die Anwendung der Lösung an einem Beispielproblem. Getreu dem Motto: „Code ist Dokumentation“ hat man eine Dokumentation geschaffen, die nicht so schnell veraltet, die notwendige Information in einer für den Entwickler verständlichen Form transportiert und dabei auch noch schön kompakt ist.

Da ich Abkürzungen nicht mag (steht ein Teil des Problems drin), aber der eine oder andere doch einen Begriff haben möchte, mit dem er dieses Vorgehen benennen kann, nenne ich das ganze: Development is Code, Test and Documentation (DICTAD/DCTD).

Wer wie ich Webanwendungen entwickelt, wird sich ähnlich freuen, den Microsoft arbeitet intensiv daran, sich an Standards zu halten.Wenn sich der IE Version 8 dann großflächig verbreitet hat, kann man vielleicht die eine oder andere "Krücke" endlich abschalten, die notwendig war, damit es auch im IE gut aussah. Wenn dieser Schritt wegfällt, ist mein Leben wieder ein kleines Stück einfacher.

Denn man muss schon feststellen, dass während der Entwicklung von Webanwendungen vermutlich zu einem Anteil von über 90% der Firefox zum Einsatz kommt und danach geprüft wird, ob der IE nicht aus der Reihe tanzt. Das liegt wiederum in den wesentlich besseren Tools, die sich schön in den Firefox integrieren.

Ich hoffe, das Microsoft diesen Pfad weitergeht, bin aber gespannt, welche strategische Entscheidung dazu geführt hat. Im Zweifelsfall ist das nichts gutes, vorerst sehe ich es aber mal positiv.

Den Begriff "Bananensoftware" kannte ich bisher nur aus dem kommerziellen Umfeld. Das Opensource-Projekt KDE hat es geschafft, das man auch mal im Linux-Umfeld das Gefühl nicht los wird, dass die Software beim Anwender reifen soll. Das ist unverständlich und hat mehr geschadet als genützt, auch wenn KDE 4.2 endlich wichtige Fehler beseitig. Die technischen Möglichkeiten sind sicher beeindruckend. Das hilft nur nicht, wenn man nicht mit einer gewissen Stabilität rechnen kann. Wenn man schon das Ziel Windows oder sogar MacOS hat oder sogar noch besser sein möchte, fängt es IMHO immer bei der Stabilität an. Da muss man Microsoft auch zugestehen, dass sie mit WindowsXP gelernt haben und ein stabiles System ausliefern. Es wäre erschreckend, wenn es die ersten Nutzer gibt, die sich fragen, wie sie von Linux auf Windows wechseln können.

Das kann man besser.

Seit Dezember ist mein Frau stolze Besitzerin eines EeePC 900A. Es ist schon ein sehr schön handliches Gerät und die Freude war groß, als das Päckchen unter dem Weihnachtsbaum lag.

In der Grundinstallation ist sind viele spannende Anwendungen drauf. Dann kommt das Fenster "Softwareupdates" in den Blick und der Ärger beginnt. Die Aktualisierungen lassen sich nur zum Teil einspielen und schon einfache Systembefehle stürzen ab. Unzufriedenheit macht sich breit… so wanderte das Gerät zu mir, damit ich das Problem löse.

Einfacher gesagt als getan. Nach mehreren Schleifen aus Zurücksetzen in den Werkszustand und erneutem Probieren, Googlesuchen, einer Testinstallation von Ubuntu auf einer neuen SD-Karte und einer Neuinstallation von der Orginal-DVD, weiteren Googlesuchen fand ich dann irgendwann die Lösung (Forumsbeitrag). Und so geht es:

sudo bash
cd /tmp
wget http://update.eeepc.asus.com/p701/pool/perl-base_5.8.8-7_i386.deb
dpkg -i perl-base_5.8.8-7_i386.deb

Damit repariert man das fehlerhafte Perl-Paket in Xandros 1.6.1, das mit dem EeePC ausgeliefert wurde. Danach klappen alle weiteren Installationen und Updates problemlos.

Xandros Linux bekommt so nochmal eine Chance.