Íme, amit kilenc hónap alatt tanultam meg szoftvermérnöki munkám során

Körülbelül kilenc hónapig dolgoztam a Dexternél szoftverfejlesztőként. Írtam egy blogbejegyzést a munka kezdeti leszállásáról, valamint egy technikai bejegyzést egy önpozicionáló alkatrészről, amelyet az első pár hónapban készítettem a cégnél. A munka megszerzése volt a kezdeti célom, a megtartás és a fejlesztőként való növekedés pedig a következő természetes lépés volt.

A szerepemmel kapcsolatos gondolataim kezdettől fogva jelentősen megváltoztak. Úgy gondoltam, hogy fejlesztőnek lenni a kód lehető leggyorsabb feltöltését jelenti. Ez a legmesszebb a valóságtól. A sok gagyi kód gyors kivágása nem skálázható módja az üzleti élet fejlesztésének vagy a karrier fejlesztésének. Szerencsére találtam egy munkáltatót, aki ugyanígy érzett és terméke a szoftver.

A cél éppen a megfelelő mennyiségű jó kód megírása és a jó kommunikáció. Nem a kódért fizetnek, hanem azért, hogy gondolkodj és kitaláld a problémákat. A melléktermék kristályosított gondolat és utasítás, amelyet egy gép követhet kód formájában. Inkább megoldok egy problémát egy jól olvasható kódsorban, mint 10 nehezen érthető kódsorban. Inkább megoldok egy problémát 5 soros, olvasható kommentált kódban, mint egy sor nagyon összetett, többszörösen beágyazott kódban, több terner operátorral. Megkapja az ötletet.

Tegyen fel sok kérdést, és dokumentálja a válaszokat

A főnököm elküldte nekem ezt a linket, amely sok olyan stresszt és szorongást foglal magában, amelyet új mérnökként érzek. Alábecsülés azt mondani, hogy nagyon öntudatos vagyok a kérdések feltevésében.

Ezt az ellenőrzőlistát használom, mielőtt mások segítségét kérném:

  • Ezt a kérdést már feltettem korábban, és ha igen, hol dokumentáltam a választ?
  • Lehet, hogy tudnám a Google-t?
  • Ezt valahol valaki más belsőleg dokumentálja?
  • Mi folyik itt? Mi a hiba vagy váratlan viselkedés kiváltó oka?
  • Tényleg megértem azt a kérdést, amelyre próbálok válaszolni? Nem baj, ha szán egy kis időt, és újra átolvassa a problémát, ahelyett, hogy félszamár vagy rohanó választ adna.

Ezeknek a lépéseknek az elvégzése után egyedül megoldom a problémát, megtalálok egy dokumentált megoldást, vagy sokkal jobb kontextusban és részletességgel teszek fel egy kérdést, amely megkönnyíti, hogy valaki más segítsen nekem. Még jobb, ha jó kérdést teszek fel, és csevegés közben megválaszolható, a csapattársamnak nem kell mindent ledobnia, hogy segítsen nekem.

Ha az út 90% -át megtettem a probléma megoldása felé, és csak az utolsó 10% -ra van szükségem, akkor egy idősebb fejlesztő örömmel segít abban, hogy tudjam, egyedül jutottam el a lehető legmesszebbre. Ha valaki mást keres a problémáinak megoldására, az nem nagyszerű módja a bizalom kialakításának a csapatában.

Az okos emberek szeretik a jó kérdéseket - ezért tedd fel őket.

Kerülje el ugyanazokat a hibákat és ne tegye fel ugyanazokat a kérdéseket újra és újra

Ezt könnyebb elmondani, mint megtenni, és ez minden munkára igaz lehet, nem csak programozásra. Sok új fogalom és információ kerül eldöntésre, és elkerülni a hibákat. Legyen tisztában ezzel. Gondolkodjon, mielőtt kérdezne. Google cucc. Nézd meg a dokumentumokat. Ők a barátod. Ha trendet lát, próbálja meg azonosítani. Tegyen aktív erőfeszítéseket arra, hogy elkapja magát, ha azonos típusú kérdéseket tesz fel. Írja le, és tűzze ki célul a javítását.

Győződjön meg arról, hogy ha legközelebb ugyanazzal a problémával találkozik, tudja, mit kell tennie. Mindannyian hibázunk, de mindenki öntudata és erőfeszítése a változás érdekében mindenki jobbá válik.

Mindig nézze át munkáját

Senki sem szereti, ha átmegy egy PR-n, és azt kéri, hogy távolítsa el a console.logs és a hibakeresőket, vagy azt mondja, hogy javítsa a szöszös hibákat. Nem tenném közzé ezt a bejegyzést anélkül, hogy elolvasnám párszor, és hogy egy barátom is megnézné.

Nézd meg igazán a kódodat, és tedd fel magadnak ezeket a kérdéseket:

  • Összetett logikát írtam. Van-e hasonló funkció az alkalmazásban, ami talán olvashatóbb, rugalmasabb vagy általánosabb módon teszi ezt meg?
  • Ha nem, emlékszem, miért írtam ezt a kódot egy hét alatt? Ha a válasz nem, akkor valószínűleg módosítani szeretném a kódot, vagy megjegyzést fűznék hozzá. A PR-t átnéző személynek valamilyen összefüggésben kell lennie azzal, hogy miért hoztam meg ezt a döntést.
  • Mielőtt másnak átadná, ellenőrizze, hogy a kód megfelel-e a szöszökésnek és a teszteknek
  • Ismétlem magam? Beilleszthetem az ismételt logikát egy függvénybe?
  • Ha ez más kódja volt, amit átnéztem, milyen megjegyzéseket tennék? Mit szeretnék változtatni, hogy egyenesebb legyen?

Nézze meg kódját friss szemmel (talán másnap). Van-e olyan speciális logikai elemzés a komponensekre, amelyeknek nem szabad? Az alkatrészei olyan üzleti logikát kezelnek, amelynek egy tárolóba kellene kerülnie?

Ezenkívül a jó önkód-ellenőrzés időt és pénzt takarít meg a vállalat számára. Így sokkal olcsóbb megtalálni saját hibáit, és saját maga kijavítani azokat, nem pedig azt, hogy valaki más találja meg őket két nappal később.

Utolsó dolog a kód felülvizsgálatával kapcsolatban. Érintse meg és kattintson MINDEN, amin dolgozott. Azt akarom, hogy a bárkinek küldött kódot rendkívül nehéz feltörni. Ha rákattintanak egy új oldalra, és nagy hibát vagy fehér halálos képernyőt kapnak, az azt mutatja, hogy nem igazán néztem át a munkámat. Nézzen utána a szerkesztett kódnak, és győződjön meg róla, hogy nem tört-e meg mást a megosztott összetevő hozzáadásával.

Butaságnak tűnhet, de a nagy kódbázisok összetettek, és előfordulhat, hogy nem veszi észre, hogy elront valamit, amíg nem teszi meg.

Komolyan, nem szeretné látni ennek a blogbejegyzésnek az első piszkozatát :)

Semmi sem varázslat

Általában jó oka van annak, hogy a kód miért került LGTM-be (jóváhagyva és a kódalapba). Ha nem érti a működését, töltsön egy kis időt a kitalálásával. Naplózza, megtöri a dolgokat, nézze meg a használt funkciók és minták néhány dokumentációját.

Meg tudnád mondani a gumikacsának, hogy működött? Ha még mindig nem biztos benne, tegyen fel néhány kérdést a megértés konkrét hiányosságaival kapcsolatban.

Kényelmezze a hibakeresést, mivel sokat csinál

A hibakeresés azt jelenti, hogy meg kell érteni a kód működésében rejlő alapvető problémát, majd megoldani a hibát. Meg kell értenie a dolog működését, hogy rájöjjön, miért nem működik eleve. Az, hogy használni tudja a böngésző hibakereső eszközeit, megkönnyíti az Ön életét és munkáját. A hibakereső és a konzolos módszerek a barátai.

Néhány hasznos forrás, amelyet találtam:

  • CSS trükkök a hibakeresésről
  • Front-End Masters hibakeresés (fizetett, de nagyon jó)

Pro-tip: a console.log kimenet stilizálható CSS ​​használatával. Ez megkönnyíti a látni kívánt napló azonosítását.

console.log('%c I want this to be big and red', 'font-size: 30px; color: red;');

Kövesse az adatokat

Ez újra és újra felmerült, mert bevallom, hogy hibát követtem el. Ez valami jobb lett, de még mindig munkára van szükségem.

A szoftverfejlesztés nagy része magában foglalja az adatok formátumba történő manipulálását, hogy a felhasználó cselekvőképes betekintést nyerhessen belőle, vagy saját maga frissíthesse.

Az egyirányú adatáramlással rendelkező és globális állapotú alkalmazások közvetlen adatvonalat követnek. Minden adat valahonnan származik. Miután megtudta, honnan származik, könnyebb hibakeresés.

Szigetelje el problémáit, majd integrálja azokat abba, amivel dolgozik

A Codepen.io közeli barátom, és neked is ennek kell lennie. Amikor nem tudom kitalálni, mi okozza a problémát, elkészítem egy egyszerű verzióját annak, amit építek. Gondoskodom róla, hogy működjön, majd beépítem a fejlesztői környezetembe. Könnyebb kitalálni, hogy mi lehet a felhasználó kezelőfelületének megszakítása egy lecsupaszított környezetben.

Gondoljon arra, hogyan kell működnie a funkcionalitásnak

Az, hogy valaminek működnie kell egy 30.000 ft-os szintről, majd egy technikai szintről, segített megértenem, mit kell építenem, hogyan kell építenem, és segít enyhíteni a gödör zuhanását. Ha nem tudom megmagyarázni, hogy az általam épített dolog hogyan működik (magas és alacsony szintről), akkor rosszat teszek magamnak. Terv nélkül a közeljövőben sokat fogok kerekezni.

Ezenkívül visszautalhatok arra, amit írtam, vagy megmutathatom valakinek, mire gondolok, ami segít csökkenteni a téves kommunikációt.

Ölelje át a küzdelmet

10000 órás munkahelyi küzdelem után sokkal jobban tudsz küzdeni és megoldani a problémákat. Mindentől függetlenül meg kell tennie, így az élmény élvezetével sokkal, de sokkal jobbá válik a mindennapja. Nevessen el egy kicsit magán, és próbálja meg igazán lebontani a problémát. Még akkor is eljutsz, ha szükséged van egy kis extra segítségre.

Vegyen konstruktív kritikát és folyamatosan ismételje meg

A csapattársak azt akarják, hogy jobban járj. A vezető fejlesztők erősebb fejlesztővé akarnak tenni. Akkor járjon el az ő tanácsuk alapján, ha kezdetben nem érted, miért mondják neked. Soha egyetlen ember nem tud mindent. Csevegjen.

Nem kell kapkodni

A munkáddal való rohanás oda-vissza, sok zavart és további frusztrációt okoz. A főnököm inkább később látna jobb kódot, mint rosszat. Úgy értem, nem mindannyian?

A tanulás folytatása munkán kívül

Bármennyire is tanulok a munkahelyemen, továbbra is szeretnék új dolgokat tanulni azon kívül, hogy csak a kódalapunkon dolgozom. Ez lehet a Python felvétele, egy bot építése, egy videósorozat vagy egy személyes projekt kidolgozása. Készítettem egy táblát a Zenhub + Github-szal, hogy nyomon kövessem, hol vagyok és mire vállalkoztam a hónap során. A hónap általános céljának betartása arra kényszerített, hogy tovább tanuljak, építkezzek, és igen, a saját időmben blogoljak.