Nagylányok és kisfiúk

Minicube

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

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!

---

Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.