Hogyan adjuk el a TDD-t X-nek?

Nyugodtan behelyettesíthetjük a címben x helyére a magunk nevét, mivel a kifogások keresése a legtöbb embernek nagyszerűen megy. Sokszor nem is mást, hanem saját magunkat kell meggyőznünk bizonyos dolgok tekintetében. Legyen az módszertan, eszköz, vagy bármilyen újdonság használata. Mivel nagyon hatékonyan tudjuk magunkat befolyásolni és akadályokat görgetni önmagunk elé ezért ez nem is olyan egyszerű feladat.

Hébe-hóba olvasok valami ilyesmit.

Ja, a [TDD /BDD /ATDD ] nagyszerű. De hogyan győzzem meg a főnökömet / beosztottamat / kollégáimat, hogy szánjanak rá időt?

Az elmúlt hetekben úgy döntöttem, hogy kell valamit írjak erről, ha újra fölmerül ez a kérdés. És tessék, itt van!

A TDD nem működik

Először is azt hiszem, segít, ha alkalmazunk egy leckét, melyet évekkel ezelőtt úszóedzőként tanultam. Volt több kissé szokatlan, időnként nehezen végrehajtható gyakorlat a repertoáromban. Ezek karcsapások variációiból álltak szokatlan testhelyzetekben.

Időről időre, amikor kiadtam egyik-másik gyakorlatot a gyerekeknek, minden alkalommal valaki vagy akár mindenki panaszkodott: „ez nem működik”, „nem tudok így úszni”, stb.

Amit a gyerekek nem tudtak, hogy először én is kipróbáltam ezeket a gyakorlatokat, hogy megtudjam, milyen nehezek is azok. Ezáltal azt is megtudtam, hogy meg lehet azokat csinálni. Idővel rájöttem, hogy az „ez nem működik”-et könnyen le lehet fordítani: „nem tudom, hogyan tudom megcsinálni”, és íme, hadd lássam, hogyan tudok neki segíteni ebben.

Manapság ugyanezt alkalmazom a TDD-re. Amikor valaki azt mondja nekem, hogy a TDD nem működik az ő kód bázisán, máris kész a fordításom: „Nem tudom, hogy működik a TDD az én kódomon”, és mehetünk is.

A főnököm nem engedi

Ja, tényleg. Ez egy kemény üzenet: megmondod az ácsnak, hogyan tartsa a szekercét? A vízvezeték-szerelőnek, hogyan használja a csőkulcsot? Az autószerelőnek, hogy mikor cseréljen olajszűrőt?

Komolyan, miért a főnököd, a projektmenedzsered, vagy bárki más, aki megbocsátja, ha nem használod a TDD-t, mondja meg neked, hogyan csináld a munkádat? Azt hittem, egy magasan képzett szellemi dolgozó vagy. Ha meg vagy győződve a TDD hatékonyságáról, nincs az a főnök vagy projektmenedzser, aki megmondja, hogyan végezd a dolgod.

Óh, sajnálom, valóban van egy eset, amikor helyénvaló lehet, hogy a főnököd azt mondja, ne használd a TDD-t: ha a TDD segítségével sem tudsz olyan működő szoftvert szállítani, amely megfelel az üzleti céloknak.

De ne feledd: ez arról visszajelzés, hogyan használod a TDD-t, és nem arról, hogy a főnök vagy a projekt menedzser milyen rossz is lehetne. Szóval, a jobb, TDD-t használó gyakorlatok és tervezési módszerek, melyek képessé tesznek, hogy jobb legyél, a projektet segítik amin dolgozol.

A TDD nem működik a [nyelvemen | keretrendszeremen | stb.]

Hogyne. Ez csak egy könnyű kifogás. Igen, ezek a szemét programozók sosem voltak segítőkészek. Ez az, fog ez működni!

Ööö, várj egy picit! Mit gondolsz, hány éves a TDD valójában? Egy dolog a Smalltalk közösségtől? Mindjárt kiderül, hogy ez nem egészen igaz.

Nemrég Arialdo Martini írt erről egy blogbejegyzést (https://arialdomartini.wordpress.com/ 2012/07/20/you-wont-believe-how-old-tdd-is/), hány éves a TDD valójában. Olvasd el, az elejétől a végéig, megvárlak.

Meglepődtél? Akárcsak én – bizonyos mértékig. Mindamellett, hogy tény, a TDD-hez hasonló dolgokról először Dijkstra írt a cikkeiben és beszélt róluk az első NATO-konferencián, TDD valójában ennél régebbi.

Szintén fontos megjegyezzük, amit Jerry Weinberg mondott a TDD-ről ebben a Michael Boltonnak adott interjúban (http://www.developsense.com/blog/2011/01/jerry-weinberg-interview-from-2008/).

„Michael: […] Mindkettőről tanultam a veled és más okos emberekkel folytatott beszélgetésben. Emlékszem, egyszer Joshua Kerievsky kérdezett arról, miért és hogyan teszteltetek a régi időkben. Azt mondtad Josh-nak, hogy kénytelenek voltatok tesztelni, mert a berendezések annyira megbízhatatlanok voltak. A számítógépek nem fagynak le úgy, mint régen, tehát mi ma a motiváció unit tesztek készítésére és tesztelésközpontú programozásra?

Jerry: Mi még nem úgy neveztük azokat a dolgokat, mint manapság, de ha megnézed az első könyvemet (Computer Programming Fundamentals, Leeds & Weinberg, first edition 1961 —MB) és még sok más, azóta megjelent munkát, látni fogod, hogy mindig az, ahogy gondolkodtunk, volt az egyetlen logikus módja a dolgoknak. Ezt Bernie Dimsdale-től tanultam, aki pedig Neumann Jánostól.

Amikor elkezdtem a számítástechnikával foglalkozni, nem volt senki, aki programozni tanított volna, így saját magamat képeztem. Azt hittem, ez elég jó, aztán 1957-ben összefutottam Bernie-vel, aki megmu-tatta nekem, hogy az igazán okos emberek hogyan csinálják. Ez először egy kicsit sokkolta az egómat, de aztán rájöttem, ha Neumann is így csinálta, akkor nekem is így kellene.

Neumann sokkal okosabb volt, mint én vagy a legtöbb ember valaha is lesz, és ez azt jelenti, hogy tanulnunk kell tőle. […]

Szóval, a következő alkalommal, amikor a főnököd azzal jön, hogy felejtsd el a unit teszteket, vagy hagyd abba azokat a TDD dolgokat, mondd el neki a Jerry Weinberg történetét, hogyan tanult Bernie Dimsdale-től, aki meg Neumann Jánostól hallotta ugyanezt. Aztán kérdezd meg, nem tartja-e okosabb magát Neumannál.

Ja, és különben is, annak ellenére, hogy a hardvereink jó része egyre megbízhatóbb, a legtöbb szoftve-rünk még nem. Amikor megválaszolod a kérdést, miért adtunk fel valamit, amit Neumann tanított nekünk, a továbbiakban nem fogom elfogadni ezt kifogásként.

Mi van, ha ezek egyike sem működik?

Pár évvel ezelőtt részt vettem egy Code Retreat ülésen Bielefeldben. Egész nap TDD szerint dolgoztunk, hat egymást követő ülésen, mindig töröltük a kódot a végén, hisz igyekeztünk megismerni a TDD-t, és nem egy gyönyörű megoldással előállni egy rég megoldott problémára.

A nap végén tartottunk egy gyors visszatekintést. Mindenki elmondta, mit tanult aznap, és mit fog más-képp csinálni a következő héttől. Az egyik srác előlépett és azt mondta, hogy munkahelyet vált hétfőn, mivel soha nem fogja tudni használni a TDD a jelenlegi munkahelyén. Most, miután ezt megtapasztalta, ő sem akar már mást csinálni.

Igaz, a „változtasd meg a szervezetet, vagy válts céget” kifejezés természetesen vonatkozik a TDD-re is. Ha meg vagy győződve erről a megközelítésről, többé nem akarsz mást csinálni, és a jelenlegi környezeted nem támogatja ezt, nos, lépj tovább!

Forrás: http://www.shino.de/2014/11/02/how-to-sell-tddto-x/#more-3209
Szerző: Markus Gärtner