Minicube

Sziasztok, az én nevem Papp Krisztián és ez pedig a minicube podcast ötödik epizódja!

A mai témánk igen egyszerűnek tűnhet, legalábbis ha az azonos nevű wikipédia oldalból indulunk ki, de mi most a fejlesztésre vetítve fogjuk megvizsgálni ezt. Ugye a dolog nagyon egyszerű, van a jel, van a zaj és a kettőnek van egy viszonya. Nyilván minél nagyobb a zaj jelhez viszonyitott aránya, annál rosszabb a helyzet. Na de hol érdekel ez bennünket?

Hát bizony nem a fórumokon az értelmes bejegyzések versus trollkommentek aránya, habár erre a példára is applikálható. Minket inkább a kód érdekel, amit ugye nem a gépnek, hanem embereknek irunk. Ezért itt is igencsak fontos a zaj, mint olyan. Na de mi lesz itt a zaj? Volt már olyan, hogy megnyitottatok egy kódbázist és csak percekig bogarásztátok, hogy mi történik? Mi miatt lehetett ez? Szar a kód, vágja rá rögtön mindenki. Jójó, de mégis miért az?

Lehet azért, mert félrevezet. Mivel? Pl olyan kommentekkel, amik nem is szükségesek. Nincs hozzáadott értékük, csak a helyet foglalják, tehát ez is csak zaj, amit az agyunk próbál kiszűrni, de ez nem megy könnyen. Hasonló a helyzet a hosszú copyright fejlécekkel is, meg az importok a fájl elején, amiket az IDE már magától eltüntet előlünk, hogy ne is lássuk azt.

Ezek már annyira beleették magukat egyes nyelvekbe, hogy van ahol már nyelvi elem is van rá, mint pl a c#-ban a regionök. Konkrétan megadhatunk régiókat, amiket el tudunk rejteni, mert annyi minden lenne előttünk. Ezzel pedig nevesitett régiókat tudunk létrehozni, amibe aztán mindenfélét belehányhatunk anélkül, hogy a külső szemlélőt ez terhelné.

A kérdés itt az, hogy vajon jó-e az, hogy már nem csak az IDE, de maga a nyelv is ad eszközöket erre? Egyik oldalról jönnek az olyan checkstyle szabályok, hogy ne legyen hosszú a fájl, aztán jön az, hogy dugjuk el az importokat, amik aztán maguk 40-50 sort is elfogalhatnak, meg dugjuk el a régiókban levő dolgokat, amik szinte kiáltják, hogy ebből baj lesz. Aztán bumm, 600 soros osztályokat gyártunk. Az importok amúgyse ok nélkül kerültek be a fájlba. Ha sok van, akkor az azt jelenti hogy a fájlnak sok a függősége, ezzel instabillá téve azt, de ez már egy másik téma.

Na de tegyük fel nincs rengeteg import, meg nincsenek kommentek, amik hibásan azt irják le mit csinálnak és nem azt, hogy miért. Miféle zaj lehet még a fájlban? Metódusok, amiknek semmi közük ahhoz, amit mi épp meg akarunk oldani. Ezért is fontos, hogy valamiféle sorrendiség legyen benne és azok a függvények vagy metódusok, amik egymást hivják sorban legyenek. Nyílván van kódnavigáció, de több sort látunk egyszerre és jó lenne, ha amit látunk az összetartozó és lényeges. Persze itt elő is jön a sokszor félreértelmezett single responsibility is, csak kicsit más szemszögből. Ami nem oda tartozik, azzal ne is terheljük a saját agyunkat.

Ide tartozik még a pattern driven development, amikor úgy érezzük, hogy fú, de kipróbálnánk az xy tervezési mintát, de hol kéne azt… Hát persze, hogy az éles kódban, amivel aztán majd más is fog szívni. Ebben az a legjobb, hogy elkezdjük lefejleszteni a dolgot, a nulladik időpillanattól kezdve az adott mintát használva, még ha nem is oda való és aztán ebből lesznek azok a singletonok, amiket utólag cserélni lehet, mert nem is singletont akartunk, a visitorok, amik egy elemet járnak be, meg a builderek, amik igazából factoryk, meg a factoryk, amik igazából egy osztályba rejtett new statementek. Folyamatosan megtévesztjük az olvasót, mert az amit lát, nem szolgál semmiféle értéket.

Majdnem elfelejtettem azt, amire igencsak tudok ugrani, főleg reviewkon. Lehet csak engem zavar, de ha egy fájl nincs megformázva, valahogy az is képes elterelni a figyelmem és megnehezíti az értelmezését. Itt egy behúzás, ott kicsit más, itt van space, amott hiányzik. Nem csak a szépérzéket triggereli, elhihetitek. A másik kedvenc még az impl utótag, ami ugye azt hivatott közölni, hogy ez az implementációja valaminek, de nem tudtunk jobb névvel előállni, hogy mégis miféle implementációja is, így odabiggyesztjük ezt. Fontos? Fontos tudni, hogy ez egy implementáció? Ha az, akkor nem lenne jobb azt tudni, hogy mégis miféle, hiszen elvileg többet ilyet is akarunk, ha interfész mögé tettük.

Persze nem csak a kódban lehet zajforrások után kutatni. Vegyük mondjuk a ticketing és projektmenedzsment eszközöket. Igen, most inkább a PM-ekhez szólnék. Mondjuk az gyakrabban probléma, hogy az adott hibajegy hiányosan van kitöltve, de most ebbe ne menjünk bele. Inkább azt nézzük, amikor fogják és a panaszkodó ügyféltől kapott mailt egy az egyben belemásolják.

Mennyi szükséges és mennyi szükségtelen ebből? Hát ha az átlag felhasználót nézzük, akkor simán lehet, hogy az egész csak zaj lesz, az a kis jel pedig totál nonszensz. Leírja, hogy mit reggelizett, melyik oldalról navigált hozzánk, kitalált elemeket emleget, majd azt, hogy aztán kifagyott. Köszi, sokat segítettél.

De nem kell ilyen messze menni a zavaró tényezőkért. Gondoljunk csak arra, hogy mit is látunk alapból egy IDE-ben? Mennyi hasznos és mennyi haszontalan információt is ad? Most megnyitottam és azt látom, hogy plugineket kéne updatelni, a képernyő egy negyedét elfoglalja egy hatalmas toolbar, benne egy hibaüzenettel, a másik negyedét a fájlböngésző ablak, és kb a képernyő felében van ténylegesen kód. Ha ebben a kódban még van egy rakás zaj, akkor sok sikert a hatékonysághoz.

Ez volt a minicube podcast, ha tetszett a rész, akkor irjátok meg a [email protected] cimre, addig is, találkozunk legközelebb!

Hosted on Acast. See acast.com/privacy for more information.

Sziasztok, az én nevem Papp Krisztián és ez pedig a minicube podcast negyedik epizódja.

A minap a teraszon olvasgattam Uncle Bob Clean Agile c. könyvét, aminek a végefelé találtam valamit, ami szöget ütött a fejembe. A craftsmanshipről volt szó, és épp a hivatás vs munka témakört tárgyalta, erről pedig eszembe jutott az, hogy eddig is elég nagy ütemben képezték a különböző gyorstalpalókban az embereket, de most a COVID után talán mégjobban beindult ez a gépezet.

Arról, hogy ez mennyire jó ötlet nem akarok most tárgyalni, ellenben kicsit gondoljunk bele ezen emberek motivációjába. Mivel is hirdetik az ilyen képzéseket?

Leginkább a fizetésekkel.

Teljesen természetes, hogy egyes embereknek ez lesz a legfőbb motiváló tényező. Persze egyéb módon is próbálják odacsábítani a dolgozókat a cégek, na meg valakinek már az is elég, hogy egy klimatizált irodában, home office lehetőséggel dolgozhat 8 órában. Amitől én félek az leginkább az, hogy nem alakul ki bennük a szakma szeretete, ami azokban van, akiknél már az első nyolc osztály alatt beakadt a számítástechnika. Sokaktól lehet majd hallani, hogy otthon már egy percet sem foglalkozik vele, hiszen ott már nem akar dolgozni lévén "azt nem fizeti meg senki". Számára a napi nyolc órával véget ér az egész, nem is fog egy perccel sem többet dolgozni, hiszen az teher. Otthon végképp nem fog szakmai cikkekkel foglalkozni, keretrendszerekkel, nyelvekkel játszani. Félre ne értsetek, semmi baj nincs ezzel, amíg nem okoz problémát. Miféle problémára gondolok? Leginkább arra, hogy mennyi ember fog kiégni, aki felugrott erre a vonatra, elkezdi csinálni, de legbelül nem ezt akarja csinálni? Hogy fognak bejárni nap, mint nap a munkahelyre, vagy éppen felcsapni otthon a laptopot a home office alatt?

Pedig fejlődni kell, mert a szakma nem áll meg. Ha egy pillanatra nem figyelünk oda, elrobog mellettünk. Nyílván mondhatjuk, hogy majd a munkaadó belénk invesztál és segit a fejlődésben, de mi van ha mégsem? Mi van ha vállalkozóként dolgozunk? Meg különben is, nem a mi felelősségünk az, hogy fejlesszük magunkat? Persze fogunk mi is gyorsulni, lesz itt is ami idővel szimpla ujjgyakorlattá válik. De az eszközöket, amik akár sokszorosára gyorsithatják a munkát ezzel nem fogjuk megismerni. Lehet velem van a baj, de már kisgyerekként is mindig azt mondogatták, hogy olyan szakmát válasszak, amit szeretek és akkor egy percet sem fogok dolgozni az életben. Szóval szerintem ezt a szakmát is csak akkor lehet eredményesen, hosszútávon végezni, ha az ember szereti azt. Nyílván rengetegen panaszkodnak a különböző legacy kódok és problémás ügyfelek miatt, akik "megnehezítik az életünk", de ezek egyfajta velejárói a szakmának. Ha nem lennének változások a specifikációkban - amiket annyira szeretünk -, akkor nem is szoftvert kellene írni az adott problémára.

Persze tisztában vagyok vele, hogy nem egyszerű az ember idejét menedzselni. Kell egy kis család, barátok, kell dolgozni, szórakozni, pihenni.. alapból se könnyű megteremteni az egyensúlyt, pláne ha az ember még egy kicsit utánaolvasna a dockernek, játszana a kubernetessel, megirna egy hello world-öt Rustban. Na és a kérdés itt az, hogy mitől vesszük el ezt az időt? A pihenésből? A szórakozástól? Netán a barátoktól? Vagy lehet nem is kell semmitől elvenni az időt, mert mindez inkább feltölt bennünket, szórakoztat, mert újdonság, mert érdekel?

Na ezekről nem esik szó, amikor az embert a programozói pályára csábitják. Ez volt a minicube podcast, találkozunk legközelebb!

Hosted on Acast. See acast.com/privacy for more information.

Sziasztok, az én nevem Papp Krisztián és ez itt a minicube podcast harmadik epizódja!

Láttatok már jól működő scrum csapatokat? Igen? Az tök jó, mert akkor kevesekhez tartoztok, akik még jobban tudjátok majd értékelni, ha egy olyat làttok, ami rossz.

De mitől is lehet rossz? Mik is azok a scrum csapatok?

Hàt akik scrumban dolgoznak, igaz?

Na és mi az a scrum? Igazából nem csak a scrumról szeretnék beszélni, hanem mindenről, amit az agile fedőnéven adnak el. Ez az egész a kis csapatok hatékony menedzseléséről szol, leginkább.

Régen kb minden szoftveres projektet úgy közelitettek meg mint paks kettőt és emiatt kb addig is tartottak. Hosszasan tervezték, engedélyeztették, embereket verbuvàltak, aztán ásót ragadtak az emberek és uccu neki. A végén még hosszasan tesztelték, hogy biztos minden klappol, majd átadták.

Egy ilyen beruhàzásnál lehet ez jó megoldás, de képzeljük el mi lenne ha kiderül, hogy az egyik reaktort nagyobbra kéne méretezni. Mindezt akkor amikor màr állnak a falak. Hát garantálom, hogy nem örülnénk neki. De minek is kellene változtatni?

Emelje fel a kezét, aki nem vezet és nem làtott még olyan szoftveres projektet, amiben menet közben vàltoztatni kellett!

De miért kell ilyet? Nos azért, mert szoftvert írunk, aminek ez a legfontosabb jellemzője. Gyorsan tudunk módositani benne és emiatt az ügyfelek gyorsan tudnak reagàlni a piac megváltozott igényeire, konkurenciára és még sorolhatnám. Erre jött az ötlet hogy akkor kis iterációkat csináljunk, amikben gyorsan tudunk reagálni a változásokra, ne dokumentáljunk feleslegsen, hanem inkább működő szoftvert adjunk át, ami működés tesztekkel igazolt, kommunikáljunk egy csapatként, de nem akarom ideidézni a komplett agile manifestot, akit érdekel járjon utána.

Na szóval az alapötlet tök jó, de a megvalósítás… akkor rant on:

Miféle szörnyszülötteket hozott mindez létre? Nos miután ez elterjedt valamikor kétezer elején, mindenki megpróbált felülni a vonatra, ahogy korábban mondtam, a cégek gyorsan akarnak reagálni. Néha talán túl gyorsan is. Emiatt lett igény mindenféle agile coachokra, scrum master gyorstalpalókra ésatöbbi. Gondolhatjuk, hogy mennyire is jól megy ez az egész. Na de mivel van nekem már megint bajom?

Kezdjük az egyik kedvencemmel, a tesztek v. épp a tesztelés hiánya. Tudom, biztos unjátok már, de komolyan, nem viccből emeltem ki, hogy tesztekkel bizonyitjuk, hogy az adott szoftver műküdik. Persze sokan úgy gondolják hogy megoldás az is, ha felveszünk x embert indiából bagóért és majd nyomkodják kézzel.

Ez jól is megy egy darabig, de szép lassan le fognak maradni a fejlesztők mellett. Miért is van ez? Mert a kód és a funkcionalitás csak bővül, emiatt a tesztelendő esetek száma is.

Az elején az lesz, hogy kell egy nap a tesztelőknek a sprint végén. Igen, már visszatértünk a scrumhoz. Utána kell kettő nap. Egy pillanatra nem nézünk oda és a sprintek fele elmegy tesztelésre.

Persze ez csak akkor van, ha minden sprintben akarunk egyszer releaselni, amivel el is jutottunk a mini waterfallhoz. Hangsúlyoznám, hogy a scrum az nem mini waterfall! Persze simán lehet az is, hogy a csapat úgy dönt, hogy nem is olyan fontos sprintenként releaselni, elég ritkábban is. Itt mentünk át végképp waterfallba.

Mi fog itt történni? A tesztelők csinálnak amit csinálnak, jó esetben automatizálnak, aztán amikor eljön a release ideje, lehúzzák a rolót és nekiállnak végignyomkodni mindent, mert az automatizált tesztek nincsenek még kész. Ha kész is vannak, nem bizunk bennük és igy tovább. Mi lesz akkor, ha találunk egy problémát éles környezetben? Ki kéne javitani mert ügyfelektől esünk el. Mindenki eldobja a vakolókanalat és elkezd rajta dolgozni. Na de várunk vele a sprint végéig? Persze, senki nem meri bevállalni, hiszen lehet mégnagyobb bajt okoz, amiről nem tudunk. Ezzel pedig el is mondtam a másik eshetőséget.

Nem mondom, hogy ez ugyanolyan szörnyű, mintha waterfallban nyomnánk, de a lényeg, hogy lehetne ez sokkal sokkal jobb. Ha lennének acceptance tesztjeink, amikkel legalább a happy path le van fedve, a qa pedig hozzáirja azt, amivel szerintük csecsre lehet futtatni az appot és ezek nem csak assert true-k, akkor ki merünk rakni egy új verziót szinte bármikor. Persze ehhez fontos, hogy ismerjük azokat a bizonyos kritériumokat. Na de akkor mit fog igy a tesztelőgárda csinálni? Előre dolgozik. Már akik maradnak, mert igy a munka mennyisége nem fog lineárisan nőni, tehát kisebb létszám is elég lesz. Tehát előre automatizálhatnak és nem ők lesznek betolva a release előtti utolsó pár napba egy rakás feladattal, ami lehet bele se fér, aztán ki tudja mit kell kihagyni belőle.

De túltoltam ezt a témát, menjünk tovább.

Ja igen, a sprint nincs bebetonozva. Ahogy az ügyféloldal, úgy mi is mondhatjuk, hogy állj. Ha valami nem lesz meg, akkor nem lesz meg. Nem szabad amiatt túlórázni, hogy minden meglegyen. A sprint egyik alternativ célja, hogy adatot szolgáltasson a sebességünkről. Ha túlórázunk, hogy valami beleférjen, semmi más nem lesz, mint hamis adatokat szolgáltatunk a product oldalnak, ami miatt később még több feladat fér be a sprintbe a velocity mentén.

Persze nem mondom, hogy tilos túlórázni, mert mint mindenhol, igy itt is vannak kivételek. De ez legyen látható. Ha viszont látjuk hogy nem fog beleférni, szóljunk minél hamarabb. Ne féljünk attól, hogy emiatt veszélyeztetjük az állásunkat. Ha mégis igy van, az a cég, vagy menedzser igazából nem érett még meg, hogy agile legyen. Ha szólunk, az olyan mintha egy veszélyre hivnánk fel a figyelmet. Ha időben teszzük, meg lehet tenni az óvintézkedéseket. Ha nem, akkor az olyan, mint mikor a titanicon felkiáltottak, hogy “jéghegy”, jó hogy szóltak, de már késő. Ha időben szólunk, akkor fel tudják terjeszteni az infót, az ütemtervet tudják megfelelően módositani és lehet semmi nem lesz belőle.

Persze minden product ownernek minden tegnapra kéne, de vajon tényleg ez a helyzet?

Próbáljuk ki legközelebb, hogy hogy reagálnak. Jól mutatja, hogy a vezetés mennyire is állt már át a régi módszerekről.

Áh, a retrospektiv. Ezt is szeretem, igencsak elhanyagolt téma. A scrum csapatok az elején elég gyengén teljesitenek, mert nincsenek adatok, rosszak a becslések, nincs összerázódva a csapat. Aztán szép lassan fejlődésnek indul az egész. De nem csak a becslések és az összeszokás tud fejlődni, hanem a folyamat ami eköré épül. Az ilyenek fejlesztésére szolgál a retrospektiv, amit szeretnek elhanyagolni, vagy leröviditeni. Ebből lesz az, hogy kb felirnak az emberek elemeket, de senkit sem fog érdekelni. Ugyanazokat a problémákat hozzák fel minden héten, de semmi változást nem hoznak. Ha szeretjük feleslegesen tölteni az időnket, akkor ez egy tök jó módszer rá.

Persze a tervezést se hagyjuk ki. Ebben aztán nagyon jók szoktak lenni. Nyilván, ha a sprintek nincsenek bebetonozva, akkor ez a hiba ez propagálódik felfelé is. Emiatt a hosszútávú terveket is valamennyi rugalmassággal kell kezelni. Na itt szokott az lenni, hogyha pl black fridayre kell valami, akkor nem lehet rugalmasan kezelni a dolgot, aznapra meg kell lenni. Teljesen érthető is. Akkor mi erre a megoldás? A kedvencem az volt, mikor egy hasonló helyzetben megkérdezték, hogy hány indiait kontraktor kell hogy meglegyen időre?

Minden projektmenedzser első gondolata az, hogy plusz erőforrással bármit meg lehet oldani. A gond az, hogy ez nem igy van, főleg rövid távon, amig be kell őket tanitani. Ráadásul lehet csak nekem volt ilyen “szerencsém” eddig, de a kódminőségük hagy némi kivánnivalót maga után, de ez egy másik téma.

Na de megkérdezem megint, mi lehet a megoldás? A minőség rovására menjen a dolog? Nem-nem, ezt már megbeszéltük, hogy amint pl teszteket stb elhagyunk, elindulunk egy lejtőn.

Akkor? Bizony a scope-ból kell vágni. Meg kell értetni az ügyféllel, hogy az amit ő akar ebben a formában nem fog beleférni az időbe, tehát valamit vágni kell belőle. Üljünk le és nézzük, hogy mi az amit ki lehet hagyni?

Persze az ügyfél nem enged, túlórák lesznek, rossz lesz a kód, ezzel pedig senki se jár jól.

Na de ennyi volt a rant mára, ez volt a minicube podcast, találkozunk legközelebb.

Hosted on Acast. See acast.com/privacy for more information.

Sziasztok, az én nevem Papp Krisztián és ez pedig a minicube podcast második epizódja!

A mai témánk nem más, mint a TDD, azaz test driven development. Nem sok más olyan téma van, ami ennyíre megosztja a fejlesztői társadalmat, aminek egyik oka az, ahogy mindezt hirdetik. Kicsit olyan, mint a kamu hirdetések, amikkel találkozhatunk a neten: egy egyszerű trükk, amivel megszabadulhat a kilóktól. Három egyszerű lépés, amivel igazán profi fejlesztővé válhatsz. Ugye, hogy így hangzik sokszor? Nincs más dolgod, mint hipp-hopp elsajátítani a TDD-t és minden gondod megoldódik.

Na de tényleg így lenne? És ha igen, akkor miért nem csinálja már mindenki?

Nos leginkább azért, mert ezt a fajta módszertant - ami egyéni, tehát mindenki maga dönti el, hogy használja-e, ellentétben pl a scrummal -, nem könnyű elsajátítani. Maga a tesztelés is egy olyan témakör, ahol habár rengeteg anyag kering a neten, piszok nehéz olyat találni, ami tényleg jó és nem móricka példákkal akarja átadni mindezt. Ha mindezt megfejeljük a TDD-vel, akkor garantált, hogy valami olyat kapunk, amivel később megutáljuk nemhogy a TDD-t, de magát a tesztelést is.

Na de mi is ez az egész TDD? Nem kell túl sok időt eltölteni a szakmában, hogy az ember szembetalálkozzon a fogalommal, de akinek ez még kimaradt, akkor gyors elmondom. Három szabálya van: nem írhatsz addig éles - tehát nem teszt - kódot, amig nem írtál hozzá egy tesztet, ami jelenleg törik, és épp ki akarod javitani. Nem írhatsz annál több tesztet, mint ami épp el fog törni, ebbe beleértjük a forditási hibákat is. A harmadik szabály pedig, hogy csak annyi éles kódot írhatsz, amivel épp megjavitod a tesztet, ami épp törik. Igy elolvasva is kapizsgálhatjuk, hogy mi volt az egyik legfőbb oka annak, amiért nem ugrott rá a szoftverfejlesztő közösség rögtön erre.

Teljesen más workflow ahhoz képest, amit a legtöbben megszoktak. Na meg az első gondolat az lehet, hogy miért írnék tesztet valamíre ami még nem is létezik? Tegyük fel, hogy valahogy túltettük magunkat ezen. Megkaptunk egy egyszerű feladatot, pl egy elfelejtett jelszó funkciót. Mindent mi kezelünk, Semmi sso, keycloak meg hasonló finomság. Ott van előttünk megnyitva az IDE, rákattintunk, hogy új tesztet akarunk létrehozni.. és belefutottunk az első problémába. Mi legyen a neve a fájlnak? Hát lévén az elfelejtett jelszót akarjuk tesztelni, a forgotpasswordtest elég jónak tűnik, nem? Első akadály legyőzve, következő rögtön jön utána: mi legyen a tesztmetódus neve? Valamit oda kell neki írni, hiszen anélkül nem tudunk törő tesztet csinálni. Hát azt akarjuk, hogy működjön, nem? Akkor legyen "itWorks". Ezután pedig jön az, hogy mégis mi bizonyitja, hogy működik? Hát kiküldi az emailt, amíre ha rákattintunk, akkor utána be tudjuk állítani az új jelszót, amivel utána be tudunk lépni. Ezután pedig megprobáljuk ezt az egészet belezsúfolni egy tesztbe, amivel nemhogy a TDD-t, de a tesztelés egyéb szabályait is megszegtük.

Ehelyett meg kellene állnunk és átgondolni, hogy mik is azok a lépések, habár az imént jól össze lettek szedve. Na de a negativ esetekről se feledkezzünk meg, mi van pl. akkor, ha nincs is ilyen felhasználó, vagy hibás a token ami az emailből jön.

Persze itt a legtöbb fejlesztő már el is dobta a billentyűzetet, hiszen kinek van erre ideje? Itt van a feature, egy szusszra lefejlesztem egy óra alatt, utána kipróbálom, működik, akkor minek teszteket írni meg bajlódni ezzel az egésszel? Csak megtöri a flowt és nem is haladok vele. Erre a flowra majd kitérünk később.

Az egyik legtipikusabb válasz, hogy "csukott szemmel is megírom, annyiszor kellett már". Ezzel két probléma is van, először is ha már olyan sokszor megírtad, miért nem emelted még ki egy ujrahasználható modulba, valamint az, hogy valóban csukott szemmel csinálta.

Miért is? Amikor tesztek nélkül implementálunk valami nagyobb modult, a végén pedig kézzel végignyomkodjuk, az kb olyan, mintha egy sötét szobában kezdenénk legózni és csak a legvégén kapcsolnánk fel a villanyt, hogy lássuk mit is alkottunk. Ehelyett megtehetnénk, hogy minden kis apró darab felhelyezése után felkapcsoljuk a villanyt, hogy ellenőrizzük az eredményt. Ha nem tesszük, igen könnyen oda jutunk, hogy kicsit csárén áll a millenium falcon.

Ez nyilván csak akkor megy, ha az a bizonyos villany megvilágitja azt amin dolgozunk, a félhomály nem lesz elég. Tehát megbizható tesztek kellenek. Szintén fontos, hogy ne kelljen elindítani egy aggregátort minden alkalommal mikor fény kell, mert akkor a kutya se fog bajlódni ezzel. Tehát a tesztek gyorsan fussanak le és ne kelljen egy erőmű hozzá.

Persze én se állítom, hogy mindig TDD-ben fejlesztek, mert nem igaz. Ellenben egyre gyakoribb nálam is ez a hozzáállás. Ott éreztem először szükségét, mikor az alkalmazás elindítása hosszú perceket emésztett fel, emiatt végképp nem engedhettem meg magamnak, hogy minden apró módositás után újraindítgassam. Ellenben azt megtehettem, hogy amit tudtam lefedtem tesztekkel és azután próbáltam ki az alkalmazást egy utolsó smoke test erejéig. Ez először a test first volt, hiszen még nem úgy terveztem az alkalmazásom, kis lépésekben a tesztek mentén vezérelve. Csupán volt pár tesztem, amiket előre megírtam, hogy ezeket akarom letudni. Sokan itt megállnak, ami bőven elég, mert már ez is sokkal megbizhatóbb kódot eredményezhet. Viszont kellő önfegyelemmel ezt fel lehet darabolni kisebb lépésekre. Na az lesz az igazi TDD.

Akkor bele akarsz kezdeni? Tök jó! Ha már van egy olyan projekted, amihez akadnak tesztek, akkor nyert ügyed van, mert hozzá tudsz építeni így. Ha nincs ilyened, akkor először a teszteket kell bevezetni és elsajátítani. Ezt ajánlott olyan helyeken elkezdeni, amiket szívás az appon belül kézzel tesztelni. Pl valami speciális bónusz program, ami a fizetés utolsó lépésében jön fel, ha bizonyos termékek benne vannak a kosárban, visszatérő vásárlóknak, akik x hónapja nem vettek semmit. Egy ilyen teszthez megteremteni a valós körülményeket hatalmas szívás, nem?

Akkor képzeljük el, hogy fogjuk azt a kis kódrészletet ami eldönti, hogy bónuszprogramba kerültünk-e vagy sem és kódból meghívjuk, különböző körülményeket behazudva. Mi kell hozzá? Példányosítgatunk, függvényeket hívunk. A francba is, egész nap ezt csináljuk, ez a munkánk, nem? Ha ráérzünk ennek az ízére, akkor egyre több helyen fogjuk alkalmazni, amiket nehéz "végignyomkodni", később pedig azokat is amiket nem. Na és tudod mi a legjobb? Hogy ezt bármikor újra tudjuk futtatni, ha belenyúlunk a kódba. Na de ez miért nem elég? Miért kell ez a TDD is?

Emlékszünk még arra, hogy a TDD megtöri a flowt? Ez részben a lényeg, ugyanis az a bizonyos flow habár gyorsan eredményez működő kódot, semmi sem garantálja, hogy nincs benne hiba. Ráadásul tetemes mennyiség, így utólag a kutya se akar teszteket írni rá. Ehelyett rá vagyunk kényszeritve, hogy újra és újragondoljuk a problémát és annak megoldását. Ezzel ugye fixen olyan kódot készítünk majd, amihez vannak tesztek. Hiszed vagy sem, a tesztek nem a legfontosabbak itt, inkább azoknak a hozadéka. Ugyanis a tesztelt kód általánosságban jobb minőségű, modulárisabb. Miért? Mert az a kód, amit nehéz tesztelni, általában problémás. Itt ugye a folyamat részét képezik a tesztek és ahogy bővül a kód, feltűnik hogy nehezebb tesztelni és fogsz időben ellene tenni.

A lényeg tehát itt is a sokszor ismételgetett mondat, csinálni-csinálni-csinálni. Idővel ebbe is beletanul az ember és eljön az a bizonyos 'aha' élmény, ami után talán máshogy nem is akar az ember kódhoz nyúlni. Persze ahogy az elején mondtam, ez egy egyéni workflow, nem mindenki tudja magáénak. Ez persze nem megy könnyen, ugyanis a TDD az extreme programming, azaz xp környezetben született, amit elég nagy fegyelem jellemzett és megvolt a támogatás a TDD felé. Ez már nemigen jellemző, így akadnak helyek, ahol szinte esélytelen bevezetni.

Kérdés, hogy szükséges-e az adott projekten? Gondoljunk csak valami kis oldalra PHP-ban: egyik monitoron a kód, a másikon az oldal minden szerkesztés után egy oldalfrissités, mindez pillanatok alatt történik, így ha ugy nézzük az illető legalább egy ágat tesztel, még ha manuálisan is. Ez sok esetben még elég is. Micrositeoknál nem lesz semmi olyan amit érdemes lenne tesztelni, nem fogja továbbnőni magát a kód. Vagy mégis? Akkor ki fogja tovább gondozni? Benne mernéd hagyni az elérhetőséged a readme-ben a következő fejlesztőnek, vagy vállalnád hogy tovább fejleszted az oldalt?

Ezzel a gondolattal búcsúzunk, ez volt a minicube podcast, találkozunk legközelebb!

Hosted on Acast. See acast.com/privacy for more information.

Sziasztok, az én nevem Papp Krisztián és ez pedig a minicube podcast, mégpedig annak a legelső epizódja.

Akinek ismerősen cseng a nevem, az tudja, hogy van már egy másik podcast - szintén tech témában -, amiben részt veszek, így jogos a kérdés, hogy minek még egy? Nos kellett egy hely, ahova a saját kis rövidke agymenéseim mehetnek. A hosszabbakra ott a blog, ha tudást akarok átadni, akkor videók, ha pedig tematikára vágyok akkor a letscode podcast, minden más téma pedig ide.

Apropó téma: a mai témánk nem más, mint "az első 100 lépés mindig nehéz". Az ötlet pedig onnan jött, mert mostanában kezdtem el foglalkozni a Vimmel, aki foglalkozott már vele, annak ismerős lehet a tanulási görbéje. Na de miért 100 lépés? Hiszen mindenhol azt lehet hallani, hogy az első lépés a nehéz, nem? Csak addig nehéz, amíg elmegyünk az edzőterembe, míg rávesszük magunkat, hogy elmenjünk futni, a többi már megy magától, ugye?

Nos akadnak esetek, amikor ez valóban így van. Azonban a programozás, hasonlóan a vim szerkesztőhöz, kicsit más. Az ember manapság rengeteg információt talál mindenről a neten, így a szakma öregjei, akik még az internet előtt könyvekből, újságokból, de legfőképp a saját tapasztalataik útján sajátították el azt, méltán gondolhatják, hogy bizony ma már nagyon könnyű dolguk van. Ez részben igaz is, azonban valami továbbra is elengedhetetlen a programozáshoz.

Ez pedig a kitartás.

Mert habár a rengeteg oktatóanyag segítségével el is tud jutni mindenki egy szintig, a legtöbben elfáradnak. Feladják, ahogy sokszor velem és a vimmel is volt. A tanulási görbe egyre meredekebb és meredekebb, egyre lassabb valami újat elsajátítani. Az elején pedig olyan könnyű volt, pikk pakk megoldottunk dolgokat, apró célokra lőttünk, de elragadt minket a hév és egyre nagyobbat akartunk. Vagy éppen a fordítottja történik, hiszen már mindent tudunk ami ahhoz kell, hogy az ügyfeleket kielégítsük, minek fejlesztenénk magunkat tovább, megállunk a lépcsőfordulóban pihenni, aztán ottmaradunk örökre. Pedig sok esetben csak találni kell egy célt, legyen az valami kis egyszerű webes alkalmazás vagy a pet projectünk konténerizációja, a lényeg hogy a cél mindig ott lebegjen előttünk. Sőt, jobban járunk, ha feldaraboljuk a cél felé vezető utat és ezeket a kis darabokat akarjuk midnig elérni. Ha túl távoli a cél, akkor úgy fogjuk érezni, hogy sosem érünk oda és ez könnyen ahhoz vezethet, hogy feladjuk, pedig már lehet közel járunk a célhoz. Ezért fontos, hogy a feldarabolt lépéseket vezessük magunkban vagy valami felületen, trello boardon, akár fizikailag is.

Milyen kis lépésekre gondolok? Ha pl. egy egyszerű felhasználókezelést akarok, akkor daraboljam fel, belépés, kilépés, regisztráció, elfelejtett jelszó, profiloldal. Ha konténerizálni akarok, akkor kezdjük azzal, hogy milyen imagere építek, buildeljük le, majd később ráérünk foglalkozni azzal, hol és hogyan futtatom. Ha úgy érzem, hogy ezek az részfeladatok is túl nagyok ahhoz, hogy még azelőtt megoldjam őket, mielőtt hiányozni kezdene a sikerélmény, akkor daraboljuk tovább. Ha megy az email küldés az egyikben, akkor legyünk büszkék magunkra, amikor a másikban is tudjuk majd ezt használni.

Én hogy csinálom? Vegyük pl. a vim tanulását. Köztudott, hogy a tanulási görbéje borzasztó meredek és pont emiatt sokan kb. ott feladják, hogy ki tudnak belőle lépni. Rengeteg billentyűkombináció, plugin és trükk van, a saját kis script nyelvéről nem is beszélve. Az elején közel se voltam vele produktív, de nyílván nem is éles projekten próbáltam ki, de a fejembe vettem, hogy minden nap egy kicsit fogom használni. Minden nap egy új billentyűkombinációt kipróbálok, olyanok ezek, mint a napi tippek az egyes programoknál. Ha már tudom legalább a cheat sheet felét, akkor jöhetnek a vim scriptek, amiket egy weboldalon szépen fejezetekre bontva megtaláltam. Mindig csak valami apróság. Pedig itt van a gépemen a másik IDE, nyílván csábít, hogy inkább ott oldjam meg, hisz azt már megszoktam, kézre esik. Bármikor leülhetnék a lépcsőfordulóban én is, de inkább kinéztem a következő lépcsőfokot, a következő lépést, hogy afelé haladjak. Aztán szép lassan eljutottam oda, hogy saját plugint írjak, scripteket konfiguráljak benne magamnak, amivel tovább gyorsíthatom a munkát. Mára már nem is térnék vissza - habár a videókon még akad, hogy azt használom, hiszen másokat nem kényszeríthetek a vimre.

Képzeljünk el egy hosszú ösvényt felfelé a hegyen. Minél messzebb van a vége, annál kevésbé tudjuk felmérni azt. Ellenben ha tudjuk, hogy van 100 lépcsőfok és mi már megtettünk ötvenet, akkor pontosan tudjuk hol is járunk, vagy épp milyen tempóban érünk a végére, ez pedig erőt adhat a folytatáshoz.

Ez volt a minicube podcast, találkozunk legközelebb!

Hosted on Acast. See acast.com/privacy for more information.