Skip to end of metadata
Go to start of metadata

oder: "Warum Tab Driven Development ein Problem für Test Driven Development ist"

 

Spoiler-Warnung: Dieser Text ist nicht gänzlich ernst zu nehmen! (smile) Ich denke / hoffe aber Ihr merkt worauf ich hinaus möchte.

 

Begriffsklärung

Tab Driven Development :

Nutze für die Entwicklung deiner Software eine IDE welche eine Autovervollständigung ( Tab(ulator)-Completion ) für die genutzte Programmiersprache und Bibliotheken besitzt.

Mach dir keine Gedanken um den Aufbau, es wächst einfach so wie du es gerade brauchst.

Fortan lerne auch nicht mehr irgendwelche APIs / ABIs sondern hangele / tabbe dich durch die "Möglichkeiten". Fehlt eine Möglichkeit, wird sie ergänzt oder was gebastelt um es zu umgehen - im Zweifel jedesmal wieder.

Eng verwandt mit "Try and Error", "Spaghetticode", "" und "f*** it, ship it"

 

Test Driven Development :

Ist eigentlich das was jeder Entwickler tun sollte: Erst denken, dann handeln

-> Erst den Test schreiben - sich dabei Gedanken um den Aufbau machen -, erst dann das Programm selbst entwickeln.

Die Tests belegen dass du alles richtig gemacht hast und geben dir ein gutes Gefühl.

Das Problem sitzt vor dem Rechner

Nun, was sind wohl die klassischen Ausreden keine Tests zu schreiben:

  • Ich habe keine Zeit
  • Aufwendig
  • bezahlt niemand
  • muss ich ständig anpassen da mir während der Entwicklung immer noch was brillantes einfällt
  • Tests schreiben ist langweilig

(smile) ich denke wir kennen genügend weitere und sei es reine Bequemlichkeit, aber: es geht ja um Tab DD vs. Test DD und nicht um "Test DD" vs. "Test-less DD".

 

Nun: Was wäre ohne 'Tabs'?

Annahmen:

  • Wir müssten uns mehr merken
  • Wir müssten uns mit APIs / ABIs mehr auseinandersetzen und verstehen was Sie tun bevor wir programmieren und einen Fehler finden
  • Code wäre tendenziell fehleranfälliger durch Schreibfehler (bei nicht vor-kompilierten Sprachen)
  • Entwicklungszeit verlängert sich

Erwartungen:

  • Mehr Qualität denn Quantität
  • Am Ende höher qualifiziertes Personal
  • Fehlerbehebungen gehen "schneller von der Hand" wenn man mehr Background hat

 


inspired by / related to topic: svenpet.com about Blame driven development - finally a methodology that works

  • No labels