Default TDD

Ich habe mal einen Kletterkurs besucht. Klettern hat tatsächlich einige Parallelen zum Programmieren. Das Ziel ist klar und in Sichtweite. Der Weg dorthin aber steinig und schwer. Oft muss man einige Hindernisse und Abgründe überwinden. Es ist nicht immer direkt ersichtlich welcher Weg begehbar ist und schon gar nicht welcher der beste wäre. Hat man sich für einen entschieden, ist es nicht so leicht umzukehren. Man blickt in die Tiefen seiner selbst und lernt, wie man in stressigen Situationen handelt oder mit Versagensängsten und Ungewissheit umgeht.

Wow! Ich könnte hier immer weiter schreiben, aber der Punkt ist klar.

Jedenfalls sagte der Lehrer in diesem Kletterkurs: “Das Klettern ist ein schöner Nebeneffekt des Sicherns.”

Eigentlich handelte es sich um einen Sicherungskurs. Außer kurzen Exkursen in Klettertechnik, lernte man sich anseilen, abseilen, Knoten knüpfen ect. Alles was notwendig ist um nicht, bei einem falschen Tritt, ungebremst in die Tiefe zu fallen.

Dies ist vielleicht die wichtigste Parallele zwischen Klettern und Programmieren.

Früher stand für mich die Funktionalität der Anwendung im Mittelpunkt. Durch Druck der Vorgesetzten, Termine ect. habe ich mich hinreißen lassen die Sicherheit der Anwendung zu vernachlässigen. Heute weiß ich es besser. Wer sich nicht absichert, wird früher oder später schmerzhaft auf die Nase fallen.

TDD muss der Standard sein. Nicht dogmatisch, aber praktisch. Erst wird das Sicherheitsnetzt gespannt und danach beginnt der Drahtseilakt. Ich schreibe heute weit mehr Testcode als eigentlichen Programmcode. Ich habe mich nie als Softwaretester war genommen und wollte auch nie einer sein. Ich dachte es handele sich um einen komplett anderen Beruf. Wenn ich mir den geschriebenen Code ansehe und das Verhältnis von Tests und Code gegenüberstelle, muss ich allerdings feststellen, dass ich in erster Linie wohl ein Tester bin und erst dann Programmierer.

Diese Erkenntnis ist gut. Sie heißt nicht, dass sich meine Aufgabe geändert hätte.

Sie heißt zwei Dinge:

1. Sie heißt, dass ich meine Verantwortung für die eigene Arbeit und das Produkt dieser Arbeit wahrnehme.
2. Das ich kein Programmierer bin, sondern Entwickler. Ich schreibe nicht einfach Code. Ich entwickle ihn durch Try and Error. Wann habt ihr schon mal etwas programmiert, von dem ihr schon zu Beginn genau wusstet welche Codezeilen ihr schreiben müsst? Wie komplex kann dieses Problem gewesen sein? Der Standardfall ist doch, dass ich eben nicht genau weiß, was zu tun ist. Ich muss es herausfinden. Das mache ich heute indem ich einen Test schreibe. Das wiederholte Starten der Anwendung und Eingeben von Testdaten kann ich mir dabei sparen, Ich schreibe einen Test und probiere aus. Dann ändere ich den Test und probiere erneut. So sichere ich mir Stück für Stück den Weg zum Gipfel.