Ess dit første år som juniorudvikler med dette råd

Er du en juniorudvikler, der går i gang med din softwareudviklingskarriere?

Eller en nyuddannet datalogi, der for nylig er startet på et nyt job?

Måske en selvlært udvikler, der spekulerer på, hvad de skal gøre næste?

At starte din softwareudviklingskarriere kan være skræmmende, men også meget spændende.

Jeg kender følelsen af ​​at have været der selv. I løbet af de sidste 4 år er jeg gået fra juniorudvikler til lederudvikler ved en SaaS-opstart, hvor jeg lærer meget undervejs.

Jeg har skrevet denne guide med mine bedste tip, for ikke kun at overleve, men stræbe i dit første år som juniorudvikler.

Det er OK at have huller i din viden

Universitetsgrader, kodning af boot camps og onlinekurser gør et godt stykke arbejde med at lære dig at kode.

Alligevel er sandheden, at i den virkelige verden af ​​softwareudvikling er der lidt mere ved det end at skrive kode. Du bliver nødt til at forstå:

  • Hvilke teknologier er bedst til forskellige problemer
  • Kode skrevet af andre mennesker
  • Design mønstre og bedste praksis
  • Sådan testes kode
  • CI / CD, kildekontrol og forgreningsstrategier
  • Softwareudviklingen livscyklus og forskellige metoder
  • Arbejder ikke kun med dit team, men med andre teams, ledelse og klienter

... for at nævne et par ting.

Du kender måske allerede nogle af disse ting, eller du har måske aldrig hørt om noget af det før. Og det er OK. Du er der som en junior softwareudvikler, din manager og dine teamkammerater ved dette.

Så der vil være huller i din viden. Hver udvikler har dem! Bliv ikke overvældet, hvis det hele ikke giver mening med det samme.

Faktisk er en del af skønheden ved at være softwareudvikler, at teknologien altid ændrer sig. Vi lærer altid, uanset hvilket niveau vi er på.

Spørgsmål er gode - det er også at spørge om hjælp

Du har din første opgave, du bliver ophidset og dykker lige ind. Men så ... er du fast. Din kode fungerer ikke som forventet, og alt hvad du skal gå forbi er en mærkelig, forvirrende fejlmeddelelse.

Stumpet, du tænker på at bede en af ​​de andre udviklere på dit team om hjælp, men du tænker:

”Hvad hvis de synes, jeg er stum? eller at jeg ikke kan kode? og griner af mig ?! ”

Men i virkeligheden vil det aldrig ske. Hvad de faktisk vil tænke er:

”OK, jeg ser hurtigt og ser om jeg kan hjælpe. Ah! Ja, jeg har stødt på dette problem før, du kan bruge someMethod () fra somePackage () til at ordne det. ”

Hvilket er ikke så dårligt, ikke?

Dit team er der for at støtte dig, især i de tidlige dele af din karriere, så spørg dem om hjælp.

Ligeledes, hvis du ikke forstår noget, skal du stille spørgsmål. Jeg stiller stadig mange spørgsmål hver dag! Der er ikke noget som et dumt spørgsmål. Dit team vil hellere hjælpe dig i stedet for at lade dig stirre på din skærm med forvirring det meste af dagen.

Kodeanmeldelser er din ven

Jeg vil aldrig glemme min første kodeanmeldelse som en del af mit første juniorudviklerjob. Min kode blev gennemgået af en erfaren seniorudvikler. På det tidspunkt fandt jeg denne nerveindpakning. Og selvfølgelig var der flere kommentarer fra ham, end jeg kunne tælle!

Men bagefter var dette en god ting.

Kodeanmeldelser er ikke et stadium til kritik, men for at lære og give feedback fra alle sider.

Seniorudvikleren satte sig sammen med mig og forklarede, hvad hver af kommentarerne betød, og også hvorfor han havde lavet dem. Naturligvis lærte jeg meget. Så når din kode gennemgås, skal du huske, at enhver feedback er til at hjælpe dig med at lære og forbedre dig som softwareudvikler.

Ligeledes når du kommer til at gennemgå kode for andre mennesker, vil du være i stand til at se, hvordan forskellige mennesker nærmer sig forskellige problemer. Du vil endda hjælpe dem med at forbedre dig ved at komme med dine egne forslag!

Nedbryd det, og nedbryd det lidt mere

Ok, så du har din første virkelige opgave, afhængigt af opgavens størrelse, kan du føle dig lidt overvældet:

”Hvor starter jeg? Jeg vil nok starte med at gøre X, men hvad med Y? Men så hvis jeg gør Y, er der A, B og C ... hvad sker der med X igen ?! ”

Bare rolig, vi har alle været der. Det er let at gå tabt i det mundtlige kaninhul, når man prøver at løse et problem. Næste gang du har et stort problem at løse, prøv at huske dette tilbud,

”Hvordan spiser du en elefant? En bid ad gangen. ”

Med andre ord, lav en opgave, der synes umulig at være mere håndterbar ved at opdele den til mindre opgaver.

Så hvordan gør du det?

Inden du skriver nogen kode, skal du prøve at skrive trinene ud på almindeligt engelsk (eller det sprog, du vælger). Lad os tage et eksempel.

Hvordan hælder du et glas vand?

En almindelig engelsk tilgang ville være

  1. Åbn skabet
  2. Hent et glas
  3. Placer glas under hanen
  4. Tænd for hanen
  5. Når glasset er fuldt, skal du slukke for hanen
  6. Fjern glas under hanen

Ved at skrive trinene ud er det lettere at visualisere hver del af problemet og komme med en løsning for hvert trin.

Hold det simpelt

En almindelig fejltagelse, som mange juniorudviklere begår (mig selv inkluderet da jeg startede) er at prøve at opfinde hjulet igen.

Det ser måske imponerende ud for at løse et problem ved at bruge en super-fancy teknik i din kode.

Men dette medfører andre problemer:

  • Kode, der er helt anderledes end, hvordan lignende dele af systemet er sværere at vedligeholde
  • Din kode kan blive mere ordlyd, som den skal være, og der vil være en øget risiko for fejl
  • Det kan tage dig længere tid at gennemføre din opgave

Så hvordan præcist holder du det enkelt?

  1. Få det til at virke. Tænk ikke for meget, og gør hvad din tarm siger for at få din kode til at fungere
  2. Refactor. Nu hvor din kode fungerer, er det tid til refaktor. Gør din kode let at læse ved at navngive tingene godt og bruge korrekt formatering. Mere om dette i 'Lær hvordan du skriver ren kode' nedenfor
  3. Fremskyn det. Når du er færdig med refactoring, vil du muligvis bemærke flaskehalse i udførelsen af ​​din kode. Nu er det tid til at optimere det. Vær forsigtig med ikke at falde i fælden ved at optimere for tidligt! Gør kun dette, hvis du har brug for det.

BONUS TIP. Overvej at skrive nogle mislykkede prøver, før du skriver en kode. Dette kaldes Testdrevet udvikling. Dette giver dig ikke kun en god testdækning, men det vil hjælpe dig med at tænke over strukturen i din kode.

Lær hvordan du skriver ren kode

Mastering af ren kode vil få dig til at skille dig ud som softwareudvikler.

Så hvad mener vi nøjagtigt med ren kode?

  • Følger S.O.L.I.D-principperne
  • Det er testbart og vedligeholdeligt
  • Det er let at læse og følge

Med andre ord:

Enhver nar kan skrive kode, som en computer kan forstå. Gode ​​programmører skriver kode, som mennesker kan forstå. - Martin Fowler

Jeg vil ikke gå for detaljeret ind her, ligesom bogen Clean Code: A Handbook of Agile Software Craftsmanship af Robert C Martin vil give en meget dybere indsigt i dette område. Hvis du er seriøs med at skrive ren kode og bryde ud af juniorudviklerniveauet, vil jeg varmt anbefale denne bog.

Skrivning af ren kode viser, at du brænder for, hvad du gør, og kan skabe vedligeholdelig pålidelig software. For ikke at nævne, at du vil gøre livet lidt lettere for den næste person, der kommer med for at føje til din kode.

"Der er et bibliotek til det"

Har du nogensinde fortalt en ven om et problem, du havde, og de svarer med "Ja, der er en app til det"?

Softwareudvikling er lidt sådan.

Der er allerede mange svar på de problemer, du prøver at løse. Så når du prøver at udføre en opgave, skal du kontrollere, om en anden allerede har løst problemet.

Du kan gøre dette ved at:

  • På udkig efter eksisterende pakker og biblioteker
  • Gennemse steder som GitHub og StackOverflow for at finde lignende løsninger på dit problem.

Hold det lige der! Dette giver dig ikke frie tøjler til at kopiere og indsætte kode uden en tanke. Hvis du bruger en andens kode som eksempel, er det vigtigt, at du forstår, hvad deres kode laver, og hvorfor.

  • Hvorfor bruger det et bestemt designmønster?
  • Hvorfor er det skrevet på et bestemt sprog? (Node.js vs Python for eksempel)
  • Hvad er ulemperne? Vil det arbejde med din nuværende kodebase?

Hvis du ikke er sikker, kan du bede nogen på dit team om vejledning. Søgning efter Google efter et svar er en almindelig tilgang til løsning af kodningsopgaver. Så vær ikke bange for at vende dig til dine holdkammerater og sige:

"Jeg tænker på at bruge dette bibliotek X eller denne pakke Y, jeg har set nogle eksempler her, hvad synes du?"

Dette viser ikke kun, at du er proaktiv, men det vil også udløse en del samtale / debat fra teamet. Du har måske opdaget noget fantastisk, som ingen andre vidste endnu om!

Lær hvordan du læser kode

Vi har alle set disse film. Dem, hvor en hacker hurtigt skriver, når sider med kode ruller ned på skærme foran dem.

I den virkelige verden bruger udviklere mere tid på at læse kode end faktisk at skrive kode.

Når du tilføjer nye funktioner eller løser mangler, bliver du nødt til at forstå den aktuelle kodebase, du arbejder på. Hvordan gør du det? Læs, læst, læst!

Læsning af kode er også en gavnlig læringsteknik. Ved at læse eksisterende kode kan du se, hvordan andre har udviklet en bestemt funktion.

Ting at holde øje med:

  • Brug af designmønstre
  • Navngivelse af metoder, klasser og variabler
  • Brug af kommentarer
  • Sådan struktureres projektfiler
  • Brug af test og hvordan de er struktureret

Så hvor finder du kode til at læse?

  • Lagre i din kildekontrol på arbejdet
  • Projekter på GitHub
  • Læs svar / spørgsmål om StackOverflow
  • Kodeudfordringswebsteder som codewars.com, der viser svarene på udfordringer

Hav det sjovt!

Hvis du fjerner en ting fra denne artikel, så lad det være dette - er det vigtigt at have det sjovt. Nyd at skrive kode, løse problemer og fortsætte med at lære. Du er i starten af ​​en spændende karriere, så læn dig tilbage og nyd turen!

BONUS TIPS

  • Lær lingo. Vi udviklere har vores eget sjove sprog ("at oprette en gren" har intet at gøre med træer!) Så sørg for at du forstår de vigtigste udtryk
  • Lær din IDE at kende. Lær genvejstasterne, genveje og tilpas det, indtil du er tilpas med det. Dette øger din produktivitet.
  • Arbejde med bugs er en fantastisk måde at lære om kodebasen. Så vær ikke bange for at hente disse op!
  • Medbring en notesbog, lyt med vilje og skriv alt ned.
  • Tag på nogle sideprojekter på din fritid. Det er en fantastisk måde at lære forskellige teknologier, som du ikke lærer i dit dagjob, og som vil øge dit CV.
  • At blive involveret i arbejdsbegivenheder er en fantastisk måde at lære dine kolleger at kende på. Hvorfor ikke organisere en selv?

Tak for at have læst!

For at få de nyeste guider og kurser for juniorudviklere direkte til din indbakke, skal du sørge for at deltage i adresselisten på www.chrisblakely.dev!