Seite 2: Einstieg in TDD

Inhaltsverzeichnis

heise Developer: Wie machen Entwickler ihre ersten Schritte mit testgetriebener Entwicklung?

Uncle Bob: Sehr vorsichtig! Es ist eine Fertigkeit, nicht nur eine Reihe von Regeln. Man muss TDD üben und richtig lernen, bevor man damit ernsthaft arbeiten kann. Es kommt häufig vor, dass jemand die drei Grundregeln von TDD lernt und gleich damit arbeitet. Dann fangen die Probleme an, es wird kompliziert, und die Betroffenen verwerfen TDD.

Es braucht einen sicheren Weg, testgetriebene Entwicklung zu üben. Lunch-and-Learn-Events, Dojos, Wochenendtrainings – Entwickler müssen zunächst die Fertigkeit lernen, bevor sie TDD produktiv einsetzen können. Es erfordert von Programmierern und den Unternehmen anfänglich zeitliche Investition, aber anders funktioniert es nicht.

heise Developer: Im heutigen Trainingsprogramm haben Sie testgetriebene Entwicklung mit doppelter Buchführung verglichen. Warum ist TDD für Entwickler so viel schwerer als doppelte Buchführung für Buchhalter?

Uncle Bob: Es ist nicht schwieriger, aber Buchhalter lernen doppelte Buchführung von Anbeginn ihrer Ausbildung. Sie haben keine Wahl, und kein Buchhalter wird erwägen, darauf zu verzichten. Programmierer bekommen dieses Training noch nicht.

Doppelte Buchführung wurde zwar bereits vor 1000 Jahren erfunden, aber das letzte Land, dass es offiziell eingeführt hat, wartete damit bis 1945. Es hat also sehr lange gebraucht, bis die Methodik ihren Weg rund um den Globus zu der Disziplin für Buchhalter gefunden hat.

Ich fürchte, dass wir keine 1000 Jahre Zeit haben, um TDD weltweit durchzusetzen. Aber ich bin zuversichtlich. Sie existiert erst seit zwanzig Jahren und hat sich seitdem gut verbreitet. Ich hoffe und glaube, dass die Verbreitung voranschreiten wird.

heise Developer: Werden Kommentare mit Clean Code überflüssig? Sätze wie "das muss ich später fixen" oder "Folgende Zeile funktioniert, auch wenn ich nicht weiß, wieso" sollte es in TDD freilich nicht mehr geben, aber was ist mit erklärenden Kommentaren für andere Entwickler?

Uncle Bob: Meine Regel für Kommentare ist: Man schreibt einen Kommentar, wenn man nicht in der Lage ist, sich deutlich über den Code auszudrücken. Man sollte immer als erste Option versuchen, aussagekräftigen Code zu schreiben. Kommentare sind die letzte Option. So gesehen sind Kommentare immer ein Zeichen des Scheiterns und man sollte sie als solches sehen.

Schreibe ich selbst Kommentare? Natürlich, aber das zeigt, dass ich an den Stellen nicht in der Lage war, mich ausreichend über den Code auszudrücken. Ich möchte keinen Standard, der vorsieht, dass alles kommentiert werden muss – jede Klasse, jede Methode, jede Variable. Das ist Verschwendung und führt zu Wirrwarr. Kommentare sollten nur dort stehen, wo Entwickler festgestellt haben: Hier kann ich mich nicht deutlich genug durch den Code ausdrücken.

heise Developer: Wie beeinflusst die Open-Source-Entwicklung den Prozess? Lässt sich Clean Code einfacher oder schwerer in der Community durchsetzen als im Unternehmen?

Uncle Bob: Die Open-Source-Community ist sehr interessant, weil sie aus den Committern und den Kontributoren besteht. Erstere bestimmen, ob der Code von Letzteren es ins Projekt schafft. Die Committer legen also die Standards fest. Ich habe an einigen Open-Source-Projekten mitgearbeitet, und gelegentlich haben Committer meine Codeeinreichungen mit dem Argument abgelehnt, dass mein Code nicht dem Standard im Projekt entspräche.

Das ist ein leistungsfähiger Steuerungsvorgang, und ich wünschte, dass mehr Firmen auf dieselbe Art arbeiten würden. Es wäre klug, wenn erfahrene Entwickler dort die Rolle der Committer einnähmen. So ließen sich auch dort Standards besser durchsetzen.