5 dolog, amit junior fejlesztőként tanultam

Körülbelül 4 hónappal ezelőtt kezdtem el az első munkámat szoftverfejlesztőként, és mivel freelancerként dolgoztam előtte, megvolt a saját kódírási módszerem. Az idők többségében senki nem olvasta a kódomat. Még az ügyfeleim sem, a technikai hozzáértés hiányában.



Nem dolgoztam még előtte soha az iparban, szóval nem voltam tisztában az alkalmazott kódolási paradigmákkal. Bár az elmúlt 2 évben freelancerként dolgoztam, teljesen más volt, amikor teljes munkaidőben egy cégnek kezdtem el dolgozni.


Függetlenül az elmúlt 2 évben szerzett tudástól, tulajdonképpen semmi tapasztalatom nem volt a csapatmunkában. Alább található 5 dolog, amit a csapatom senior fejlesztőitől tanultam.


A refaktorálás számít


Egy olyan projekten dolgoztunk, melyben rengeteg volt a folt, duplikáció, és általánosságban nem volt hatékony a kódja. Egy nap a Team Lead tanácsolta, hogy vessek egy pillantást a kódbázisunkra, és dolgozzak egy kicsit a kódminőség javításán.


Annak ellenére, hogy első pillantásra nem láttam benne kivetnivalót, hamar kezdtem rájönni, hogy mire célzott. Elkezdtem újraírni a függvényeket, hogy modulárisabbak legyenek, beépített megoldásokat tettem a foltok helyére és szétbontottam a kódot fájlokba és mappákba ahogy és amikor kívántam.



Pár napnyi refaktorálás után a kódbázis elkezdett sokkal olvashatóbb és könnyebben írható lenni a foltok és a duplikáció nélkül, és szépen mappákba és fájlokba rendezve. Úgyhogy igen, a refaktorálás bizony számít, de csak egy bizonyos mértékig.


A formázásnak egységesnek kell lennie csapaton belül


Ne legyen felesleges whitespace! Se extra üres sor, se helytelen indentálás! Ezek mind annak a jelei, hogy nem követtek egyetlen közös formázási stílust a csapaton belül.



Szóval kinek a formázási stílusát kellene követnünk, a Team Lead-ét? Nem, itt jönnek be a linterek. A projekt elején kiválasztunk egy lintert, és mindenkinek követnie kell a teljes fejlesztési ciklus alatt.


Ez segít, hogy a kódbázis tisztább legyen, és mindenkitől ugyanazt a kódolási szabványt várja el mindenkitől. A Team Leadek sokszor csináltatnak pre-commit hook-ot, hogy meggyőződjenek róla, hogy mindenki követi a megbeszélt formázást, mielőtt a kód felkerül a repoba.


A unit tesztek sokat segítenek hosszú távon


Unit tesztek! Meh, haszontalanok… Már a saját oldalamról leteszteltem a kódot, és minden az elvárt szerint működik. Miért kellene scripteket írnom erre?


A véleményem akkor változott meg mindenkorra, amikor más fejlesztők elkezdték módosítani a kódomat, hogy belevigyék a saját változtatásaikat. Senki nem tudta, hogy mi törhet el a módosításokkal, amiket terveztek. Ez nehezen módosíthatóvá tette a kódomat, és ez még rosszabb lett, amikor a dolgok tényleg elkezdtek eltörni a productionben.



Ha lettek volna unit tesztjeim, akkor a bugokat már a tesztelési fázisban azonosíthattuk volna, és nem kezdődött volna el a hibáztatás. Ez felnyitotta a szemem, hogy a tesztek szükségesek a kód fenntarthatóságához.


A türelem kulcsfontosságú


Az egyik csapattársam egyszer nem működő és formázatlan kódot pusholt közvetlenül a dev branchbe. Abban az időben nem volt lezárva a branch, hiszen senki nem csinált ilyesmit előtte. Ő új volt még a cégnél, és mivel én vettem észre először, KIAKADTAM.


Rárivalltam, amiért mindent elrontott mindenki számára. Megértette, és egyből bocsánatot kért. Kijavította néhány órán belül, én viszont megbántam, hogy úgy rászóltam.



Jobban is kezelhettem volna a szituációt, ha elmagyarázom neki a problémát, és hogy miért ne ismételje meg.


„Minden hibázik. De nem sokan tanulnak belőle.”


Nem mindig a senioroknak van igaza


Ahogy mindig, a napi stand-up eljött, és mindenki elkezdte tárgyalni a problémát, ami már napok óta idegesített minket, de nem volt még rá megoldásunk. Ez egy jelentős szűk keresztmetszetet állított az alkalmazásunk skálázhatóságának útjába.


Az emberek különféle megoldásokat dobáltak be, és ahogy a legoptimálisabbat tárgyaltuk, a team lead bedobta a sajátját, és elmondta, hogy miért az övé lehet a legoptimálisabb. Mindenki egyetértett, és megkaptam, hogy implementáljam.


Ahogy elkezdtem átgondolni, rájöttem, hogy az implementációban nem kezeljük le az edge caseket, és hogy nem is lehetséges őket lekezelni a megadott implementációval.



Gondolkodtam egy kicsit, és kitaláltam egy új megoldását a problémának. Ellenőriztem az általam kigondolt edge caseket, és az én megoldásom mindet lefedte.


Küldtem egy emailt a team leadnek az ajánlott megoldásommal, és a következő nap mindenki megbeszélte és egyetértett a megoldásommal, kivéve a team lead. Nem volt különösebb indoka az ellenkezésének, én pedig még mindig azt gondoltam, hogy az én megoldásom jobb, szóval feljebb vittem a dolgot a CTO-ig.


A CTO összehívott egy meetinget a következő napra, és mindkét megoldás analizálása után az enyémet nevezte ki jobbnak, érvekkel alátámasztva. Mindenki egyetértett, és sikeresen implementáltuk.


Ha nem vittem volna tovább, vagy csak simán elfogadtam volna, amit a seniorom, vagyis a team lead kért, akkor az talán működött volna rövidtávon, de hosszú távon még nagyobb problémákat hozhatott volna. Így az előre gondolkodás segített hatékonyabban analizálni a problémát.


Emellett persze még rengeteg dolgot tanultam juniorként, de a felsoroltak voltak azok, amik igazán nagy ugrást jelentettek mind a soft, mind a hard skilljeim tekintetében.


Sok billentyűkombinációt is megtanultam, hogy könnyebben navigálhassak a fejlesztőkörnyezetekben. A debuggolási képességeim és az elemző gondolkodásom pedig szárnyra kapott a mások tapasztalataiból való tanulástól.


(Forrás)

***
Ha Te is kreatív, kihívásokkal teli mérnök állást keresel minőségi munkáltatónál, jó helyen jársz, mert a Schönherz Bázis épp azért jött létre, hogy Neked segítsen.
Gyere, nézz szét aktuális állásaink között!


2020.02.27.