Főoldal

"Mérnököt a mérnöktől"

A Schönherz Bázis összeköti az állást kereső és állást kínáló mérnököket.

CV küldés

Küldj önéletrajzot! Gyorsan, egyszerűen.
Megjegyzésbe írd be a pozíció nevét.
CV küldés

Iratkozz fel hírlevelünkre!

Hírek

Becsülendő szokások, amelyeket érdemes elsajátítani feltörekvő/junior fejlesztőként – és amelyeket célszerű elkerülni
Becsülendő szokások, amelyeket érdemes elsajátítani feltörekvő/junior fejlesztőként – és amelyeket célszerű elkerülni

Amikor kódolni tanulsz, igen könnyű felvenni néhány csúnya szokást. Az elkövetkezőkben leírok pár tippet, hogy könnyű legyen ezeket elkerülni, illetve néhány jó szokást, melyeket célszerű elsajátítani.


A jó szokások



Kezdjük hát a dolgok pozitív oldalával! Az alább felsoroltak a legjobb szokások, melyek a leginkább lenyűgöznek, amikor egy junior fejlesztővel dolgozom (vagy bármilyen fejlesztővel, ha már itt tartunk).


Gyakori commit


Nagy eséllyel találkoztál már a “Git”, “GitHub” és “source control” kifejezésekkel a programozói utad során. Hogyha mégsem:


  1. Hol éltél eddig? 
  2. Itt utána tudsz olvasni: https://www.freecodecamp.org/news/how-you-can-learn-git-and-github-while-youre-learning-to-code-7a592ea287ba/


A source control egy csodálatos dolog. Tulajdonképpen egy backup a kódodról, ami lehetővé teszi, hogy kövesd a változtatásokat, és gyorsan visszaállíts egy régebbi verziót, amikor elérkezel egy „a francba, semmi sem működik!” pillanathoz kódolás közben.



Arról nem is beszélve, hogy sokkal, de sokkal könnyebbé teszi az életet egy csapatban dolgozva. El sem tudom képzelni, hogy nélküle dolgozzak csoportos projekten, és e-mailben vagy slacken osszam meg a kódomat.


Egy jó szokás, amit érdemes megtartani, az a gyakori commitolás, akár még a saját kisebb projekteidben is gyakorlásképp. Én személyesen szeretem „becsekkolni” a kódomat amikor befejeztem a projektem egy kis részét. Például, ha épp egy TODO alkalmazáson dolgozok, akkor commitolnám a kódomat amint hozzáadtam az új todo gombot, vagy elkészítettem a checkbox funkciót.



A kód feltöltésére ugyanakkor nincsenek szigorú szabályok. Néhány szituáció, amikor érdemes:


  • Ha éppen készülsz befejezni a napi munkát (ehhez ne felejtsd el a lentebb található fontos szabályt)
  • Mielőtt egy nagyobb refaktorra/ változtatásra készülsz
  • Ha tűz üt ki az épületben (csak viccelek, a biztonság az első)


Csak egyetlen fontos szabály van, amelynek teljesülnie kell kód commitolása előtt:


Sikeresen build-elnie kell, és át kell mennie a teszteken


Vagy ez két szabálynak számít? Akárhogyan is, ez tényleg fontos. A hibás kód garantáltan megakaszt bármilyen fejlesztői csapatot. Szóval mielőtt commitolnál, bizonyosodj meg róla, hogy a kódod build-el és minden teszten átmegy!



Végül pedig, használj megfelelő commit üzeneteket! A „kijavított bug” nem annyira konkrét, mint a „kijavítottam a save todo gombot, ami nem hívta az onClick függvényt helyesen”. Ez nem csak neked lesz hasznos, hanem a csapattársaid számára is.


Használj tiszta elnevezéseket a változóknál, függvényeknél és fájloknál


Ó, az elnevezések. Amiről mindenki azt hiszi, hogy a webfejlesztés könnyű része, egészen nehéz tud lenni néha. Az elnevezések viszont fontosak, mivel növelik a kódunk olvashatóságát és érthetőségét.


Amikor nevet választasz a változóknak, függvényeknek és fájloknak, próbálj meg minél többet mondó nevet választani. Hogy miért?


  • Megkönnyíti a kód gyors átnézését. Ha látsz egy getUsers() nevű függvényt, akkor a függvény kódjának végigolvasása nélkül is egészen biztos lehetsz benne, hogy a felhasználók egy listáját adja vissza.


  • Segíti a felelősségek szétválasztását. Egy új kifejezés! Ne aggódj, ez csak annyit jelent, hogy mindennek megvan a saját felelőssége, és ezeket megfelelően el kell szeparálni egymástól. Például ha egy Node.js alkalmazásban létezik egy /users és egy /products végpont, akkor célszerű egy fájlban tartani a users logikát (például usersService.js néven), és egy másik fáljba tenni a products logikát. Így nem sokkal könnyebb megtalálni mindent?


Itt egy egyszerű függvény, amely nagyon rosszul van elnevezve (a paramétereivel együtt). Ki tudod találni, hogy mit csinál?


const function1 = (x, y) => {
    return x + y
}


Ez a függvény összeadhat két számot, de akár összefűzhet két sztringet is. Akárhogyan is, az eredeti célja nem tiszta. Mondjuk azt, hogy eredetileg két szám összeadására szánták, de egy másik gyanútlan felhasználó két sztring összefűzésére alkalmazza. Most még akár működhet is, de később ha refaktoráljuk a kódot, hogy validáljuk a számokat, akkor a sztringes használata nem fog működni!



Íme a függvény egy kicsit jobb elnevezésekkel:


const addNumbers = (num1, num2) => {
    return num1 + num2
}


Így már egy kicsit tisztább, hogy mit is csinál a függvény, és mik a paraméterei.


Gyakorold a debuggolást


El tudod hinni, hogy a webfejlesztők is töltenek ugyanannyi időt (ha nem többet) bugok javításával? Igen, még ott is vannak bugok. És ezek felderítésének és kijavításának a legjobb módja a kód debuggolása. Ez egy olyan folyamat, melyben sorról sorra haladsz a kódban, ameddig fel nem fedezel valamit, amire nem számítottál.



A webfejlesztők szerencséjére sok IDE jön beépített debuggerrel, melyek nagyban megkönnyítik a folyamatot. (Itt egy útmutató a debugger beállításához a VS Code-ban, a különböző nyelvekhez. Más IDE-hez a Google-t tudod segítségül hívni.)


Szóval hogyan tudod hatékonyan debuggolni a kódod? Itt van néhány útmutató:


  • Ismételd meg a problémát – reprodukáld a bugot párszor, hogy meg tudd érteni, pontosan mi is okozza azt


  • Gondolkodj – mielőtt beleveted magad a kódba, és elkezdesz cél nékül tisztogatni, állj meg egy pillanatra és gondolkodj. Miért történne ez? A kód melyik része kapcsolódik ehhez?


  • Vizsgáld meg a kódot – amikor már van ötleted, hogy a kód melyik része okozhatja a problémát, kezdd el beleásni magad. A kód átolvasása után lehet, hogy meg is találod a hibát. Hurrá! Ha pedig nem, akkor ideje a debuggerhez fordulni.


  • Debuggolj – indítsd el a debuggert, és nézd végig a kódot sorról sorra. Tartsd szemmel a változók értékeit (és a változásukat), és hogy melyik függvények hívódnak meg (és melyek nem). Az if elágazás megfelelő ága fut le? Megfelelően aktiválódnak az események? Helyesen hajtja végre a számításokat?


Tervezz, mielőtt kódolsz


Épp most keltél fel egy kiadós alvásból. Épp a reggelidet fogyasztod, amikor hirtelen egy szuper mellékprojekt jut eszedbe. Milyen csodálatos ötlet!


Kiugrasz a székedből, a laptopod felé veszed az irányt, a müzli szanaszét repül, és megszállottan kódolni kezdesz.



Habár gyakran vonzó, hogy egyből a fejlesztőkörnyezetbe ugorjunk és kódolni kezdjünk, egy kis tervezés nagyon sokat tud jelenteni.


  • Lecsökkenti az „elvesztegetett” kód mennyiségét
  • Lecsökkenti a változtatásokat
  • Egy szilárd célt tesz a szemed elé
  • Emellett pedig egy lenyűgöző képesség a junior fejlesztők számára – megmutatja a kritikus gondolkodást!




Íme egy kis összefoglaló gondolat:


  • „Mit fog csinálni?” - Írj le pár funkciót, amit szeretnél az alkalmazásodba tenni.


  • „Hogyan fog kinézni?” - Csinálj egy gyors vázlatot vagy drótvázat az alkalmazásod kinézetéről.


  • „Hogyan tudom elhelyezni és formázni az elemeket?” - Amint megvannak a drótvázak, kezdj el gondolkodni rajta, hogyan akarod elhelyezni a dolgokat az oldalon.


  • „Hogyan viselkedik?” - Ezután kezdj el gondolkozni az alkalmazásod viselkedésén. Gondold át a funkciókat, és hogy mi történik, amikor a felhasználó rákattint valamire.


  •  „Hogyan fog kinézni a kódom?” - A viselkedések és funkciók tudatában kezdd el tervezni a kódot. Milyen komponensekre lesz szükséged? Kellenek majd eseménykezelők? Állapotobjektumok?


  • „Mi kell a teszteléshez? És mi romolhat el?” - Gondolkodj el a tesztekről, mik az edge-case-ek, és hol romolhat el a kód.


A nem annyira jó szokások



Most pedig nézzünk már pár rosszabb szokást, melyeket könnyű felvenni. Ha megvan nálad ezek közül pár, ne pánikolj. Mindannyiunknál megvannak a karrierünk egy pontján! Egy kis gyakorlással túl tudsz rajtuk lépni – én pedig adok egy kis iránymutatást, hogy hogyan tedd.


Kód másolása és beillesztése vakon


Azt hiszem, mindannyian találkoztunk már egy olyan problémával, aminél elakadtunk. Nyilvánvalóan folyamatosan problémákkal állunk szemben a kódólás során. Ez hozzá tartozik, és a mi feladatunk kitalálni, hogyan tudunk ezeken túllépni.


Az esetek többségében a Google, StackOverFlow, vagy valami ezekhez hasonló használatához folyamodunk a megoldás reményében. Természetesen nincs ezzel semmi probléma – vitathatóan bár, de bátorítani is kellene ezt a megközelítést, hiszen ez a problémamegoldás leggyorsabb módja.


A baj akkor van, amikor vakon, a kód megértése nélkül másoljuk azt be.



De ha működik, mi a probléma?


Egy valid kérdés. Íme az okok, hogy miért tud gondot okozni:


  • Mi van, ha meg kell változtatni? Elég nehéz lesz, ha nem értjük, hogy mit csinál.


  • Ha nem értjük, hogyan lehetünk benne biztosak, hogy ténylegesen megoldja a problémánkat?


  • Biztosak lehetünk benne, hogy nem befolyásolja a kódbázis más részét negatívan?


Szóval hogyan tudjuk ezt elkerülni?


  • Olvasással – Olvasd végig sorról sorra, és szánj időt a megértésére.


  • Gépeléssel – Gépeld be a másolás helyett. Ez rá fog kényszeríteni, hogy végigolvasd/analizáld a sorokat.


Semmi baj nincs a másolással, amíg meg is értjük pontosan, hogy mit csinál a kód. Ha egy senior fejlesztő nézi át a kódunkat, és nem tudjuk elmondani, hogy mi történik, mert másoltuk, az nem fog jól mutatni.



Nem írsz teszteket


Ez vitathatatlanul a legrosszabb szokás, amit bárki elsajátíthat a tanulás folyamán. Rengeteg tutorial végigvezet minket az alkalmazásfejlesztés „boldog részén”, és így könnyedén elhanyagoljuk a tesztírást. De miért is olyan fontos ez?


  • A tesztek bizonyítják, hogy működik a kódod. Senki nem tudja vitatni a funkcionalitás működését, ha a teszteken átmegy!


  • Könnyebben látszik, hogy az új funkciók elrontottak-e valamit, vagy nem. Kódolás közben is futtasd a teszteken rendszeresen. Elromlott pár teszt? Már a fejlesztési folyamat korai szakaszában is tudod, hol romlott el ahelyett, hogy mondjuk másnap véletlen futsz bele.


  • A refaktoring biztonsági öve. Írd meg a kódod. Írd meg a teszteket. Refaktoráld a kódot. A tesztek átmennek? Minden működik még mindig, mindenki boldog! Most próbáld meg úgy megváltoztatni a kódot, hogy nincsenek futtatható tesztjeid. Hogy tudod bizonyítani, hogy minden úgy működik, ahogyan kellene?


Menj biztosra, és teszteld a kódod. Nem muszáj mindig minden kis mellékprojektet tesztelni, de előnyös néha gyakorolni ezt is. Ha kapsz egy munkát, akkor a maximális tesztlefedettség lesz a cél a legtöbb funkciónál. Gyakorold!



Rengeteg jó tutorial van a kód tesztelésével kapcsolatban. A jelenlegi projektjeidtől és technológiai hátteredtől függően be tudod írni a keresődbe, hogy „testing with {használt nyelv}” vagy „hogyan teszteljek {használt nyelv} alkalmazásokat”.


A dokumentáció kihagyása


Dokumentáció. Az unalmas bürokrácia, mely minden projekt része. Ahogy valaki már mondta egyszer:


Minden fejlesztő utál dokumentálni, de mindenki akarja, hogy legyen.



Ez pedig színigaz. Tértél már vissza valaha egy régi mellékprojektedhez, és nem tudtad, hogy mit csinál? Mennyivel nehezebb lenne, ha úgy akarnál egy külső könyvtárat használni, hogy nincs semmilyen dokumentációja ami elmondaná, hogyan működik? Ez még sokkal fontosabbá válik, amikor egy nagy cégnél dolgozunk. Mi van, ha egy másik csapatnak integrálnia kell a kódodat, de nem biztosak az API-ban?


Ezek fontos dolgok, szóval itt van néhány tipp a gyakrolásához:


  • README fájlok – A GitHub lehetővé teszi, hogy readme fájlokat adjunk a projektekhez. Ez a legjobb helye a dokumentáció tárolásának, és könnyű megtalálni.


  • Írd bele, hogy hogyan működik az app, és hogyan kell futtatni – Ez egy jó kiindulási alapot szolgáltat az olvasónak.


  • Magyarázz el más fontos dolgokat – Olyanokat, mint a komplikált logika, külső könyvtárak és API-k, vagy a konfigurációs beállítások


(Forrás)

***
Ha Te is kreatív, kihívásokkal teli mérnök állást keresel minosé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!


2019.11.12.