Original: https://dannorth.net/the-art-of-misdirection/

Vigyázz a varázslóra. Vigyázz, hogyan dob le egy érmét a kezébe, becsukja a kezét, megmutatja a zárt kezét, kinyitja azt egy virágzással, és az érme eltűnt! Mosolyog. A másik kezére nézel. Megfordítja, és ugyanazzal a liszttel kinyitja. Sem ott! Aztán megfogja a kezét, ököllel bezárja, kinyitja és ott van az érme!

Most figyelj újra. Ezúttal figyelje a másik kezét. Ahogy átfordítja a felső kezét és ökölbe szorítja, látja, hogy az érme sokkal kisebb mozdulattal becsúszik az alsó kézbe. Kinyitja az üres kezet, és az alsó kezét felfelé mozgatja. Figyelmen kívül hagyja a nyilvánvaló mozgást. Ehelyett észrevegye, hogyan vezeti az érmét középső ujjai között. Ne hagyja figyelmen kívül, hogyan nyitja meg a másik kezét, és ehelyett látja, hogy diszkréten dobja vissza az érmét az első kézbe. Végül érezze, hogyan csúsztatja az érmét a tenyerébe, miközben bezárja az ujjait. Varázslat? Talán nem. De egy klasszikus illúzió.

A varázslat téves irányba működik. A varázsló kihasználja az ön hajlamát arra, hogy a nyilvánvalóra nézzen, miközben a valódi akció máshol zajlik. Amikor a nyilvánvaló eléggé vonzóvá válik, nehéz elképzelni, hogy máshová nézzen. A közgazdászoknak megvan a neve annak, hogy csak egy helyre nézzenek: Lehetőség Költség hívják. Amit éppen most csinálsz, minden más költségére kerül sor, amit inkább csinálsz, és mindig vannak más dolgok, amelyeket csinálhatsz. De nem veszi figyelembe a többi dolgot, mert elfoglalt vagy a nyilvánvalóra koncentrálva.

A szoftverfejlesztés rejtett költségei

Hogyan vonatkozik ez a szoftverfejlesztési gyakorlatokra? Egy új gyakorlat általában jó szándékú tanácsokkal kezdődik: “Kipróbáltuk ezt a dolgot [stand-up, páros programozás, TDD (tesztvezérelt fejlesztés), diagramok leégett táblái, iterációk, építkezési automatizálás], és ez jól működött számunkra. Talán meg kellene próbálnia is!”

Túl hamarosan mellékelt egy napirend: “Megpróbáltuk ezt a dolgot, és úgy gondoljuk, hogy kereshetünk pénzt, hogy megmutassuk az embereknek, hogyan kell csinálni. Használd, mert működik! Itt egy fehér könyv, amely ezt bizonyítja.”

Mellesleg, ha elolvassa a gyakorlatok listáját és azt gondolja, hogy “de ezek mind jó dolgok”, akkor veled beszélek. Hol nem működik a technika? Mit csinálhatna helyette? Melyek a kompromisszumok, ha ezt az egyik alternatívára választják?

Az elmúlt néhány évben olyan csapattal dolgoztam, amely termelékenyebb volt, mint bármi más, amit korábban láttam. Módszereik a “hagyományos” agilis technikák és az őrült, ellentétes intuitív gyakorlatok keverékét képezték, amelyek kulturális sokkot okoztak számomra. Ki kellett szabadítanom egy begyűjtött bölcsességet, mielőtt elkezdtem volna gondolkodni úgy, ahogy ők.

Próbáld ki ezt a két részből álló feladatot: Gondolj egy olyan gyakorlatra vagy technikára, amelyet szoftverfejlesztéskor használsz, esetleg a kedvenc gyakorlatára. Megvan? Ok, 1. rész: miért csinálod? Milyen előnyöket nyújt Önnek? Valószínűleg néhányra gondolsz. Írd le őket. Most, 2. rész: hol nem használnád, és milyen alternatívák vannak? Írja le mindegyik előnyeit és hátrányait. Várni fogok.

Valószínű, hogy ez a második rész sokkal nehezebb. Ha többnyire negatív vagy ironikus okokat vetett fel az alternatívákra, akkor csak további okokat sorol fel az eredeti gyakorlat alkalmazására. Nem láthatod, hogy az alternatívák felé haladtál. Becsaptak téged!

TDD a reflektorfényben

Példaként a TDD fogom választani, mivel az a leg dogmatikusabban támogatott gyakorlatok közé tartozik, amelyekkel találkoztam, de ezt a megközelítést bárkihez alkalmazhatja. Megvizsgáljuk a TDD – valóban nézzük meg, és megnézjük, fedezhetjük fel, hol világít, és hol nem olyan hasznos.

Ha tesztvezérelt fejlesztő vagy, szánjon egy percet arra, hogy gondolkozzon azzal, hogy hol nem fogja használni, és mit tehetne helyette. Nemrégiben láttam, hogy néhány ember ezt retorikus vagy akár ironikus kihívásként kéri, mintha őrült lenne, ha valaha is fontolgatná a TDD használatát.

A TDD támogatói szerint olyan dolgok vannak, mint például a „TDD lehetővé teszi állandó, magabiztos változtatásokat”. Gyakran így van. “A TDD lehetővé teszi a kialakuló kialakítást.” Talán. “Az automatizált tesztek regressziós csomagként működnek, és megakadályozzák a hibák újbóli bevezetését.” Gyakran megteszik. “A tesztek élő dokumentációként működnek.” Ők tudnak. “A tesztvezérelt szoftver tisztább és könnyebben cserélhető, mint a nem tesztvezérelt szoftver.” Valójában ezzel foglalkozom. Láttam sokkoló tiszta TDD kódbázisokat, valamint tiszta és életképes kódbázisokat, automatizált tesztek nélkül.

Vessen egy pillantást az alternatív költségekre – a kompromisszumokra – ezen állítások mindegyikében. Mindegyik önmagában is cikk lehet. Csak azt szeretném adni neked, hogy megtalálja a hasonló harapásokkal járó kompromisszumokat.

A folyamatos, magabiztos változás alternatív költsége

Mi nem tetszik az állandó, magabiztos változásnál? Nos, néha leírhatja a problémát, de nem lát egyértelmű választ. A pénzügyi kereskedési alkalmazások nagyon hasonlóak: kipróbálhat többféle megközelítést, és megnézheti, hogyan teljesítenek, mint egy kísérleti sorozat. Azt akarja, hogy minden kísérlet olcsó legyen, így kipróbálhat többet. Az egyes opciók TDD biztosan működni fognak, de drágább lesz, mint pusztán felvázolni valamit, hogy megbizonyosodjon arról, hogy megfelelő-e.

Mennyibe kerül a vázlatok TDD-jével töltött extra idő alternatív költsége? Féltucat ötletet vázolhat fel az az idő, amely bármelyikük TDD-jéhez tart. És azzal nem ér véget. Egy kísérlet eredménye megváltoztathatja a probléma megértését annyira, mint egy lehetséges megoldás felkínálása, amely új, váratlan irányba vezet. Néhány TDD-képviselõ azt állítja, hogy ez egy tüske-sorozat, és ezeket nem kell megtennie. Arra gondolok, hogy a szoftvert teljes egészében a termelésbe helyezzem, és a sikeres kísérleteket termelési szoftverként tartom fenn, tehát ez nem igaz.

A TDD rögzíti a kívánt végcélra vonatkozó feltételezését. Feltételezi, hogy tudja, merre tart, vagy legalább honnan indul. Ha nem tudod, hogy a megoldás miként is néz ki, ez nemkívánatos stratégia lehet. Lehet, hogy el kell halasztania a megoldásba történő befektetést, amíg nem tud többet a problémáról.

A megjelenő tervezés alternatív költsége

Időnként a megfelelő formatervezés nem úgy néz ki, hogy az arcodba kerül. Szükséges lehet egy perspektívaváltás, az egész előfeltétel újraértékelése, hogy az egyszerűséget látszólagos bonyolultságon keresztül lássa. A TDD a növekményes változásokról és fejlesztésekről szól. Kiválóan alkalmas helyi maximumok megkeresésére, de a legjobb megoldás radikális átgondolást igényelhet. Az alternatív költség ebben az esetben az, hogy becsapódunk ebbe a helyi maximumba, és hiányzik egy nagyobb nyeremény. Lean szempontjából ez a különbség a kaizen, a folyamatos fejlesztés és a kaikaku, a hirtelen átalakulás között. A másik nélkül sem sikerülhet, de inkább a kaizenre koncentrálunk, mint az optimalizálás egyik formájára.

A TDD a kaizen programozásának példája. Ahhoz, hogy ragyogjon, olyan környezetre van szüksége, ahol vissza tud lépni, mentális sétára járhat a blokk körül, visszatérhet, és talán mindent megváltoztathat. Szüksége van átfogó jövőképre, „nagy kép” kialakításra vagy építészetre. A TDD ezt nem fogja megadni. A komplex viselkedés robusztus megvalósítása azonban előnyös lesz a TDD által alkalmazott fokozatos megközelítésben. Észre fogja venni, hogy nem azt javaslom, hogy ne használjam a TDD-t, hanem azt, hogy miért és hogyan hatásos.

Nem azt írja, mert szoftvert akar, hanem szoftvert ír, hogy képes legyen rá. Több nemrégiben alkalmazott alkalmazásnál eljutottunk arra a pontra, ahol átírtuk a rendszert, hogy új képességet adjunk hozzá. Nehéznek tűnik, soha ne pazarolja az időt, de amire megtanultunk odajutni, ahol azt mondták nekünk, az sokkal hatékonyabb lenne – gyakran más technológiával – újraírni az alkalmazás azon részhalmazát, amely a valós értéket tartalmazza. Az egyik rendszer Scala-ban indult és darabonként mozog a Java-ba (biztosan rossz irányba!). Egy újabb Python-ban indult, és átkerült a JavaScriptre és a node.js. Még egy újabb Python-ban indult, és átírták egy másik Python-alkalmazásba! Minden újraírás annak eredményeként jött létre, hogy a szoftvert az emberek, a mûveleti emberek, valamint a felhasználók elõtt hozzák létre, és válaszoltak visszajelzéseikre. Ebben az összefüggésben nem volt jelentősége, hogy megalkotott vagy tesztvezérelt volt az eredeti kód, mert nagy részét eldobtuk.

Nem túlzottan fektettünk be a szoftverbe azáltal, hogy átfogó automatizált tesztekkel vesszük körül, különben drága feladat lett volna. De mi a túlélõ szoftver? Megállapítottuk, hogy a tényt követően TDD minőségi szinteket lehet előállítani. Tudjuk, hogy néz ki a jól bevált szoftver, és ebből a szakaszból tudtunk, hogy készek vagyunk befektetni ebbe a szoftverbe: ez bizonyította értékét. Így elkezdtük a TDD-stílusú tesztek bevezetését a kód bonyolultabb vagy kritikus részeire, ami arra késztett minket, hogy a tesztelhetõség érdekében átvizsgáljuk, ami természetes varratokat és alrendszereket hozott létre a kódban, ami nagyobb refaktorokhoz vezet, és így tovább. Ezt a technikát Tüske és stabilizátor – ként írtam le: szerezzen valamit, bármit, a gyártásba, hogy gyors visszajelzést kérjen, és fektessen be minden, ami túlél.

Az automatizált tesztek alternatív költsége

Az automatizált tesztek biztosítják, hogy a kód mindent megtegyen. Ez két kérdést vet fel: Van-e más módja annak, hogy megszerezzék ezt a bizonyosságot? És az értékbiztosítás még értékes?

Az automatizált tesztek alkalmasak bizonyos kóddarabok gyakorlására. A tesztek nélkül észlelne hibákat ebben a kódban? Nem segíthet a hiányzó vagy nem csatlakoztatott beküldés gomb észrevétele. Mi az, ha az alkalmazás félbeszakad az adatok lekérése során? Miután kódolta, hogy megteszi, valószínűleg leáll-e? Az automatizált teszt további bizonyosságot nyújt Önnek? Mit tehetsz ennek helyett?

Az automatizált teszt értéke számos dolog függvénye: a kód kritikája, a rossz dolog bekövetkezésének hatása, a rossz dolog kijavításának költsége, amely lehet hírnév és operatív szempontból is, valószínűsége, hogy Ön ha nem tapasztalja meg rendszeresen a fejlesztés során, a domain ismerete. A rendszer szélén található kódot gyakran nehezebb tesztelni, mint a belső kódot. Az UI-kütyü, a külső integrációs pontok, a harmadik féltől származó szolgáltatások automatizálása drága lehet. Indokolja-e a költség az értéket? Megint nem azt mondom, hogy nem ezt tennék, hanem megkérdőjelezem a kompromisszumokat, és el kell döntenem, hol van értelme. Láttam, hogy a csapatok heteken át fejlesztették a fejlesztési erőfeszítéseket, és gyönyörű, automatikus tesztkészleteket hoztak létre, amelyek szinte semmilyen további bizonyosságot vagy visszajelzést nem adtak az alkalmazás használatával kapcsolatban. A jó hírnévvel járó költségek: elveszítik hitelességüket az érdekelt felekkel szemben, akik jobban szeretnék látni a szolgáltatásokat. Megint meg kell találnia az egyensúlyt, megértve, hogy az automatizálás miért értékes és hol szokás.

A tesztek alternatív költsége élő dokumentációként

Sokféle dokumentáció létezik. Értékes dokumentáció oktat téged. Azt mondja neked olyan dolgokról, amelyeket egyébként nem tudna, mert nem egyértelműek. Szeretné tudni, mi különbözteti meg ezt a rendszert az összes többi hasonló rendszertől, amelyet látott. (Megkérdezheti azt is, hogy miért dokumentálja ezeket a mókákat, ahelyett, hogy eltávolítja őket a rendszerből, és csökkentené az újonnan érkezők meglepetésének szintjét, de ez egy másik történet.)
Néhány automatizált teszt inkább a történeti dokumentumokat olvassa, és betekintést ad a múlt idejébe. Talán egy pillanatban volt egy buta hiba, ahol a jelenlegi állapot frissítése e-mailt küldött a hátsó irodába. Természetesen azonnal észrevették, így a fejlesztők írtak egy tesztet, melynek címe: „Nem szabad e-mailt küldeni a hátsó irodának az aktuális állapot frissítésekor”. Mit? Természetesen nem kellene. De az idő múlásával sok ilyen „természetesen nem” teszt halmozódott fel, növelve a zajt a jel között, így nehezebb megtalálni az igazán hasznos élő dokumentációt. Az élés nem szinonimája a hasznosnak. Az élő dokumentáció kurálása – automatizált tesztek – ugyanolyan fontos tevékenység, mint bármely más típusú dokumentáció kurálása. Túl gyakran figyelmen kívül hagyják.

Következtetés

Miközben ebben a cikkben a TDD összpontosítottam, hasznos az alternatív költségek és a kompromisszumok azonosítása minden gyakorlat és tevékenység során. A TDD értékes és fontos fejlesztési technikának látom, de vannak olyan körülmények, amelyekben ragyog, és mások akadályozzák azokat. Tehát ne vegyen semmit névértéken, és inkább keresse meg a kompromisszumokat minden döntésekor, mert ezek a kompromisszumok vannak, függetlenül attól, hogy látod-e őket. És ha megtanulja észrevenni őket, akkor mágia is megtehető.

Történelem: ezt a cikket először tették közzé The Developer magazin szám # 2/2012 és mint a pdf letöltés.

Daniel Terhorst-North