Warum Testgetrieben Entwicklung Goldwert ist?
Der Anlass für diesen Blog war der Abschluss von sehr
erfolgreichen JEE Projekt (auf Basis JEE 7 Technologie) . In sehr kurze Zeit
habe Ich JSF, EJB, JPA Programmieraufgaben realisiert!
Aus Erfahrung weiss Ich, dass die Enterprise Projekte sind meistens keine „Sprint“ Projekte, in den meisten Fällen handelt es sich um „Marathon“ Strecken, trotzdem durch meine Arbeitsweise und den Streben nach Qualität und sehr methodischen Vorgehen bei der Realisierung von Projektteilen wurde es zum Erfolg geführt, wobei viele in den Projekt an den Erfolgt nicht geglaubt haben!
Aus Erfahrung weiss Ich, dass die Enterprise Projekte sind meistens keine „Sprint“ Projekte, in den meisten Fällen handelt es sich um „Marathon“ Strecken, trotzdem durch meine Arbeitsweise und den Streben nach Qualität und sehr methodischen Vorgehen bei der Realisierung von Projektteilen wurde es zum Erfolg geführt, wobei viele in den Projekt an den Erfolgt nicht geglaubt haben!
TDD : Test driven development
So ein Unsinn,
Ich stelle immer wieder fest, dass Ich mit den Vorurteilen zu kämpfen habe: TDD ist zu langsam , TDD führt nicht zum
Ziel , TDD wer soll diese Tests pflegen, TDD schütz nicht von eigene Dummheit,
TDD viel zu teur.
Was zeigt aber meiner Erfahrung, ich kann leider hier keine Einzelheiten
meines letzten Projektes public veröffentlichen,
aber man kann JSF(Managed Beans) , JPA und JMS; EJB Testgetrieben entwickeln!
Was spricht dafür?
Kommerzielle Software, muss sehr oft angepasst werden, und es gibt viele Gruppe von Programmierer ,
die behaupten nur durch sauberes Code und einhalten von Architektur kann man
sich „retten“, ich persönlich vertrete die andere Sicht dieses Spektrums.
Nach meiner
Meinung, sich auf eine bestimmte Architektur zu verlassen kann zu einer der
größten Fehler überhaupt führen!
Die Testgetriebene Entwicklung gibt ein sauberes Code und gibt mir meistens die Garantie, dass jeder Zeit meine Software an die chaotischen Kundenansprüchen angepasst werden kann, so dass die ganze Geschäftslogik nicht verletzt und oder die Datenbank Persistenz und Redundanz eingehalten werden kann.
Die Testgetriebene Entwicklung gibt ein sauberes Code und gibt mir meistens die Garantie, dass jeder Zeit meine Software an die chaotischen Kundenansprüchen angepasst werden kann, so dass die ganze Geschäftslogik nicht verletzt und oder die Datenbank Persistenz und Redundanz eingehalten werden kann.
Aber die Deadlines?
Die Deadlines müssen eingehalten werden
das stimmt, aber nicht um jeden Preis, der Quellcode soll immer wieder besser werden,
und nicht schlechter.
Nach ein Paar Jahren aktiver mitarbeit, bin Ich zum folgender Meinung gekommen:
für mich in so vielen
Projekten war es immer eine Mutprobe, sich quer zu stellen und zu sagen
warum ein Projekt soll länger laufen, einige Auftraggeber waren ehrlich darüber schockiert und verärgert,aber andere haben Verständnis dafür gezeigt und mir die nötige Zeit für den Abschluss des Projektes immer gegeben!
Bei den diejenigen wo keine Verständnis gibt, dort war auch für mich das Projektende und Ich habe keine Vorauszahlung dafür verlangt oder dafür das Geld erhalten habe, also beide Parteien blieben somit zufrieden!
Für die Zukunft aber, Ich möchte nur mit diejenige Firmen arbeiten, wo
meine Arbeitsweise von Anfang an akzeptiert wird, sonst lohnt sich aus meiner Sicht der Aufwand nicht, da Ich für die schlechte Quellcode nicht verantwortlich oder
zuständig weiterhin bleiben will