Ilyen lesz egy átlagos napod Junior fejlesztőként

Nézzük meg Sándor egy napját, aki 4 hónapja dolgozik fullstack fejlesztőként.
Átlagos nap junior fejlesztőként

Ebben a cikkben megnézzük, hogy a tanulmányaidat befejezve, kezdő, junior fejlesztőként miképp képzelheted el egy átlagos napod. Egy valós életből vett példát ragadunk ki, ahol alanyunk, nevezzük Sándornak, 4 hónapja dolgozik egy webalkalmazásokat fejlesztő cégnél.

Már 4 hónapja egy kisebb magyar webfejlesztő cégnél dolgozom. Minden hétköznap reggel nyolcra érkezem és délután 16:30-ig dolgozom. Amikor megérkezem reggel a munkahelyemre elindítom a laptopomat és amíg az elindul elkészítem az első kávémat. Az első kávénak jelentősége van.

Én még nem láttam programozót, aki a reggelt nem kávéval, esetleg teával indította volna. A lényeg, hogy valamivel el kell indítani a napot. Ha esetleg még nem kávézol, de fejlesztőnek készülsz, jó eséllyel hamarosan kávézni fogsz.

Miután lefőztem a kávét szépen bekeverem, elkészítem és visszamegyek az asztalomhoz, közben beszélgetek a kollégáimmal nevetgélünk, hülyéskedünk, jófejek.

Általában az érkezést követő első fél órában még érdemi munkavégzés nem nagyon történik. Vagy beszélgetünk, vagy híroldalakat böngészünk vagy a Facebookot tekergetjük céltalanul. Ezzel tudat alatt nagyjából ráhangolódunk az adott napra, közben fejben átgondoljuk hogy mit szeretnénk csinálni. Tehát, ha közvetve is, azért ez is produktív.

Pontosan reggel 9:00 órakor felállunk a géptől és egy kör alakot formázva elkezdődik a szokásos, minden nap megtartott rituálé, az úgynevezett stand up. Ilyenkor a Scrum Master vezetésével megbeszéljük, hogy mi történt az előző nap, mit tervezünk a mai napra, illetve hogy van-e valamilyen akadályozó tényező, ami az aznapi munkavégzését hátráltatja, gátolja. Kivétel nélkül mindenki szót kap 1-2 percben.

A stand up nem tarthat tovább 15 percnél, ugyanakkor ennek valós időtartama változó, van hogy megvagyunk öt perc alatt, de van hogy 40 percig is egyeztetünk, bár ez már inkább az ún. grooming. Nagyon fontos ez a reggeli egyeztetés, hiszen ez alapján fogjuk az aznapi munkánkat elvégezni.

Az egyeztetés után az extrémebbek elkészítik a második kávéjukat, majd mindenki visszaül a saját laptopjához és átnézi a jegykezelő rendszert hogy esetleg kapott-e új feladatot, vagy kapott-e vissza mástól függőben lévő feladatot. Előfodul persze, hogy lezártak egy olyan feladatot, amiben részt vettem, ez jó érzés tud lenni. A ticket-eket minden nap, legalább reggel aktualizálni kell. Szükség esetén a jegyet meg kell válaszolni, vagy le kell zárni, esetleg további egyeztetés miatt másik kollégára „rátenni”.

Nagyon fontos, hogy mindennek legyen nyoma, hiszen elég sok szálon futnak az események, lehetetlen mindent fejben tartani, másrészt, ha esetleg lebetegszem egy kollégám számára minden információ ismert lesz a ticket élettörténete alapján.

Jelenleg ugyebár junior fejlesztőként dolgozom. Pont van rajtam egy új ticket, programozói feladat. A ticket szerint egy jelszómódosítás feladatainak elvégzése a feladat. Pontosan így néz ki:

Jelszómódosítás feladat a ticketkezelő rendszerben

A jegy státuszát módosítottam „folyamatban” állapotra és nekikezdtem a feladatnak. Elsőként a felületre belépve a profil oldalra mentem, hogy lássam vizuálisan hogy mi a feladat, milyen célt kell elérnem, mi a különbség a jelenlegi megoldáshoz képest.

Ezután pedig kikerestem a forráskódban a routing alapján, hogy melyik kontrollert illetve melyik nézetet fogja érinteni az adott feladat.

Mivel nem voltam biztos benne, megkérdeztem a vezetőfejlesztőt hogy külön Request típusú objektumot létrehozzak-e, amin keresztül validálom backend oldalon a jelszómódosítás követelményeit.

Miután minden információ a birtokomban volt elkezdtem a feladatot. Körülbelül dél volt mikor oda jutottam, hogy már teszteseteim voltak a régi jelszó megadására, illetve az új jelszó és annak megerősítésének megadására.

Ezután elmentünk ebédelni. Valaki ugye rendel, valaki a helyi menzára megy ebédelni, a lényeg hogy 30 perc nagyjából az ebédidő, bár ez azért nem ennyire szigorú. Van hogy elhúzódik ez egy órára is, de van, hogy csak 20 perc. Ezért nem nagyon szoktak szólni.

Ebéd után jöhet a harmadik kávé, majd mivel most ettünk azért nem illik ilyenkor egyből elkezdeni dolgozni, kimegyünk a szabad levegőre, beszélgetünk, hülyéskedünk.

12:45 magasságában mindenki visszaül a gépéhez és folytatja a feladatát. Körülbelül 15:00 körül elkészültem a feladattal, amit egy feature branch-re commit – oltam és push – oltam a Git-be. Majd a vezetőfejlesztőre egy merge request formájában rátettem egy Code review feladatot. Ennek az a lényege, hogy ő átnézi, mindent helyesen csináltam-e, a kód megfelel-e a sztenderd-eknek, szabványoknak. Ha minden oké, a vezetőfejlesztő a kódot behúzza a TEST ágra és mehet tesztelésre.

A vezetőfejlesztő ellenőrizte a kódot és több olyan pontot is megjelölt, ami kritikus, vagy nem felel meg a szabványoknak. Igazából egy SOLID elvet sértettem meg, illetve egy apróság, hogy nem volt implementálva a régi jelszó ellenőrzése :).

Ezeket gyorsan javítottam, push – oltam és jeleztem neki, hogy elkészültem a javítással. Természetesen mindezt merge request formájában és az ő nevére tett ticket-el.

Ezt is ellenőrizte, most már mindent rendben talált. A feature branch-emet merge – ölte a TEST ágra. Ezt követően visszakaptam a ticketet, hogy a kódom kikerült a tesztelői ágra, a biztonság kedvéért próbáljam ki, majd adjam át a ticketet a tesztelőknek.

A tesztelőktől hamarosan visszakaptam a jegyet, de sajnos nem olyan státusszal, amit szerettem volna. „Tesztelésen elbukott” státusszal visszajött a feladat. A hiba az volt, hogy nem ellenőriztem, hogy az új jelszó korábban már volt-e használatban az adott user-nél.

Miután ezt is lekezeltem újra merge request-et kértem a vezetőfejlesztőtől, aki ellenőrizte a változtatásokat és mivel sikeresnek találta, ki is került újra a TEST ágra a fejlesztés javított változata.

Újra jött a ticket, hogy TEST ágra kikerült, tesztelhető. Így már csak annyi dolgom volt, hogy a ticket – be beleírtam hogy elkészült a javítás, lehet újra tesztelni. Ezt követően a tesztelő nem talált több hibát.

Innen már tudtam, hogy ezzel a kis feature – öm ki fog kerülni a release ágra, ahol a tesztelők azt újra ellenőrzik, hogy vajon az összes új feature – el is jól működik-e. Minden sikeres tesztelésen átment feature/bugfix ág rákerül a release ágra, ezzel jelezve, hogy a következő élesítéskor azok a funkciók már készen állnak a publikálásra.

Körülbelül délután fél öt volt, amikor a veteránok az ötödik kávéjukat itták. Én megírtam a napi riportomat, hogy mivel foglalkoztam aznap és meddig jutottam. Miután ezzel is elkészültem, megnéztem mikor megy a busz, összepakoltam és hazaindultam.

A hazamenetellel azonban nem ért véget a nap, este 10:00 órakor, éppen mikor néztem a tévét eszembe jutott hogy a controller-be nem érdemes több paramétert átadnom, hanem azt célszerű lenne egy objektumba kiemelni és azt az egy darab objektumot vándoroltatni. Ezt megbeszéltem másnap a vezetőfejlesztővel, aki jelezte, hogy ezt látta, de a paraméterszám a sonar szerint még határeset volt, azért nem dobta vissza.

Az, hogy egy programozó éjjel-nappal dolgozik, nem csak mellébeszélés, hiszen akarva akaratlanul beugranak olyan szösszenetek, optimalizálási lehetőségek, amik az adott feladat elvégzésekor éppen nem jutottak eszünkbe, vagy csak egyszerűen figyelmetlenek voltunk.