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

A mostani részt a legutóbbi két háztáji fejlesztésem ihlette, amik közül az egyik már elég régóta elindult. Nem tudom ti hogy vagytok vele, de én piszok lustának tartom magam, legalábbis ha egyszerű, favágó munkáról van szó, különösen ha mindez monoton és többször is meg kell ismételni.

Anno amikor először munkaidőben fejlesztettem, még nem is fejlesztői munkakörben, az is egy ilyen feladatot hivatott kiváltani. Végtére az ipar legnagyobb részében azért írunk szoftvereket, hogy emberi munkát váltsunk ki vele, na meg excel táblákat. Pontosan ez történt akkoriban is, volt egy szoftver, ami megevett egy excel táblát és egy htmlt köpött ki magából, amit aztán lehetett is kinyomtatni és odaadni a termelőknek. Ezzel csak az volt a gond, hogy a programban voltak hibák, emiatt gyakran kellett belenyúlni a kimenetbe, de persze ehhez még számolgatni is kellett. Kb a tizedik ilyen után megelégeltem és nekiláttam írni egy kis sciptet, ami elvégezte ezt az utólagos kozmetikázást. Persze mindezt nem alaptalanul, ugyanis ez évről évre előjövő probléma volt, ugyanis a téli időszakokat a fejlesztési osztály leginkább ilyenekkel töltötte, ezért úgy éreztem a belefeccölt idő megtérül, arról nem is beszélve, hogy adott egy célt, ami mentén kódolhatok és sok olyan rész is volt itt, ahol újat tanulhatok. Excel táblák kezelése, batch feldolgozás, PDF generálás, stb. Ráadásul mivel egyszemélyben voltam a megrendelő és a fejlesztő is, így kellően motivált is voltam, hiszen tudtam, hogy mennyi munkától fogom megmenteni magam és a kollégákat is. Utóbbi csoport pedig biztos hálás is lesz mindezért, ami sosem árt egy munkahelyen. Ez persze eléggé megrészegített, emiatt utána el is határoztam, hogy teljes időben ezzel akarok foglalkozni, amit ott sajnos nem lehetett, így váltottam is. Ez viszont már egy másik történet.

Persze ez később is megmaradt bennem, hogy amit lehet és megéri, azt oldjak meg automatizáltan. Hogy miért mondom, hogy megéri? Mert ha valamivel napi 1 percet töltök, de automatizálni 3 nap munka lenne, akkor annak az automatizálásnak a megtérülési ideje olyan hosszú, hogy valószínűleg bele sem vágok, maximum a kihívás miatt.

Mivel elég sok kis apró projektem van, amiket használok is, ezért a hozzájuk tartozó build és akár deploy folyamatot is részben vagy teljes egészben egy CI szerver - esetemben a jó öreg jenkins - által futtatott scriptek és/vagy erre hivatott eszközök oldják meg. Nemrégiben pont szembesültem azzal, hogy mi is van akkor amikor ez kimarad. Van ugyanis egy régi mobilapp, amit fejlesztettem és ehhez évről évre hozzá kell nyúlni, de igen ritkán. Ennek a buildeléséhez és digitális aláírásához csináltam egy scriptet, tehát az első és legfontosabb lépés már megvolt. Viszont pont amiatt, mert ritkán kell használni nem oldottam meg, hogy Jenkinsen is fusson, hiszen úgy gondoltam ez a kis script elég. Ám időközben újratelepítettem a gépem, emiatt a script habár ott volt, de a megfelelő eszközverziók már kevésbé. Így amikor a legutóbb kellett volna felrakjam, akkor szomorúan konstatáltam, hogy az eszközök már nincsenek meg a gépemen vagy nem olyan csillag eggyüttállásban, amivel ez működne. Úgyhogy a vége az lett, hogy dockerizáltam ezt is és mostmár jenkins futtatja ezt is. Persze ezek nem feltétlenül olyan problémák, amikkel bárki találkozna, hiszen ehhez hobbiprojektek kellenek, vagy saját vállalkozásban kell űzni az ipart.

De tudnék említeni még egyéb példákat is a közelmúltból. A videós oldalamon az egyes sorozatokhoz és a videókhoz is tartoznak bélyegképek. Az oldal indulása idején még úgy voltam vele, hogy saját magam szerkesztgetek képeket az egyes részekhez, de ez hatalmas effort volt, főleg úgy hogy annyira nem is értek hozzá. Emiatt a következő lépés az volt, hogy csak az egyes sorozatokhoz készül kép, az egyes videók pedig ezt a képet megöröklik és csak egy kis szöveget cserélek rajta. Ez utóbbi cserét gimpben kb két perc alatt elvégzem, ami nem nagy idő, de továbbra is ott a hibalehetőség, hiszen egy ember - mármint én - csinálja mindezt. Arról nem is beszélve, hogy lassan 400 videó van fent az oldalon, ha két perccel számolunk, akkor már több, mint egy munkanapot töltöttem el azzal, hogy képekre írogatok szöveget. Persze ezt nem vártam meg, hanem már hónapok óta egy kis PHP script és a gd-text csomag segítségével csinálom meg mindezt. Hasonló a helyzet a videókkal is. KDEnlive-al vágom meg a videókat, amiket utána fel kell tölteni vimeora, utána láthatósági szabályokat és egyebeket beállítani. Időigényes, meg kell várni mire a program kiköpi magából, utána ki kell várni a feltöltést, mielőtt tudnám a vimeon szerkeszteni azt, sorolhatnám. Így már ezt is egy script tölti fel, ami figyeli a KDEnlive mappáját, sőt utána értesítést is küld. Ezután tudom csak a videóoldalon létrehozni az új epizódot, amit facebookra - ki nem találnátok - automatizmus posztol.

Na de ez még mindig egy kézzel futtatott script, aminek jó bemeneteket kell adni. A készült képet pedig fel kell tölteni az oldalra. Talán itt csúcsosodott ki igazán a “lustaságom”, ugyanis a vége az lett, hogy a sorozatok létrehozásakor töltöm fel a bélyegkép sablonokat, mind az oldalra, mind pedig a facebook megosztáshoz. Amikor új videót hozok létre, akkor elég beírni, hogy pontosan mit is akarok a képre írni, az pedig legyártja a sorozat sablonja alapján, optimalizálja és CDN-re fel is tölti a képeket helyettem.

Hasonló a helyzet az ingyenes videókkal, amiket youtube-ra is feltöltök. Ezt is meg lehet csinálni kézzel, feltölteni, címet, címkéket, leírást beállítani. Ez is inkább időigényes, meg macera, ráadásul ha utólag akarok valamit ingyenessé tenni - és sok ilyen is van -, akkor elő kell keresnem. Ehhez pythonban írtam egy kis flask appot, amivel ezeket az integrációkat kezelem a videóportál admin felületéről. Egy gombnyomással. Ez egyelőre még mínuszos, ha a spórolt és a belefeccölt időt nézzük, de leginkább azért, mert a pythont, flaskot és a köré épült eszközöket gyakoroltam vele, de ez megint csak az én “perverzióm”.

Ezt az automatizálás témát persze nem csak én súlykolom, hiszen manapság akad, amit lehetetlen automatizmusok nélkül elképzelni, az egész devops kultúra erre épül. Arról nem is beszélve, hogy mára már külön szolgáltatások is vannak automatizálásra, mint például a zapier. Ezzel rengeteg különféle appot tudunk összekötni különféle módon, slacket a google cloud printtel, Youtube-ot a Vimeoval és még sorolhatnánk.

Úgyhogy ha legközelebb azon kapjátok magatokat, hogy valamit már sokadjára csináltok meg, unjátok és tudnátok hasznosabban is eltölteni ezt az időt, akkor kis fejszámolás után lehet az első ilyen alternatíva az lesz, hogy kiváltjátok ezt a feladatot valamilyen automatizmussal.

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

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

Mitől lesz valaki jó programozó? Sokan feltették már ezt a kérdést és sokan meg is akarták válaszolni. Még éppen nekem is zajlik egy ilyen kampányom, amivel a videóportált szeretném népszerűsíteni egy rövid kérdőívvel: Vajon jó programozó válna belőled? Mondanom sem kell, hogy elég vegyes reakciókat vált ki, aminek az oka nem titok: egyetlen logikai vagy matek kérdés sem szerepel benne. A kérdések a kitöltő elhivatottságára, kitartására vonatkoznak. Na és akkor itt fogtok felhördülni Ti is, hiszen az összes ilyen tesztben matek és logikai feladatok szoktak lenni, nyílván okkal, ugye?

A kérdőív nem is az én szüleményem, hanem Angela Duckworth kutatása, aki két tulajdonságot vizsgált, amik szükségesek a legtöbb cél eléréséhez. A tanulmány szerint azok, akik hosszú távon is képesek tenni egy célért és megvan az önuralmuk ahhoz, hogy ne térjenek el ettől különféle pillanatnyi ingerek hatására sem, azok tudják elérni a céljaikat és sikeresek lenni. Na de hogy jön ez az egész a programozáshoz? Azért, mert a programozás tanulása sosem ér véget. Folyamatosan fejlődik, bővül. Mintha a szorzótáblát nem 10x10-ig tanulnánk meg, hanem a végtelen x végtelenig. Pont ezért kell hozzá rendkívül sok kitartás, még azoknak is, akiknek jobb képességei vannak, hiszen lehet ők gyorsabban haladnak előre, de ha az út nagyon hosszú, kitartás nélkül ők is feladják. Fókusz nélkül pedig hiába lenne jó képessége, minden mással fog foglalkozni tanulás helyett.

A másik ilyen, hogy akárki akármit mond, a matek egyre kevésbé része a szakmának. Persze vannak területek, ahol igen, így ha az ember például kriptográfiával akar foglalkozni, akkor nem ússza meg mindezt. Viszont a piac hatalmas és rengeteg olyan része van, ahova nemigen kell több annál, mint amit egy 8 osztályban összeszed az ember.

Persze ez lehet csak duma, de aki hallgatja a Letscode podcastot, az talán emlékszik arra, hogy meséltem egy biztonsági őrről, aki nem sorozatok nézésével és facebookkal töltötte el a munkaidejét, hanem megtanult programozni. Hát de biztos csak valami kis cégnél tudott elhelyezkedni, azt is csak protekcióval, ugye? Nem éppen, nagy nevű multinál. Mindezt úgy, hogy hétszámjegyű fizetést kapott évekkel ezelőtt.

Mi kellett hozzá? Matektudás? Logika? Aligha. Inkább végtelen sok kitartás, eltökéltség, hogy a munkaidejében ne valami agyatlan játékkal teljen az idő, hanem a tanulásra tudjon koncentrálni. Lehet erről is kellene egy felmérés, hogy kinek milyen szintű matek tudásra van szükség a szakmában.

Persze hozhatnám a saját példámat is. Én programozni a szabadidőmben tanultam meg, nem kellett hozzá semmiféle gyorstalpaló - hiszen akkoriban még nem léteztek -, se mások noszogatása. Rengeteg oktatóvideót, előadást és hasonlókat néztem meg. Mivel növényorvosként dolgoztam és a mezőgazdaság télen igencsak áll, sokszor mindezt munkaidőben, így előnyben voltam azokhoz képest, akik egy 12 órás műszak mellett akarnak ilyesmit. Nekik ez a folyamat hosszabb és nehezebb lesz, de továbbra sem lehetetlen.

Akkoriban magyar nyelven ezek nemigen voltak elérhetőek, ezért már az elinduláshoz is kellett az angol. Ma már némileg jobb a helyzet, de az angol nyelv továbbra sem nélkülözhető. Viszont a legtöbb helyen elég, ha az ember érti az írott szöveget, nem mindenhol kell beszélni is azt. Ehhez pedig mi kell? Nyelvérzék, ugye? Vagy kitartás?

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

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

Ma egy kicsit a manuális tesztelőkről fogunk beszélni, illetve arról, hogy mikor és mit nyomkodnak éppen és miként lehet tönkretenni a munkájukat egy tollvonással. Hogy szemléltessem, vegyük például Bélát, aki manuális tesztelőként dolgozik egy nagynevű multinál. A csapatában és az egész projekten úgynevezett SCRUM szerint dolgoznak, ami a valóságban inkább egy egy mini waterfallnak felel meg, de ebbe most ne menjünk bele. Maradjunk annyiban, hogy próbálnak kéthetente releaselni egy új verziót.

Ezeket a releaseket sikerül is tartaniuk, ami a mai világban - ahol egyesek percenként, mások meg évente releaselnek - ez még igen jónak számít. Minden ilyen iteráció hétfőn kezdődik és a következő hét péntekig tart. Béla két hete úgy néz ki, hogy eldöntik mik is férnek bele ebbe a két hétbe, a fejlesztők elkezdenek rajta dolgozni, a tesztelők is elkezdik összerakni a teszt planeket, amik leírják hogy miként lehet letesztelni az adott új featuret. Közben persze a product oldalt és fejlesztőket is folyamatosan nyaggatják, hiszen mindig lehetnek fekete foltok a feladatokban.

Az egyes featureök külön branchen kerülnek fejlesztésre, a fejlesztők pedig amit tudnak automatizáltan tesztelnek, de közel sem end-to-end. Ha valami kész van, akkor megy be master branchre, ez pedig kikerül egy tesztkörnyezetbe, lehet is nyomkodni a tervek alapján.

Ekkorra általában a két hétből már egy eltelt, így a tesztelőknek van egy hetük letesztelni ezt. Hogy biztos legyen elég idő, a második hét keddi napja az utolsó, hogy kód bekerülhet a masterbe, ekkor kezdődik az úgynevezett feature freeze.

Ez tök jó, de Béla nem ma kezdte, szóval kedden délelőtt talál valami turpisságot, amiről kiderül, hogy biza egy bug, mégpedig nem is kicsi. Ez így nem mehet ki, meg kell javítani. Meg is kapja a fejlesztő a nemes feladatot, hogy javítsa meg, de vészesen szorít az idő, ráadásul a feature freeze már életben van.

Sebaj, mert a feature freeze nem érvényes a hibajavításokra, arra ott van a code freeze, ami szerdán van. A fejlesztő megtolja az igát rendesen, be is kerül a javítás masterbe, el lehet kezdeni tesztelni. Ezúttal szerencséje volt, Béla se talál kivetnivalót a featureben, így pénteken terv szerint kimegy a release, amiben már benne van a hibajavítás is.

Aztán vasárnap csörög a telefon valakinél, ugyanis nagy baj van, mert a korábbinál még nagyobb hiba került a rendszerbe. Hát mégis hogy lehet ez? Hiszen a többi csapat tesztelői is tesztelték az alkalmazást.

Igen ám, de melyik verziónak és mely részét tesztelték éppen? Ugyanis amit a hét elején teszteltek, az nem ugyanaz volt, mint kedden, vagy a fejlesztőnk módosításai után, hiába halasztják a regressziót a végére.

Mit kellett volna tenni? Halasztani a releaset? Hát azt nem szeretik a menedzserek.

Esetleg tesztelni külön feature branchen? A feature brancheket kirakni külön teszt környezetekbe és ott le lehet tesztelni. Működhet, de mi a garancia, hogy a módosítások nem akadnak össze valaki máséval a masteren és nem okoznak valami galibát? Sőt, ha már galiba, leteszteli a feature branchen a Béla, rámondja az áment. Frankó, mergeljük be… de valaki megelőzött és most rá kell húzzam a mastert. Ha nincs conflict, az még a jobbik eset, de ha van akkor végképp más szoftvert fogunk kireleaselni, mint amire Bélánk áldását adta.

Megvan, revertáljuk a commitokat! Működhet, csak akkor megint visszajutunk oda, hogy a revert mit okozhat? Mikor fog ez kiderülni? Ugyanez a helyzet azzal, hogy cherry pickelgetünk.

Feature flagek! Ez lesz a megoldás, ugye? Már majdnem jó, de csak bizonyos esetekben működhet, mikor egy teljesen új funkcionalitást tudunk vele ki/be kapcsolni, hiszen ha valami korábbi logikában valami kapcsoló, akkor a kikapcsolt állapot is rejthet meglepetéseket.

Toljuk el a releaset pár nappal, ez még belefér, nem? Na igen, húzzák a szájukat a menedzserek, de ha nem létkérdés, talán benne vannak. Cserébe felborul a rend és ki tudja hány ember számára rövidül meg ez a két hetes periódus. A keddi feature freezeből szerdát akarnak a fejlesztők, a tesztelők pedig inkább hétfőt, hiszen nekik még az elcsúszott release után kell feltakarítani.

Ráadásul minden külső függőség újabb csúszás forrása lehet. Tegyük fel, hogy egy másik csapat, aki egy olyan szolgáltatást fejleszt, amit mi használnánk az új featureben nem készül el időre és a projektmenedzser közli, hogy ezt meg ezt ki kéne venni a releaseből. Éééés bumm, kezdődik az egész előlről.

Arról nem is beszélve, hogy ahogy hízik az alkalmazás és egyre több funkcionalitás kerül bele, a regressziós tesztelés ideje egyre csak nő és nő. Persze felvehetünk még több tesztelőt, de akkor mit fognak csinálni a hét elején? Mert amit akkor nyomkodnának már nem lesz ugyanaz, mint ami pénteken kikerül, akkor pedig mit is teszteltek?

De most komolyan nincs erre megoldás? Dehogynem, csak ahhoz bizony a manuális tesztelés kevés. A tesztelőknek is automatizálniuk kell, legalább részben, hiszen amíg a regresszió is kézzel zajlik, addig bármikor bármi történhet az ilyen-olyan csúszások miatt, hiszen emberek vagyunk.

Na de hogy és mit fognak ők automatizálni? Pontosan azt, amit eddig is csináltak, a felület nyomkodását, legyen az valami desktop alkalmazás, weboldal, vagy épp mobilapp. Ráadásul, ha a tesztesetek megfelelően voltak dokumentálva, akkor igen gyorsan össze lehet ezeket rakni, hogy aztán bármikor el lehessen indítani egy folyamatot, ami odanavigál az oldalra, végrehajtja ugyanazt, mint amit a tesztelő tett volna és megvizsgálja, hogy valóban azt látja-e, mint amit kellene.

Weben erre való a selenium, amivel a böngészőt tudjuk irányítani. Ha akarjuk futtathatjuk ezt a saját gépünkön, vagy egy úgynevezett headless böngészőben valami szerveren, az eredmény ugyanaz lesz. Ha nemigen van javascript a frontenden, akkor még lehet selenium sem kell, hanem az adott keretrendszer - amiben az oldal íródott - is biztosíthat ere eszközöket, amikkel a űrlapokat tudunk elküldeni és aztán a HTTP választ vagy éppen a HTML-t vizsgálni.

Ehhez persze fontos, hogy a UI olyan módon legyen elkészítve, hogy a gombok, mezők, lényegében bármi amit vizsgálni, kitölteni, megnyomni akarunk egyértelműen beazonosítható legyen. Ha ez megvan, akkor nincs más dolgunk, mint bekötni mindezt a saját kis CI pipelineunkba. Tehát bármikor, amikor pl a masterbe bekerül valami, kirakjuk az alkalmazást egy izolált, stabil környezetbe és utána ráengedjük ezeket a teszteket és megnézzük, hogy minden stimmel-e. Ha nem, akkor bizony jelezzen és javítsuk ki a hibát, ez legyen az elsődleges prioritás. Fontos, hogy ez a környezet ne változzon, tehát mindig ugyanbból az állapotból induljon, takarítsuk ki a db-t utána, ne legyenek fals pozitív ereményeink, ugyanis az igen hamar megrendíti a bizalmat a rendszerben és hamar visszatér a teljes manuál tesztelés.

Na és mi a szerepe a tesztelőknek itt? Nem egyik percről a másikra megy egy ilyen átállás, nyílván az opsnak is van köze hozzá, meg kell hozzá programozni is.

Viszont szép lassan el lehet kezdeni a regresszió elemeit átírni ide, azokat már nem kell a releasek előtt megcsinálni, vagy egyre kevesebbet, aztán el lehet kezdeni az új featureöket is egyre inkább automatizáltan tesztelni és utána már lehet nem is kell várni két heteket a releasere, hanem amint bemergeltük a featuret és zöld lett a build, már lehet is élesíteni azt. Miért? Mert minden buildnél mindent tesztelünk.

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

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

Viszont azon a bizonyos kódon kívül még rengeteg mást kell tudnia egy jó fejlesztőnek. Az egyik ilyen, hogy tudnia kell, mikor nem is szabad nekiállni valaminek, mert nem fog működni. Sőt, ezelőtt nem árt, ha egyáltalán tudja, hogy mit is kell csinálnia, ugyanis az ügyfelek nem a jól meghatározott üzleti igényekről híresek. Tehát azt már látjuk, hogy nem tudjuk elkerülni azt, hogy kommunikáljunk a projekt egyéb résztvevőivel, akik bizony nem fogják megérteni a technikai részleteket. Ezt tudnunk kell lefordítani másoknak, valamint visszafele is, az általuk megfogalmazott igényeket is tudnunk kell valahogy technikai nyelvre fordítani. Ha ez nem lenne elég, ha nem egyéni vállalkozóként dolgozunk, akkor nagy valószínűséggel csapatban, emiatt egymás közt is kell kommunikáljunk. Bizony, a sarokban ülő programozó, aki egymaga fejleszt valamit egy kihalófélben lévő faj. A tudást meg kell osztani másokkal, dokumentációt kell írni - bármennyire nem szeretjük azt -, hiszen gondoljunk bele mi mennyi ilyet olvasunk? Valaki ugyanúgy beletette az energiát előttünk, hogy ne a kódból próbáljuk kitalálni mi is történik, vagy éppen stackoverflow válaszokból összehalászni azt.

Na persze ne feledkezzünk el a meetingekről sem. Itt abba nem mennék bele melyik hasznos vagy éppen haszontalan, ezt cége válogatja, de valószínűleg itt vagyunk a legmesszebb a kódtól, hacsak nem lenémítva kódolunk a másik monitoron közben.

Ha már kód, akkor bizony egymás kódját is át kell nézni, a benne talált hibákat érthetően és lehetőleg nem sértőn megírni a másiknak. De gyakran közösen is kell kódolni vagy éppen hibát keresni, logokat, metrikákat bámulni, hogy megtaláljuk a hiba okát, ha nem esünk rögtön a javításának, akkor mindezt felvinni valahova.

Ha pedig felvisszük valahova, akkor elő is kerülnek a projektmenedzsment rendszerek, ahol szintén sok időt töltünk el.

Képzeljük el, hogy házat akarunk építeni. Van egy elképzelésünk, odahívjuk a kőművest, ácsot, stb. és kiadjuk nekik, hogy ezt kell csinálni, van rá öt nap, ők meg rögtön nekiállnak? Dehogy fognak, hiszen lehet amit elképzeltünk nem is megvalósítható, vagy éppen nem biztonságos, időtálló. Azért ők a szakemberek, hogy megmondják, ha valami szakmailag nem lesz oké. Ők fogják megmondani azt is, hogy mennyi idő alatt lesz kb kész. Ugyanez a helyzet nálunk is, mintha minden egyes ticket a projektmenedzsment rendszerben egy újabb építkezés lenne, viszont nálunk sokkal komplexebb elképzeléseket kell megvalósítani, esetleg azok nem annyira letisztultak, így a konkrét megvalósítás kevesebb időt vesz igénybe, mert inkább nyomozni kell az után, mi is a konkrét feladat.

Ugyanezért fontos ismerni magát az üzletet, hogy megfelelően tudjuk ellátni a feladatunkat. Minél jobban ismerjük azt, annál inkább tudunk testreszabott megoldást adni, hiszen nem kódot szállítunk, hanem egy üzleti megoldást. Annak ismerete nélkül igen nehéz lenne. Az információ hiánya, vagy a félreinformálás bizony nagy galibákat tud okozni, ezzel nekem is van egy igen rossz élményem. Amikor egy olyan funkciót fejlesztettünk, ami a felhasználói fiókok megosztását tette lehetővé és felmerült a kérdés, hogy volumenét tekintve egy felhasználóval hány ilyen fiókot is fognak megosztani. Itt azt az információt kaptuk, hogy pár ilyen lesz majd. Ennélfogva a rendszert úgy építettük meg, hogy ezt feltételeztük. Később, mikor élesítettük, akkor bizony kiderült, hogy ezek inkább 200 fölötti számok, amiknél bizony a mi megoldásunk nem teljesített úgy, mert nem erre terveztük az egészet.

Persze van olyan hely, ahol nem ez a helyzet, hanem az előbb említett abszurd módon gondolkozik a vezetés. Ezekről a helyekről érdemes mihamarabb menekülni. Szóval ha esetleg projekt menedzserek, product ownerek is hallgatják az adást, akkor nekik is üzenném, hogy ahogy a fejlesztők sem csak kódolnak, úgy nekik sem annyi a dolguk, hogy rátolják a feladatot, mindenféle kontextus, háttér nélkül a fejlesztőre és az majd megoldja, hiszen már láttuk az én esetemből, hogy miket eredményezhet.

Jó esetben juniorként nem dobnak be rögtön a mély vízbe és a fenti feladatok nagyját leveszik a vállunkról, de ahogy haladunk előre a pályáján, egyre jobban bele kell magunkat ásni a fenti problémákba. Tehát el kell szomorítsam a hallgatókat, ugyanis senki se remélje, hogy mindig kész, jól megrágott feladatokon kell majd dolgoznia és majd elkódolgat a sarokban egyedül.

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

Az elmúlt időszakban kicsit megakadt a podcast és videókészítés is, aminek az oka roppant egyszerű, ugyanis vizsgára készültem, de igyekszem bepótolni a lemaradást.

A mostani epizódban megint egy kicsit elmélkedni fogunk, ezúttal az interjú folyamatokon. Mindez onnan jött, mert a minap láttam egy gyakorlati repülős vizsgát még régről, ahol a repülés előkészítést és hasonlókat ellenőrizték.

A vizsga során szépen végig kell menni a folyamaton és bemutatni azt, mindezt gyakorlati szemszögből. Sok döntést kell meghoznia a vizsgázónak ezzel és azokat a döntéseket megfelelően meg is kell indokolnia. Ezekből igen hamar kiderül, ha valaki nem látja a teljes képet.

Erről eszembe jutott, hogy volt egy hasonló tárgyam még a mesterképzés alatt, amitől mindenki rettegett. Volt aki csak azért költött el egy vizsgaalkalmat, hogy beülhessen meghallgatni valakit, aki vizsgázik, ugyanis erre nem lehetett a szokásos módon felkészülni, mert hasonló volt, mint egy tantárgyakon és éveken átívelő szigorlat.

A neve is utalt erre, integrált szántóföldi növényvédelem. Nyílván a hallgatók többségének nincs sok köze a mezőgazdasághoz, de a lényeg, hogy nemigen vannak kőbe vésve a dolgok. Tehát nagyon sok tényező határozza meg akár csak a vetésidőt is az adott növény esetében, kezeléseket, stb. Az oktató kedvenc kérdése pedig az volt, hogy “mi a cél?”. Ez pedig szinte bármely kérdésre adott választ meg tud menteni, ha meg tudjuk indokolni azt.

Ha a saját szakmánkra tekintünk, akkor nem hasonló a helyzet itt is? Nem az van, hogy egy adott cél eléréséhez százféle módon el tudunk jutni? Szinte minden technikai döntés mögött van valamilyen ok vagy cél.

Legyen mondjuk a cél egy videómegosztó szolgáltatás. Rengeteg technikai kérdés fel fog merülni a fejlesztés során. Milyen nyelvben írjuk, milyen adatbázis lesz mögötte, a frontendre kell-e valami keretrendszer, ha igen akkor melyik? Hol fogjuk hostolni, satöbbi. Mennyi minden derülne ki a jelöltről, ha ilyen kérdéseket megválaszolna?

Persze egy juniortól nem várhatjuk el, hogy ilyen távolról lássa a dolgokat, ezért az esetükben más módszerekhez kell fordulni. Igaz egyfajta szintfelmérésre is alkalmas lehet, hiszen ha az indoka egy adatbázis mellett annyi, hogy azt ismeri, az sem egy rossz válasz, de máris tudjuk, hogy nem kell nagyon nyüstölni szegényt az adatbázisok összehasonlításával.

Akkor most gondoljunk abba bele, hogy mi hogy felvételiztetünk? Milyen kérdéseket teszünk fel, hogy néz ki ez a folyamat, mi képezi a részét? Tegyük fel, hogy van egy online tesztünk. Mi bizonyítja, hogy az adott ember oldotta azt meg? A személyes körön vagy egy online call alkalmával rákérdezünk erre-arra, hogy kiderítsük az illető írta-e a kódot/tesztet? Simán csak megnézhetjük a rossz válaszokat és megnézhetjük, hogy egy kis rásegítéssel megy-e, ezzel legalább nem csak eldöntendő kérdésekre kapunk bináris eredményt, hanem kicsit belelátunk abba is, hogy az illető jelölt hogy gondolkodik és úgy is érezheti ezzel, hogy van lehetősége javítani, mint egy szóbelin az írásbeli után.

Sajnos a legtöbb interjú teljesen személytelen, kitöltünk valami tesztet, adnak valami feladatot, ami alapján egyik nap felhív valaki, hogy bocsi, nem te voltál az igazi, vagy épp fordítva. Ez alapján már meg se fogjuk próbálni újra annál a cégnél, mert semmi irányt nem kaptunk, hogy vajon mit rontottunk el. Olyan ez, mintha annyit mondanának arra a kérdésre, hogy miért nem feleltünk meg, hogy “csak”.

Természetesen ez lehet azért is, mert rengeteg embert futtatnak át a rendszeren és nem lenne idő mindenkivel személyesen foglalkozni, ezt aláírom. Azonban akikkel foglalkoznak is, azokkal tényleg foglalkoznak? Nem ők a századik ember, akivel megoldatják ugyanazt a feladatot és várják a csodát?

Pontosan emiatt kényelmesednek el a cégek, mert rengeteg jelentkező van és nem igazán érdekli a legtöbbjüket a negatív marketing az interjúk minősége miatt. Hiszen úgyis van annyi jelentkező, mit számít, ha emiatt elvesztünk párat? Kérdés, hogy vajon abban a pár elvesztett jelöltben lenne-e az, aki csont nélkül átmegy az interjún és értékes tagja lenne a csapatnak?

Anno, mikor még én is fiatal voltam és kellett a pénz, jelentkeztem egy full stack JS állásra. Sajnos ez nem jött össze, de egyáltalán nem rossz szájízzel fogadtam a hírt, ugyanis annak ellenére, hogy nem sikerült, nem egy bináris választ kaptam telefonban, hanem szépen pontokba szedve kaptam egy igen részletes értékelést arról, hogy mi volt jó vagy éppen mi volt rossz a megoldásomban. Innen lehetett érezni, hogy valaki tényleg foglalkozott ezzel és vette a fáradtságot, hogy kb fél órában összeírjon róla egy rendes feedbacket.

Nem fogok cégnevet elárulni, meg lehet nem is a cég, hanem egy igazán elhivatott ott dolgozó érdeme mindez, de az biztos, hogy nagyon jó példát mutatott és ha újra JS-re vetemednék, akkor lehet ott próbálkoznék először.

Szóval a felvételi eljárásokra is igaz a mondás, némileg átértelmezve, hogy aki sokat markol, keveset fog.

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

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

Pár hete tettem látogatást vidéken, ami nyílván a családdal telik leginkább. Ilyenkor látom a keresztfiam is, na meg belecsöppenek a különböző nevelési módszerekbe is. Az egyik ékes példája ennek, amikor az egyik családban a nyolcéves gyerek megnézheti a nyolc mérföldet, míg a másik családban a tizennégy éves ellenben nem. Régen ezzel nemigen törődtek, mert akár horrorsorozatot is levetítettek kora délután, de mára már nem ez a helyzet.

Szóval itt akad két tábor. Az egyik mindentől meg akarja védeni a gyerekét, míg a másik azt mondja, hogy a gyerek abból tanul, hogyha megégeti magát.

Szerencsénkre a gyerekeknél a természet megoldja, hogy hamar átvészeljék a bajokat, kevésbé törjön a csontjuk, hamarabb gyógyulnak, ésatöbbi, tehát a tanulási fázis elején védve vannak valamelyest, hogy a saját mozgásterükben ne tudjanak kárt tenni magukban. Tehát külső behatás, mulasztás nélkül nem kell nagyon aggódni, hogy gond lesz.

Képzeljük el mi lenne, ha a gyerekek egy autó sebességével futnának. Olyan képességekre tesznek szert, amire még nincsenek felkészülve. Ha ezzel a tempóval esnek el, akkor bizony nem egy kis horzsolás lesz a vége.

A hazafele úton aztán sokat agyaltam ezen és rájöttem, hogy bizony sok tekintetben hasonlít ez arra, amit lehet látni a szakmánkban is. Hiszen ahogy a két szülő máshol húzza meg a határokat, úgy sokszor elég jól elválik a keretrendszerek, nyelvek és függvénykönyvtárak azon két csoportja, akik egyike minél jobban lekorlátozza a mozgásterét az adott kód használóinak annak érdekében, hogy hülyeséget csináljon, meg akad a másik tábor, akik azt vallják, hogy a nyelv használói már felnőttek, tehát teljesen szabad kezet kapnak és emiatt az ő felelősségük, ha hülyeséget csinálnak.

Ha megégetik magukat, akkor így jártak, majd tanulnak belőle. Amíg csak maga a fejlesztő járhat pórul azzal, mert valamit engedtünk neki, de nem kellett volna, addig nincs akkora gond.

Sajnos azonban az esetek többségében a fejlesztő nem saját szórakoztatására kódol, hanem valaki fizet ezért. Emiatt nem csak a fejlesztő fog tanulni ebből a hibából, hanem bizony a megbízó is kárát láthatja ennek, ami könnyedén a fejlesztő problémája is lesz.

Emiatt igen nagy a felelősség a nyelvek, keretrendszerek fejlesztőin, hiszen rajtuk múlik, hogy a használóik kapnak-e a kezükbe ollót, amivel mondjuk vágni tudnak, de nyílván kárt is tehetnek magukban. Ha a helyükben lennénk, mivel oldanánk meg azt, hogy mégse történjen baj? Vagy nem adunk nekik eszközöket vagy megtanítjuk nekik, hogy hogy is tudják azt használni és felügyeljük őket addig.

Sajnos a felügyelet nemigen működik ebben az esetben, így más irányba kell nézelődnünk.

Na most mi is történik, amikor még épp hogy belekezdtünk a keretrendszer megismerésébe, de elakadtunk és ahelyett, hogy megpróbálnánk megérteni a problémát - mert a dokumentációban nem térnek ki erre, vagy nem találjuk meg az adott részt -, a google első találatából másolunk egy olyan kódrészletet, amit nem is értünk. Ott van, működik, lendít is a projekt haladásán, de nem követtük le ezt a tempót. Ennek bizony hasonlóan ahogy a túl gyorsan rohanó kisgyerek, esés és nem egy apró horzsolás lesz a vége. Lehet holnap, lehet egy év múlva, de az ilyesmi megbosszulja magát.

Tehát látjuk, hogy már az is nagyon sokat segít, ha az adott rendszer elég laza, tehát nem köti meg a kezünket, de a dokumentáció jól felépített, könnyen kereshető és a best practiceket fogja erőltetni és csak annak végén mintegy kiegészítésként írja le, hogy mi is az amit még be lehet vetni, de az milyen következményekkel járhat. Ez azért is fontos lehet, mert ez ott van előttünk, ez lehet az első bástyája annak, hogy ne ugorjunk fejest a dolgokba. Hasonló a helyzet az interneten fellelhető rengeteg oktatóanyaggal is. Hatalmas a felelősség azokon, akik ezeket készítik és sokan ebbe bele se gondolnak, hogy mi is lesz akkor, ha anti patternek kerülnek bele.

Ha a másik oldalon vagyunk és épp tanulni szeretnénk, akkor érdemes megnézni hogy mikor is került ki az az anyag és ezután átértékelni azt, hiszen egy ilyen rohanó szektorban nem biztos, hogy egy olyan forrásból akarunk tanulni, ami 8 éves és egy olyan nyelvre fókuszál, ami akkor még béta verzió volt. Rengeteg minden megváltozhatott azóta.

Akkor mi itt a megoldás? Vagy mi az, amit át tudunk ültetni a szakmába? Ugye itt fokozatosan kell egyre több felelősséget a fejlesztőre terhelni. Szerintem a válasz itt is egyfajta mentoring lesz… Freelancerként ez nyílván nem fog menni, hiszen nem kérhetjük ki harmadik fél véleményét, maximum úgy, hogy egy csomó mindent, ahol köt minket a titoktartás nem mondhatunk el, ami torzíthatja a képet.

Egy nagy céges környezetben mindez jól is működhet, hiszen van sok különféle tapasztalattal bíró ember, akik felügyelhetik a munkánkat. Itt pedig elő is jönnek azok a bizonyos szintek, amik mentén nem csak a fizetésünk van bekategorizálva, hanem a felelősségi körünk is.

Persze ehhez az kell, hogy akik ezt megállapították is megfelelően kezeljék a dolgokat. Tehát amikor pl traineeként kerülünk oda, akkor nyílván sokminden lesz, amit nem tehetünk meg. Amiket vissza fognak dobni a review-n, mert nem megfelelő és ha jó “szülők”, akkor az indoklás nem egy “csak” lesz. Itt hasonlóan, mint a gyerekek el lehet kezdeni hisztizni, aztán valami lesz belőle vagy sem. Cserébe, ha valamire rámondták az áment, akkor ne minket terheljen a felelősség, hiszen az egy jóváhagyott kódrészlet volt, amit nálunk tapasztaltabbak néztek át.

Na de honnan a tapasztalat? Akkor ezek szerint valakik csak megégették magukat és/vagy az ügyfélt is.

Sajnos nem tudjuk megúszni azt, hogy hibákat kövessünk el. Valakinek el kell követnie azokat, hogy tanuljon belőle és aztán ezt a tudást átadja másoknak. Ha szerencsénk van, akkor ez a valaki nem mi leszünk, sőt nem is valaki a cégnél. Az internet világában rengeteg információ áll a rendelkezésünkre és sok előadás születik arról is, hogy mit hogy ne csináljunk, meg hogy sikerült elrontani x-et vagy éppen mivel akasztottam meg az y szolgáltatásunkat. Ezek azok, amikből szintén tudunk tanulni. Nekem is van egy hasonló meetup előadásom, amiben az orm, eager loading és rossz hibakezelés kombójából lett egy igen nagy baj.

Ezt a fajta erőforrást pedig hiba lenne nem használni, így ha legközelebb egy előadáson arról van szó, hogy a több tucat middleware és az AOP házassága komoly fejfájást fog okozni, főleg ha debugolni akarjuk, akkor figyeljünk oda, mert lehet ez fog megmenteni egyszer, ha magunk is ilyet akarnánk csinálni.

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

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

Van az a mondás, hogy a code review-t ötből négy ember élvezi. Nyilván, hiszen az ötödik az, aki ellenben úgy érzi, hogy szívatják, mert épp az ő kódját nézik át.

Természetesen a fenti arányok nem minden cégre érvényesek, mert mások és mások a szokások, sőt! Van ahol maga a kód review sem bevett szokás.

Na de mi is ez az egész? Miért van ilyesmire szükség? A kód review során az érintettek- akik általában a csapatból, vagy az alkalmazást magukénak vallók közül kerülnek -, ki vadul nekiesnek a beküldött pull requestnek. Ez a pull request a verziókövetőben lehet külön branch, fork, akármi. Itt sokan sokféle dolgok után kutatnak, jó vagy éppen rossz példákat követve. A célja az egésznek az lenne, hogy mások is lássák a kódot, megértsék azt, ha pedig kifogásolnivalót találnak benne, akkor azt jelezzék az illetőnek.

Sajnos sokan elkövetik azt a hibát, hogy szemre checkstyleozzák a kódot, vagy egyéb statikus analizáló szimatával mennek végig rajta, felemlegetve az összes kimaradt final kulcsszót, hiányzó entert és hasonlót. Ezzel az a baj, hogy akármilyen jól is gépel az illető, aki épp átnézi a kódot és akármilyen gyorsan is észleli ezeket a hibákat, sosem fog a gépek nyomába érni. Ezért ami ilyet ellenőrízni lehet automatikusan, azt ellenőrízni is kell, sőt mi több… ha bármi gond van, törjön az a build!

Na de tegyük fel nincs ilyen kollégánk a cégnél. Akkor továbbra is a cél, hogy mások is lássák a kódunkat. Na de minek? Nincs ezeknek jobb dolga? Ők is kódolnak és még a határidők is szorosak, nyomjatok már rá az approve gombra és vehessem fel a következő taskot, nem igaz? Van az a bizonyos mondás, hogy “the only way to go fast is to go well” azaz az egyetlen mód, hogy gyorsan fejlesszünk, az az, ha jól csináljuk azt.

Tehát pontosan azért van erre szükség, hogyha a következő task, amit valaki más felvesz és a mi általunk patkolt kódrészleteket érinti, akkor ne azzal teljen el a fél napja, hogy megpróbál rájönni mi az és 0. lépésként átnevezgessen, refaktorájon. Helyette amikor odajut, akkor egy olyan kóddal találkozzon, amit már vagy ő maga is látott, vagy mások is látták és megértették. Ha pedig nem értették meg elég gyorsan, akkor nem magukban keresték a hibát, hanem szóvá tették és javítotva lett.

A mostani csapatomban már megállapítottuk, hogy én vagyok a rossz zsaru, a másik budapesti backend fejlesztő pedig a jó zsaru, ugyanis én vagyok az, aki köti az ebet a karóhoz és sokkal szigorúbb, ha bármi nem tetszik a kódban, míg ő hamarabb elengedi a dolgokat. Nyilván itt nem egyéni preferenciára kell gondolni, mert a kód review nem ennek a helyszíne. Persze meg lehet mondani, hogyha valami szerinted másképp jobb lenne, de érvek nélkül sokat nem ér.

Az egyik leggyakoribb érv, amivel védekeznek az esetleges kommentjeimmel szemben az a “dehát a kódban máshol is így van”. Persze, mert akkor mikor az készült még nem voltam itt, hogy megcsináljam és azóta se jutottam el oda. Nyilván nem ezt fogom válaszolni, meg rövid is az adás, hogy belekezdjek a monológomba, de maradjunk csak az úgynevezett boys scout rulenál. A cserkészeknél volt egy ilyen szabály, hogy a portát mindig jobb állapotban hagyd, mint ahogy érkeztél.

Ez igaz a kódra is. Lehet, hogy aki előtted beletúrt szemét módon nem javította ki azt az elírást, nem emelte ki azt a 8x másolt kódrészletet egy helyre. Viszont ha Te ránézel érzed, hogy az ott nincs jól, így ha tele is van a kód ilyenekkel, akkor se fogd arra, hogy máshol is úgy van. Az esetek többségében hamarabb kijavítasz dolgokat, mintsem végeznél a kommentháborúval. Energiát spóroltál vele és még jobb is lett a kód. Win-win.

Nyilván ez nem mindig ilyen egyszerű, mert gyakran nem csak véleményeket, de egókat is ütköztetünk a review kommentekben, amiből nehéz jól kijönni. Ilyenkor érdemes bevonni valaki mást is, aki függetlenül tud döntést hozni az ilyen esetekben. Persze a legjobb lenne az, ha ettől mentesíteni tudnánk a kódot. Ahogy mondtam, rendes érvek nélkül sokat nem ér, de néha nehéz ezeket megtámogatni, hiszen sokszor szubjektív témákban megy a vita, lévén ugyanazt a problémát rengeteg módon meg lehet közelíteni és oldani is.

Sajnos igen tipikus hiba, hogy hatalmas pull requesteket gyártunk, amik még commitok mentén sincsenek szétválogatva. Na ilyenkor szokták gyorsan rávágni, hogy hibátlan, approve. Nyilván nem az, de akkora munka lenne végigmenni rajta, hogy senki sem akarja venni a fáradtságot. A legszörnyűbb kódok így kerültek be hozzánk is. A hatalmas csomagolás mélyén ott lapultak azok, amik felett elsiklottunk.

Persze ahogy a szoftverfejlesztésben és az életben úgy általában itt sincs szent grál. Tehát ellehetünk ilyesmi nélkül. Az is teljesen jól működhet, hogyha a csapatban nincs dedikált review, de cserébe párokban dolgozunk. Emiatt végig lesz egy második szem, aki már az elején tud szólni, ha valami a kódban csak nekünk tiszta, de neki nem az és valószínűleg másnak sem lesz az. Ahogy a bugokat is minél hamarabb fogjuk meg, annál kisebb lesz a kár, úgy igaz ez a kódban talált érthetetlen részekre is. Ha már az írás során felfedezzük ezeket, akkor nem kell több review körön átverni, nem kell x alkalommal újrabuildelni a szerveren, saját gépen és hamarabb eljut oda, hogy tesztelhető legyen.

A lényeg: A kódot továbbra sem gépeknek, hanem embereknek írjuk. Ha már a review alatt sem értjük meg mit is csinál az adott kódrészlet, akkor ez szép lassan elkezd gyűlni és gyűlni, arról nem is beszélve, hogy a review akkor van, amikor még az illető fejlesztő képben van, emiatt sokkal gyorsabban tud intézkedni, mint az aki x hónap múlva odamegy a kódhoz és csak pislog, hogy mi is történik.

Lehet ez a valaki pont mi leszünk x hónap múlva és pontosan ugyanannyira lesz számunkra is kaotikus, mint a review többi szereplőjének. Akkor fogjuk megérteni, hogy miért is szóltak be amiatt, mert az elnevezéseink félrevezetőek, átláthatatlan az egész és még sorolhatnám.

Ez volt a minicube podcast, ha tetszett az adás, akkor nézzétek meg az app.letscode.hu-t is, ahol kicsit közelebbről nézzük meg a kódot. Ha pedig írnátok nekem, akkor azt a minicube@letscode.hu mail címre tudtok. Találkozunk legközelebb, sziasztok!

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

A mai témánk egy kis előzetes sztorival kezdődik, ugyanis az életben igen sok szakmából lehet példákat venni, mivel a szoftverfejlesztés mint olyan egész újnak számít. Mondjuk a példa, amit hozni akarok nem egészen a legjobb, mert nem ezeréves múltra tekint vissza, de szerintem mindenképp tanulságos.

Repülés.

Erről mindenki egyből a szabadságra asszociál, holott rengeteg szabály köti a pilótákat és szinte minden repülési helyzetre megvan az előírás, amit követni kell. Vegyük mondjuk a motorindítást, erre a légcsavarod gépeknél kétféle helyzet is van, hidegen - tehát aznap először -, vagy melegen, mikor valaki nemrég tette le a gépet.

A kabintető csukva, pedálok beállítva, övek becsatolva, légcsavar kis szögön, gáz levéve, parkfék behúzva. Ezután főkapcsoló fel, strobe light be, üzemanyagpumpa be és innen jön majd az indítás. Mindennek megvan az oka a listában. Ha a kabintető nincs csukva, a légcsavar szele leviheti, a pedálokat azért állítjuk be előre, mert később, ha már be vagyunk csatolva akkor nem érjük el. Becsatolva azért vagyunk, mert a levegőben macerás lenne már megtenni, a légcsavart kis szögre azért állítjuk, mert motorindításhoz ez hatékonyabb, nem fojtja le a motort, gázt levesszük, mert később a hideg-meleg indítás függvényében állítjuk, a parkfék pedig azért, hogy ne kelljen lábbal fékezni a repülőt és véletlenül sem tudunk elgurulni így. A főkapcsoló kell, hogy bármilyen elektromos rendszert elérjünk, a strobe light jelzi, hogy motorindításhoz készülünk, az üzemanyagpumpa pedig egy kis terhet levesz a motor válláról.

Na most ebből a listából is kihagytam valamit, mivel ha indításkor fogyasztók vannak bekapcsolva, akkor az indítás okozta áramingadozás akár kárt is tehet bennük, ezért azokat is le kell kapcsolni. Na de miért mondom én el ezeket? Azért, mert ezek a checklistek léteznek a fejlesztésben is. Vegyünk pl valaminek az élesítését, ott is egy meghatározott sorrendiséget kell tartani, különben valami nem lesz az igazi. Az adatbázis sémát frissíteni kell a deploy előtt, ha adat kell bele akkor azt bele kell tolni az új verzió kikerülése előtt. Tesztelni is ezután kell majd a tesztelőknek és így tovább. Persze ez egyáltalán nem újdonság, hiszen ezt sokan már most is checklistek mentén végzik. Na de amiről inkább beszélnék az az, hogy mi a helyzet azzal, ami nem tartozik bele a “normal operations”-be, azaz nem egy hétköznapi dologról van szó. Mi a teendő ilyenkor? Mit teszünk, ha érkezik az xy pagerduty, miszerint az oldal elszáll ötszázas hibával.

Ha visszatérünk a repüléshez, ott léteznek úgynevezett emergency checklistek is, tehát ha valami gond van, akkor megvan a protokoll arra, hogy hogy is tudjuk abból a helyzetből a legkisebb veszteséggel kihozni magunkat. Mindennek megvan az oka itt is.

Mi a teendő ha motortűz van? Üzemanyagcsapot elzárjuk, üzemanyagpumpát lekapcsoljuk, teljes gáz és a kabinfűtést is kikapcsoljuk. Mivel a motortérben a legfőbb éghető anyag az olaj és az üzemanyag, ezért megpróbáljuk elzárni azt a tűz elől. Elzárjuk a csapot, ami a motortérbe vezet és teljes gázt adunk, hogy minél hamarabb elhasználjuk ami még ott van. A pumpát lekapcsoljuk, hiszen nem akarunk odapumpálni semmit, a kabinfűtés pedig a motortérből szivja a levegőt a kipufogó körül, így ha lekapcsoljuk, akkor a mérgező gázokat nem szívjuk be a kabinba. Ezután pedig elkezdjük a kényszerleszállást. Megvannak a lépések, megvan a sorrend is és megvan mit miért csinálunk. Nincs sok idő cselekedni, de ha valamit kihagyunk, akkor könnyen halálos következménye lehet.

Na és mi a helyzet a legtöbb tech cégben, ha valami gond van? Vakon lövöldözünk. Ez sok esetben még érthető is, hiszen az iménti példában pont az a lényeg, hogy ezek már felmerült problémák, volt idő kitalálni mi is az optimális eljárás rá. De vajon ez a helyzet nálunk is?

Nem tudnánk jól dokumentálni mindezt, hogy legközelebb, ha ilyen történik, akkor meglegyen a megoldás rá? Persze jó lenne, ha meg tudnánk oldani, hogy mindez ne fordulhasson elő, lévén egy szoftvert könnyebb módosítani, mint egy legyártott repülőt.

Sajnos akadnak helyzetek, amiket nem lehet. Sokszor lesz olyan, hogy csak odamegyünk, újraindítjuk és megjavul. Viszont ha ezt leírnánk, lenne aki meg tudja mindezt csinálni a leírás alapján, akkor nem lennénk bentebb egy lépéssel?

Azért mondom mindezt, mert már vannak cégek, ahol pl nem lehet megoldani azt, hogy a rendszer ne tudjon inkonzisztens állapotba kerülni. Ez lehet a rendszer jellege, esetleg az adott domain miatt, a lényeg, hogy a saját szememmel láttam ilyet élesben. Jött a pagerduty alert és rendesen, lépésenként dokumentálva ott volt, hogy is tudod kielemezni az adott problémát és megoldani azt. A korábbi root cause analysisoknak ez volt a kimenete, egy dokumentum, hogy ha legközelebb ez a probléma előfordul, akkor hogy kell megoldani. Egyszerűbb rendszereknél ez lehet egy sima indítsd újra ezt a szart, de már ezzel is segítünk annak, aki helyettünk, vagy ha elhagytuk a helyet, akkor utánunk találkozik azzal a hibával.

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

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

Ahogy nézegetem a különböző beszélgetéseket ilyen-olyan fórumokon, rengeteg témával lehetne előállni, amik legtöbbje nem közvetlenül a technikai képességekhez kapcsolódik, így esett most a választás a mentoringra, mint olyanra. Sajnos ez a témakör sokak számára ismeretlen, vagy nem éppen olyan formában ismert, mint azt kellene. Ebben benne van részben az is, hogy ez főleg multicégek gyakorlata, így a KKV szektorban ilyesmire nincsenek emberek, kapacitás, meg hát a csocsóasztal és a céges sörözés a fő ütőkártya.

Na de mire is jó ez a mentoring dolog? Egyáltalán miért éri meg? Gondoljunk vissza pályafutásunk kezdetére. Mennyire gyorsan haladtunk előre a szakmában? Elég volt ez a tempó? Persze, hiszen most itt vagyunk x évvel a hátunk mögött. Na de a kérdés, hogy vajon hol lennénk most ha van valaki, aki segít és igazgatja az utunkat? Ott vagyunk az xy helyen, vagy éppen egyedül és csinálgatjuk a kis dolgunkat, mennek a projektek és még büszkék is vagyunk, dől a lé, mehetünk a bahamákra nyaralni. Amit csinálunk azt értelemszerűen jónak érezzük, mert nemigen van interakció mással, akivel össze tudnánk vetni.

Illetve van valaki. Mégpedig a mi jövőbeni énünk. Próbáljuk ki és nézzük meg egy korábbi projektünket. Az esetek többségében lehet elszörnyedünk majd, persze ez nagyban függ attól is, hogy mikori kódot nézünk meg. Adnánk valami tanácsot a múltbéli énünknek? Persze itt nem arra gondolok, hogy “töröld ki a francba és inkább írd újra”, hanem valami építő kritikára. Ha adnánk, akkor lehet valaki más is tudott volna egy ilyen tanácsot adni. Megkönnyítette volna az életünket? Igen? Na itt a mentoring lényege.

Persze ha valaki visszanézi a korábbi kódját és nem talál benne semmiféle kifogásolnivalót, akkor így járt, biztos elérte a nirvanát, viszont ami inkább előfordulhat, hogy nem fejlődött ezalatt az idő alatt semmit. Na ez már nagyobb probléma. Ha nincs viszonyítási alap, nagyon könnyen benne tudunk ragadni egy bizonyos szintben, mert hát nekünk így jó. Ezért sem szokták szeretni, ha valaki új kerül a csapatba és változtatni akar valamin, még ha az jót is tenne, mert már megszoktuk, hogy így volt, minek szól bele?

Na de vissza a mentorálásra, hogy is néz ki mindez a gyakorlatban? Egyáltalán mit is csinál egy mentor? Segít a szakmai és személyes tanulásban, fejlődésben, hogy elérjük a céljainkat. Persze ha ez a cél a péntek délután 5 óra, akkor sok mindent ő sem tud hozzátenni. Na és ezt hogy fogja megoldani? Olyan, mint egy tanár?

A válasz egy határozott NEM.

Nézzünk egy példát, hogy miben másabb:

A karrierem során én is vétettem egy csomó hibát, amikről akkor még nem tudtam, hogy hibák. Ez lehet valami rosszul megválasztott nyelv, keretrendszer, biztonsági rés, akármi. Emlékszem, mikor még vadul freelancerkedtem, egy vasárnapi napon szólt az üzlettársam - aki a designal foglalkozott, hogy holnap mutatná meg az oldalt az ügyfélnek, de talált egy csomó hibát és meg kéne javítani őket. Akkor a fejembe vettem, hogy megjavítom mindet, de közel se volt olyan könnyű, így reggel 7-kor fejeztem be, aludtam egy órát és indultam a napi 8 órát leróni.

Na most képzelhetitek, hogy milyen jól telt az a hétfő. Persze tesztek nem voltak a kódra, emiatt amit kijavítottam, azzal egy csomó más hibát is ejtettem a kódban, hiszen piszokfáradt voltam. Mostani fejjel legalább magas szintű teszteket kellett volna írni rá, meg nem szabadott volna hajnalig nyomni, mert másnap mikor néztem, rengeteg bagatel hibát szúrtam ki benne. Tehát lenne egy-két szavam az akkori énemhez. Ráadásul ezt a bemutatót el is lehetett volna napolni, mint utólag megtudtam.

Ezekre a hibákra tudta volna felhívni a figyelmem egy mentor, de nyílván mélyebben szakmai dolgokban is tud segíteni, eszközválasztás, stb. Viszont csak terelgetni tud, nem dönthet helyettünk, nem egy tanár, tehát csak a végső esetben fog oktatni, viszont az simán benne van, hogy elmondja minek kéne még utánajárni.

Minél közelebb van hozzád a mentor, annál jobb. Itt nem feltétlenül fizikai közelségre gondolok, bár ha egy cégnél dolgoztok, az már mindenképp egy plusz pont. Ha a programnyelv/terület is egyezik, akkor még jobb, hiszen annál nagyobb részét járta már az illető a te utadnak, így nem a saját, hanem az ő hibáiból tudsz tanulni, ami mindig jobban megéri. Persze nem lehet csak úgy leakasztani a fogasról egy mentort, mert ez nem így működik. Nem is mindenki tud együttműködni mindenkivel, pont ezért már nem is erőltetik azt, hogy a cégeknél kijelölik az embereket, mert papíron lehet stimmelnek, de élőben ez kérdéses, mert nem egyforma stílusban dolgoznak vagy tanulnak. A másik fontos tényező, hogy a mentorált akarjon fejlődni, különben sok értelme nincs az egésznek. Bele kell tenned az időt és az energiát, hogy profitálj belőle.

Egyébként sokan azt hiszik, hogy csak a juniorok szorulnak mentorálásra, ami nem igaz. Senior kollégáknál is teljesen természetes mindez.

De még mindig nem tiszta, hogy mi haszna a mentornak az egészből? Leginkább a soft skillek terén tud fejlődni, hiszen gyakorolja, hogy is tud valakit ösztönözni, tanítani, mindemellett a jó mentorok egész hálózatot építenek ki maguk körül, akik mivel megkapták a kellő segítséget, maguk is szívesebben és ügyesebben segítenek másokon. Pont ezért mindenkinek csak ajánlani tudom, hogy próbálja ki magát az egyik, vagy akár mindkét oldalon. A cégünknél is lehet van lehetőségünk erre:

Ha nagyon akarjuk, akkor az onboarding, tehát az újonnan érkezett emberek szintre hozása is egyfajta mentoring. A code review is egy jó módja lehet annak, hogy a másikat terelgessük az úton, de ez persze nem dedikált mentorálás, így nem is olyan effektív. Viszont sok cég szervez belső mentoring programokat, érdemes lehet ennek utánajárni.

Ha freelancerkedünk, netán még csak most tanuljuk a szakmát, akkor kicsit nehezebb a helyzet, bár már akadnak erre kitalált oldalak is, mint pl a codingcoach.io is ilyen. Ha nem megy annyira az angol, akkor érdemes azzal kezdeni.

Ha éppenséggel java vagy php irányban indultatok el akkor dobjatok egy rövid bemutatkozó mailt a minicube@letscode.hu címre, hátha tudok segíteni.

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

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

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 minicube@letscode.hu cimre, addig is, találkozunk legközelebb!

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

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.

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.

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.

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.