Pont TDD tanfolyam volt előző héten, amikor volt egy videó, amiben David Heinemeier Hansson, Martin Fowler és Kent Back beszéltek (vitatkoztak?) a témáról. A kiváltó cikk ez.
A második két ember gondolom közismert, David Heinemeier Hansson a Ruby on Rails létrehozója.
Az első rész nem volt túl mély, remélem a másodikban kicsit jobban belejönnek, bár lehet, hogy kár ezt várni. Van, amikor természetesen jön a TDD, van, amikor nem, ilyenkor igyekszünk utólag tesztelni, ha sikerül. Semmi se szentírás a szakmában, van, aki elölről szereti, van, aki hátulról. Mint az Eurovíziós dalfesztiválon. :)
Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.
LEAVE A COMMENT
5 COMMENTS
En pont Davidet ismertem csak, ki a masik ketto?
Kent Back a TDD kitalálója, Fowler meg az általános Agile észosztó.
Egy kicsit en is tobbet vartam a vitasorozattol, kicsit el lett huzva, de azert jo volt. Azt gondolom, hogy mint semmiben ebben sincs silver bullet. En ismertem mindegyiket, Davidet kevesbe, de biztos vagyok benne, hogy mindharman a minosegi, profi fejlesztest kepviselik. Az pedig problema fuggo, hogy mikor mi a jo megkozelites. Nyilvan nem erdemes atesni a lo tuloldalara TDD-ben sem. Ha a TDD cel nem pedig eszkoz az baj. Mint mindennel itt is meg kell talalni az egyensulyt es erteket teremteni eszmek meg elvek helyett. Ez rengeteg fejlesztot hatraltat es keresi az igazat/hamisat ahelyett, hogy a megoldast keresne az _aktualis_ problemara. Ami erre a temara levetitve sok esetben az, hogy megfogalmazom az elvarasom majd teljesitem azt (red-green) sok esetben meg valami mas.
En nem tudtam megbaratkozni a TDD filozofiaval. Ertem, hogy mirol szol, de nem akar kedveltte valni nalam. En eleg impulziv modon fejlesztek, van egy otlet/feladat, nekiulok, megcsinalom, aztan jonnek a tesztek. Sokkal inkabb erdekel, hogy mukodni lassam a kodot, minthogy jol le legyen tesztelve.
En is impulziv modon fejlesztek es sokszor pont az teszi ezt lehetove biztonsagosan, hogy le van fedve. A prototyping meg megint egy masik mufaj, azt en sem TDD-ben csinalom mert semmi ertelme abban csinalni.
“Sokkal inkabb erdekel, hogy mukodni lassam a kodot, minthogy jol le legyen tesztelve.”
A ketto ugyanaz, ha mukodni latod a kodot akkor letesztelted, ha leteszteled es atmegy akkor mukodni latod a kodot. A kerdes ugye, hogy mennyi ido ellenorizni, hogy meg mindig _ugy_ mukodik-e mint szeretned ha esetleg megint ellenorizned kell.