Mire számíthat az első héten, mint szoftverfejlesztő

Tudod, hogy élvezed a kódolást, de milyen egy munkáért csinálni? Mire számíthat az első héten?

El sem tudtam képzelni az első hetemet egy új munkahelyen. Azonnal elkezdi a kódolást? Mi van, ha olyan nyelvet / keretet használnak, amelyet még nem tanult meg? Hogyan tud felgyorsulni a kódbázissal, és tudja, mi a prioritás? Könnyű bekerülni a csapatba? Csak ... megnyitja a szerkesztőt és elkezd kódolni? Mi van, ha valami szörnyen rosszul esik és mindent megtör?

2 évig dolgoztam egy kódoló bootcamp-on, és sok hallgatótól hallottam hasonló kérdéseket. Tudták, hogy szeretik a kódolást, és imádják, amit a bootcamp-on csinálnak mindennap - de szerették volna tudni, milyen érzés valódi munkába állni.

Ebben a bejegyzésben példákat fogok felhasználni arra, amit az első napokban tettem a legutóbbi szerepemben, hogy megpróbáljam ötletet adni arra, mire számíthat.

Háttér

Teljes verem fejlesztőként dolgozom egy kis vállalatnál. A mérnöki csapatban négy fejlesztő van (köztük én is) és egy CTO. Szorosan együttműködünk egy terméktulajdonossal is, aki az egyik alapító. Pár éves kódolási tapasztalattal mentem be.

Minden szolgáltatás az AWS-en van, és a NodeJS-t és a Ruby-t használjuk.

1. nap: Többnyire beállítás

9 órakor érkeztem az irodába. Fényes új MacBook Pro várt az asztalomra, adapterekkel és két képernyővel kiegészítve. A dev csapat kivitt reggelizni egy közeli kávézóba, és amikor visszaértünk, leültem, és elkezdtem felállítani a gépemet.

Mivel számtalan dev környezetet állítottam be korábban, miközben egy kódoló bootcamp-on dolgoztam, ez elég egyszerű volt, és nem tartott sokáig. A Ruby / Rails környezetet azonban csak egyszer hoztam létre a saját laptopomon, így ez a rész kicsit tovább tartott.

Kaptam egy A4-es lapot, amely felsorolta a követelményeket, a verziószámokat és így tovább, és gondosan követtem. Hozzáférést kaptam különféle webhelyekhez, például a BitBuckethez, egy jelszókezelőhöz, az AWS-hez és a Gitlab-hoz, és beállítottam az SSH-kulcsokat az új gépemen.

Ebéd előtt elmentem beszélgetni a CTO-val, és részletesen megbeszéltük a terméket, az architektúrát, valamint azokat a célokat és prioritásokat, amelyekkel a fejlesztői csapat belátható időn belül rendelkezik.

Ebéd után klónoztam néhány alkalmazást alkotó szolgáltatást, és elkezdtem megismerkedni a kódbázissal. Szerencsémre akkor léptem be a csapathoz, amikor a szolgáltatásnak új, friss részei voltak fejlesztés alatt, ami azt jelenti, hogy nem volt túl sok kódom ahhoz, hogy felgyorsuljak.

A nap utolsó néhány órájában ültem az egyik vezető fejlesztővel, miközben ő megvalósított egy funkciót. Lehetőségként használtuk fel számára, hogy végigvezesse az alkalmazás ezen részén, elmagyarázva, hogy miért történtek konkrétan a dolgok, miért okoztak problémákat, és milyen szempontok változhatnak a jövőben.

2. nap: Tesztelés

Azt a feladatot kaptam, hogy teszteljek pár funkciót az alkalmazás egyik repójában. Az új felvételi tesztek megírása nagyszerű módja annak, hogy megismertessék őket egy kódbázissal, és megismertessék őket az alkalmazás néhány logikájával.

Elég sok időt töltöttem azzal, hogy elolvastam a kódot, kitaláltam, hogyan működik mindez együtt, és láttam, hogy követni tudom-e a logika menetét. Érdekeltek a csapat által választott konvenciók, a kód felosztásának módja és a stílusbeli választások. A tesztek megírása nem volt nehéz, de mindig nagyon óvatos vagyok, amikor az első jelemet egy kódbázisra tettem, amin még nem dolgoztam!

Nem akartam, hogy a munkám kimaradjon, ezért megpróbáltam megfigyelni és elnyelni a jelenleg használt kódstílust. Bizonyos mértékben sokat segít az olyan jó gyakorlatok, mint a szöszölés, de vannak olyan általános építészeti és stílusbeli döntések is, amelyekben a szöszökés nem segíthet.

Egy kis kihívás volt, hogy hozzászoktam a csapat által alkalmazott Git munkafolyamathoz. Minden csapatnak megvan a maga módja a dolgok elvégzésére: egyes csapatok egyesülnek, egyesek újrabázolnak, vannak, akik elkötelezik magukat, mások pedig nem, mások követik az ehhez hasonló népszerű munkafolyamatokat, mások pedig akaratlanul akaratlanul kényszerítik a mestert. Ráadásul ott vannak az elfogadás üzenetének és a leírásnak a helyes kezelésre vonatkozó konvenciói, a felülvizsgálati folyamat és így tovább.

Összességében rengeteg nem kifejezetten „így csináljuk a dolgokat” cuccokat lehet felvenni. Miután párszor végigmentem a folyamaton, kijavítottam hibáimat és feltettem kérdéseket, ez már a második természet.

Folyamatosan jegyzeteket írtam egy füzetbe, és kódrészleteket tartottam a Bear nevű alkalmazásban. Annyi mindent be kellett vállalni - hogyan kell csinálni a dolgokat, a csapat által preferált eljárásokat, olyan dolgokat, amiket korábban nem csináltam, valamint új nyelveket és keretrendszereket, amelyeket meg kellett tanulni.

Nagyon aktívnak kellett lennem abban, hogy megjegyezzem, amit tanultam. Minden nap végén vagy elején megfogalmaztam, hogy áttekintem a jegyzeteimet, további magyarázatokat fűzök a sietve írt dolgokhoz, és olyan kutatási dolgokhoz, amelyeket nem értek teljesen. Mindez szintén eltartott egy ideig.

3. nap: Spiking AWS

A folyamatban lévő kiadás részeként el kellett döntenünk az általunk épített szolgáltatás telepítésének módjáról. Az AWS-t használtuk, de választhattunk egy EC2-példány használata között, amely a legegyszerűbb választás, mivel ez csak egy szerver a felhőben, amely futtatja az alkalmazást, vagy valami kicsit kedveltebb, mint az Elastic Container Service. Az ECS előnye, hogy kezelné több EC2 példány méretezését, és ezért jó lehetőség lenne a jövőben. De egyelőre nem volt teljesen elengedhetetlen.

Ennek fényében azt a feladatot kaptam (önként vállaltam), hogy megtudjam, milyen egyszerű lenne szolgáltatásunkat az ECS-re telepíteni. A spicc csak annyit jelent, hogy kipróbálunk valamit a megvalósíthatóság feltárása érdekében. Ha nehéz lesz, nem érte meg, mivel ez egy jövőbeli optimalizálás volt, amire most nagy szükségünk nem volt.

Ez sok tanulást jelentett számomra, mivel korábban nem használtam az Amazon ECS-jét, ráadásul az alkalmazás egy Rails alkalmazás volt, és sokkal kevésbé ismertem az egész Ruby / Rails ökoszisztémát. Talán összesen 30 órát töltöttem azzal, hogy megtanultam Rubyt, mielőtt beléptem a cégbe, mivel tudtam, hogy ez része a veremnek, de alig értem Railshez. Ráadásul a feladat egy kis munkát végzett a Dockerrel, ami szintén új volt számomra.

Technikai vezetőm arra késztetett, hogy alapvetően egy órás intróval kezdjem a Docker-t, ami rendkívül hasznos volt. Innentől kezdve a nap nagy részét új Rails alkalmazás létrehozásával töltöttem, és különféle cikkeket, dokumentumokat és példákat követtem, hogy megtudjam-e futtatni a dolgot az ECS-en. Majdnem eljutottam oda, de az adatbázis-integráció működőképessé tétele buktatónak bizonyult. Annyi új dolog volt.

Biztos vagyok benne, hogy valaki, aki jobban ismeri az ECS-t vagy a Rails-t, nem lett volna akkora baja. Nem tudtam elmenni azzal, hogy a folyamat objektíve nehéz volt. Nehéz volt nekem , de ez nem azt jelentette, hogy mindenkinek nehéz volt.

Nem egy rendkívül eredményes nap a használható kód vagy kimenet szempontjából, de úgy éreztem, hogy sokat és abból a szempontból tanultam, és nagyon jó volt.

4. nap: Párosítás és mentorálás

Reggel 8 órakor érkeztem meg az irodába, és amíg mások érkezését vártam, egy Docker tanfolyam egy részét követtem, amelyet a Pluralsight-on figyeltem. Még mindig szívesen fejeztem be a tegnapi csúcsot, de felismertem, hogy több megalapozásra van szükségem legalább egy új technológiához, amellyel együtt dolgozom.

Körülbelül egy órát töltöttem a tanfolyamon, mire többen megérkeztek az irodába, és nekiláttunk annak eldöntésében, hogy ki mit csinál. Egy másik új fejlesztő, aki egy kicsit előttem indult, éppen visszatért az ünnepről. Úgy döntöttünk, hogy párosítunk egy feladatot. Új funkciót építettünk a Rails alkalmazásban. Ez meglehetősen egyszerű feladat volt, de a Rails mindkettőnk számára új volt, így nagyon jó volt együtt dolgozni. Amikor valami magyarázatra lenne szükségünk, egyszerűen kérdezzük meg a többi fejlesztőt, akár személyesen, akár a Slack segítségével. Remek megbeszéléseket folytattunk ezen a módon, és kezdtem belekötni a Rails működésébe.

Délután mentorálást tartottam a technológiai vezetővel, amely nagylelkű volt, mivel előző nap már volt egy privát Docker osztályom! A mentorálás lehetőséget nyújt kérdések megválaszolására, a problémák együttes átfutására, közös tanulásra, vagy csak az agy kiválasztására. A tudástranszfer nagyon hasznos.

Sok furcsa kérdésem volt az adatbázis cuccaival és a Rails-szel kapcsolatban, de sajnálom, hogy egyetlen célom nem volt az első munkamenetre. Azt hiszem, nem voltam biztos benne, mire számíthatok. A következő ülések során megkértem a mentort, hogy mutassa meg nekem, hogyan tegyek valami konkrét dolgot, például egy NGINX szerver konfigurálását vagy egy EC2 példány konfigurálását, hogy hozzáférhessenek egy adatbázishoz - olyan dolgokat, amelyeket már tudna, de sokkal tovább tartana kint egyedül.

5. nap: Találkozók és összevonások

Számos szoftvercsapat a stand up találkozók (gyakran naponta), a rendszeres visszatekintések (a munkamódszerekkel vagy a technikai kérdésekkel) és a tervezési munkamenetek kombinációit használja a munkafolyamat magas szintű szervezéséhez, valamilyen nyomkövető eszközzel kombinálva. A haladás és a tennivaló munka vizualizálható.

Csapatunk sem különb, és a tervezett találkozóink többségét pénteken tartjuk. Sok csapathoz hasonlóan az összejöveteleken is az a hangsúly, hogy átgondoljuk, hogyan dolgoztunk és mit értünk el, közösen oldjunk meg minden problémát vagy blokkot, és azonosítsuk és megtervezzük a közelgő munkákat, hogy mindig legyen valami előre készen állunk továbblépni.

Mi is kimegyünk reggelizni kötődni, ami fantasztikus!

Összességében a délelőtt nagy részét ezekre a tevékenységekre fordítottuk. Kevés hozzájárulásom volt, mivel még mindig a terminológia és a termék felépítése körül jártam a fejem, és mindig egy mondat mögött voltam, és megpróbáltam utolérni az imént elhangzottakat. Emlékszem, hogy az első héten csak azt éreztem, hogy olvad az agyam, amikor megpróbáltam az agyamban tartani az építészet összes összetevőjét (az idő előrehaladtával jobb lesz, úgyhogy ne aggódj!).

Délután a párommal befejezhettük azt, amin dolgoztunk, kértük a kód felülvizsgálatát, módosításokat hajthattunk végre, és kérelmet nyújthattunk be munkánk beolvasztására az alkalmazásba. Nem vetettük be, mivel péntek délután volt, de a következő hétfőn. ?

Köszönjük, hogy elolvastad, remélem, hogy ez a cikk némi ötletet adott arról, hogy milyen lehet az első héted fejlesztőként.

Szeretném hallani észrevételeit és tapasztalatait!