Sådan bliver du en Full Stack-webudvikler i 2020

Full stack webudviklere er den schweiziske hærkniv i kodeverdenen. At have den betegnelse betyder, at du kan producere end-to-end-løsninger, hvilket er en yderst omsættelig og smidig færdighed. Men hvad skal der egentlig til for at opnå denne status?

Uanset om du er ny, erfaren eller specialiseret i den ene ende af stakken, er der meget at fordøje her. Du er velkommen til at dykke ind fra toppen eller hoppe rundt til det sted, hvor du har mest brug for support.

  • Først og fremmest, hvad gør virkelig en udvikler fuld stack?
  • Lad os tale om dette fokus, inden vi dykker ind
  • Så hvor starter vi?
  • Frontend
  • Bagende
  • DevOps og skyen
  • Hvad med design?
  • Andre ting, hvis du lige er kommet i gang
  • Andre ting, hvis du leder efter mere

Først og fremmest, hvad gør virkelig en udvikler fuld stack?

Det er sjovt og summende at sige, at enhver front-end-udvikler er en full stack-udvikler, men at være i stand til at distribuere et websted til Netlify gør dig ikke fuld stack.

Dette er ikke beregnet til at være afskrækkende - bare realistisk, kun at have denne erfaring holder ikke godt med den jobtitel i dit næste interview. Mens du teknisk opretter og implementerer dit arbejde fra start til slut, giver Netlify, Zeit og andre udbydere dig magten til at gøre dette med deres magiske værktøjer, der tager størstedelen af ​​stakoperationerne ud af ligningen.

Det er ikke for at tage væk fra det, som vi alle er i stand til at udrette nu som frontend devs. Den voksende bevægelse for at kompilere og implementere statiske websteder har netop gjort denne proces enklere på den senere halvdel af stakken med fordele over hele linjen.

Derudover, med fleksibiliteten i værktøjsindstillinger som at kunne køre JS på en server, er vores færdigheder i stand til at overføre til flere brugssager end nogensinde før.

Hvor vi kom fra

Webudviklingslandskabet har ændret sig hurtigt. Wordpress har været konge CMS i et stykke tid nu og repræsenterer over en tredjedel af websteder, der bruger et CMS og hjælper PHP med at få popularitet. Men andre arbejdede med hjemmelavede løsninger.

Disse repræsenterede en mere traditionel webstak som LAMP. I disse tilfælde havde du webservere, der normalt kørte en slags indholdsstyringssystem og et serversidesprog (som PHP), der ville interface med databaser og producere den kode, der i sidste ende ville blive leveret til browseren.

Oven i det har du muligvis Javascript, der laver nogle interaktive funktioner med CSS, der administrerer visningen af ​​siden. I nogle tilfælde er det alt hvad du behøver for visse webhostere at have en administreret Wordpress-server. Men andre større websteder ville kræve et andet team til at administrere disse tjenester og implementere pipeline for at få koden ud til produktion.

Hvor vi er, og hvor vi skal hen

Mens Wordpress ikke går nogen steder, bygger de serverløse og JAMstack-arkitekturer fart. For de ukendte er ideen ikke, at der bogstaveligt talt ikke er nogen servere, men det handler mere om at bruge servere, der administreres til dig i skyen.

Tjenester som AWS Lambda giver dig mulighed for at opbygge en "funktion", der behandler enkel input og output. Vedhæft det til API Gateway, og du har straks et slutpunkt, du kan interface med uden nogensinde at skulle administrere en server.

Andre som S3 giver dig mulighed for at dumpe HTML, CSS, JS, billeder og alle andre statiske aktiver til lagring og tjene webstedet direkte fra det. Intet bliver behandlet på serveren, du serverer simpelthen de statiske filer til klienten.

Den strålende del ved dette er, at der er meget mindre omkostninger, og det er typisk en hel del billigere. I mange tilfælde får du også et enormt ydeevnehøjde, hvor betjening af et websted fra s3 kræver mindre behandling for at få det første svar til browseren, hvilket direkte kan svare til forbedret brugeroplevelse.

Dette er ikke for at skubbe dig til JAMstack, men for at vise, at hele stack-paradigmet skifter, og det er noget værd at se på. Der er stadig en traditionel fornemmelse af forskellen i arbejde, men det bliver lidt anderledes.

DevOps-hold administrerer nu skyressourcer og implementerer. Backend-udviklere bygger nu API'er og kode, der grænseflader med tjenester ved hjælp af værktøjer som lambda-funktioner. Og frontend-udviklere arbejder primært i Javascript building React- eller Vue-apps, der når ud til de tjenester, din backend-udviklere har oprettet. Formentlig kan dette måske omfatte ting som CSS, men det er en anden dåb orme om, hvilken titel det arbejde “officielt” falder ind under (spoiler: afhænger af holdet).

Mens der stadig er en opdelt pligtfølelse, sløres linjen og gør det mere håndterbart at sprede dit fokus.

Lad os tale om dette fokus, inden vi dykker ind

Det kan være ret fristende at ønske at dykke lige ind og dække hele spektret af en full stack-udvikler, men der er noget at sige om fokus. Dette er grundlaget for udtrykket "jack of all trades, master of none", hvor du forsøger at lære lidt af hver del af den fulde stak og aldrig rigtig mestre noget.

Dette kan være farligt, når du begynder at prøve at opbygge dine styrker som en ny udvikler. Så prøv at evaluere, hvilken type lærer du er, og giv dit fokus, hvor det betyder noget. Hvis du kæmper med en spredt læseplan, kan det ikke nødvendigvis hjælpe dig med at få den oplevelse, du har brug for til at lande det første job eller det drømmejob, du når ud til.

En ny tilgang kan for eksempel være at have et individuelt fokus, men at bygge de fulde stack-færdigheder omkring denne styrke. Dette kan være en frontend-udvikler, der kan implementere deres egne webapps og fortsætte med at bygge videre på den grundlæggende viden.

Oven i det er en del af at være en fuld stack-udvikler ikke nødvendigvis i stand til at sige, at du kender sprogene x, y og z. Forståelse af kode- og softwaredesignkoncepter såvel som at være i stand til at tackle enhver udfordring ved hånden, stablet til side, er det, der gør en god udvikler.

Bundlinjen, prøv at finde ud af, hvad der er bedst for dig, og lad ikke din høje ambition komme i vejen for at mestre din rejse.

Så hvor starter vi?

I forbindelse med denne artikel vil vi holde fast ved de traditionelle breakpoints for, hvad der opdeler stakken (frontend, backend osv.). Selvom nogle mennesker siger, at det ikke rigtig er en ting mere, er der realistiskvis masser af job til full stack-udviklere og dag til dag, de henviser til de traditionelle breakpoints. "Full stack-udvikler" går bestemt ikke nogen steder.

Så vidt stakken går, vil vi læne os på de serverløse / JAMstack-arkitekturer, da det bare fortsætter med at vokse. Og hvis du lærer dem, vil det kun gøre dig mere salgbar med antallet af job, der dukker op omkring det.

Som du vil bemærke nedenfor, er det ikke meningen, at det hele skal omfatte alle typer databaser og alle typer gengivelsesløsninger. En stærk udvikler skal være i stand til at være fleksibel med deres værktøj og nå ud til at forstå begreberne i deres arbejde i stedet for at være ensartet og kun være i stand til at være produktiv inden for en ramme.

Mens du muligvis arbejder i React og har det godt i dit nuværende job (det er okay!), Kan dit næste job være tungt for Vue eller "overraskelse!" din teamleder vil omskrive appen i Svelte. Prøv at forstå, hvorfor du i første omgang bruger en brugergrænseflade, og hvordan det hjælper dig med at løse det aktuelle problem.

Lad os nu komme ind i det ...

Frontend

Frontenden af ​​et websted eller en applikation er typisk det brugergrænseflade, som den person, der bruger din tjeneste, interagerer med. Den største sprogspiller i spillet er Javascript, hvor du typisk læner dig på UI-biblioteker som React eller Vue for at styre komponenterne i dit projekt.

Brug af disse UI-rammer giver dig mulighed for at oprette "komponenter", i det væsentlige kodeblokke, der ender med at producere HTML med evnen til at skabe interaktioner og dynamiske tilstande lige sammen med din kode. Dette bliver virkelig stærkt, og selvom der muligvis er en lille kurve at starte, bliver det ret dejligt at arbejde med, når du først har fået fat i det.

Uanset om det er nyt inden for marken eller godt erfarent, kan du til sidst løbe ind i jQuery. Selvom det har sine fordele og har tjent samfundet godt, er Javascript's oprindelige funktioner virkelig vokset og skabt mindre efterspørgsel efter den funktionalitet, jQuery var i stand til at levere. Nu læner devs sig på UI-rammerne og det oprindelige Javascript i stedet.

Så det er godt at forstå, hvad jQuery er, men jeg anbefaler ikke at tage sig tid til at lære det på dette tidspunkt. Den gode ting er, at hvis du lander et job, der bruger det, kan du skrive native Javascript lige sammen med jQuery, så det er det rigtige svar at lære vanille Javascript.

Så hvad skal jeg lære?

Hvis du virkelig er nybegynder, skal du tage dig tid til at lære grundlæggende HTML og CSS. Det er måske ikke så sjovt og attraktivt som at grave lige ind i Javascript, men at bygge på det grundlæggende i det, der gør nettet, vil være nøglen til at starte med højre fod.

Lær derefter Javascript. Det vil forblive konge i overskuelig fremtid. Javascript giver grundlaget for enhver ramme eller ethvert bibliotek, som du bygger på, så det at forstå, hvordan bits og stykker i selve sproget fungerer, hjælper dig med at rejse dig igennem din rejse med at lære den forreste side af tingene.

Det vil også gøre dit liv lettere, når du prøver at forstå nogle af kompleksiteten i forskellige mønstre og koncepterne bag de rammer, du vil bruge.

Apropos rammer er React og Vue sandsynligvis de bedste kandidater i betragtning af deres popularitet. React er den mest populære blandt flokken og vil bare fortsætte med at vokse. Dens team arbejder konstant på at modne rammen og producere API'er, der hjælper med at opbygge moderne, hurtige webapps.

Kom godt i gang med Create React App eller Gatsby vil endda hjælpe dig med let at dreje en React-app op og straks komme i en position, hvor du kan pille rundt i koden.

Mens der ville være fordele ved at kalde CSS-forprocessorer og værktøjer som Sass ud, er der nu masser af løsninger til CSS, herunder CSS-in-JS.

Mens det at placere CSS inde i JS har nogle fordele og ulemper, er det ikke nødvendigvis værd at påpege, hvad man skal bruge som en bestemt retning, da det virkelig vil være teamafhængigt.

At forstå det grundlæggende og styrken ved CSS og hvordan man bruger det i sin vaniljeform hjælper dig med at forberede dig på at bruge det uanset rammerne.

Ressourcer

  • freecodecamp.org Responsiv webdesigncertificering //www.freecodecamp.org/learn
  • “Sæt Javascript ned: Lær først HTML & CSS“ //www.freecodecamp.org/news/put-down-the-javascript-learn-html-css/
  • MDN Intro til Javascript //developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript
  • Just Javascript e-mail-kursus //justjavascript.com/
  • JSRobot Learning Game //lab.reaal.me/jsrobot/
  • reactjs.org Introduktion til React //reactjs.org/tutorial/tutorial.html
  • gatsbyjs.org Tutorials //www.gatsbyjs.org/tutorial/

Bagende

I JAMstack-verdenen henviser bagenden generelt til de API'er, som vores frontend bruger til at skabe dynamiske oplevelser ved at interagere med slutpunkter fra klienten (som dem i CRUD API'er). At være i stand til at fremsætte disse anmodninger fra klienten fjerner behovet for at skulle foretage nogen af ​​denne behandling, før siden serveres til browseren.

Selvom du ikke skulle føle, at du kun nogensinde kan kode på et sprog, giver det en god fordel her at være i stand til at skrive i Javascript, da du kan vokse til det grundlæggende ved at arbejde med bagsiden af ​​tingene med et velkendt sprog (eller omvendt med frontenden).

NodeJS er en almindelig runtime, som du finder i de fleste skymiljøer som en mulighed, og vil give dig en lignende oplevelse som hvad du forventer i en browser. Den største forskel er, at du ikke har adgang til bestemte browser-API'er, og der vil heller ikke være et windowobjekt og API'erne tilknyttet det.

Når det er sagt, er Python også et andet populært sprog og vokser, især i betragtning af dets popularitet i datalogi og ingeniørfællesskab. Mens PHP og Ruby begge er gyldige og giver dig muligheder på jobmarkedet, ser det ikke ud til at være så populære og ikke så meget på en samlet opadgående tendens som Javascript og Python.

Med det sprog du vælger, vil dit bedste valg være at lære at oprette skytjenester, som dine applikationer kan interface med.

Oprettelse af en simpel lambda, som du kan lege med, hvad enten det er i AWS, Netlify eller enhver anden skyudbyder, giver dig en god oplevelse af, hvad du kan forvente, når du arbejder i marken.

Og selvom du måske ikke udvikler dig direkte i en lambda i det job, du finder, kan du begynde at blive fortrolig med begreber, der er grundlæggende for at arbejde med bagenden. Og du bruger i sidste ende disse funktioner til at oprette forbindelse til andre tjenester og databaser for at oprette dine egne dynamiske tjenester.

Så hvad skal jeg lære?

Hvis du allerede arbejder på at lære Javascript fra forsiden af ​​tingene, skal du fortsætte ved at bruge Javascript til din backend. Spin en lambda op ved hjælp af Netlify-funktioner, hvor du bare skal fokusere på koden, og Netlify tager sig af resten (som at få din funktion bygget og implementeret).

Med dit valgte sprog og din første funktion, prøv at begynde at arbejde med andre tjenester inden for din kode for at få erfaring med at arbejde med tredjeparts API'er.

Måske opbygge et slutpunkt, der kan sende en tweet ved hjælp af Twitter API (men misbrug det ikke). Lær hvordan du opretter en database og indstiller din funktion til at interface med den i et CRUD-mønster, hvilket giver dig en mere realistisk brugssag for, hvordan en typisk app kan interagere med en backend.

Dit mål her skal være at skabe tjenester, som din frontend vil interagere med via et slutpunkt for at udføre operationer for den person, der bruger din app. Den gode nyhed får skyens momentum, du har masser af muligheder og gratis muligheder eller niveauer, du kan begynde at lege med.

Ressourcer

  • “Super simpel start til serverløs” //kentcdodds.com/blog/super-simple-start-to-serverless
  • “Opbygning af serverløse CRUD-apps med Netlify-funktioner og FaunaDB“ //www.netlify.com/blog/2018/07/09/building-serverless-crud-apps-with-netlify-functions-faunadb/

DevOps og skyen

DevOps stammer fra behovet for at være i stand til at skabe løsninger, der udjævner og fremskynder processen med at få kode fra de mennesker, der skriver den til en implementeret tilstand.

Dette arbejde kan variere fra mange ansvarsområder til nogle få, hvad enten det er at skrive bash-scripts til en brugerdefineret løsning eller at skrive en CloudFormation-skabelon, der opretter alle de ressourcer, der er nødvendige for, at en app kan køre.

Du finder typisk dette inkluderet som en del af en større orkestrering af CI / CD-arbejdsgange, der automatiserer build- og implementeringsprocessen.

Og dette ændrer sig konstant! I betragtning af den serverløse boom dukkede den serverløse ramme op, som styrer meget af dette på en lettere måde, hvilket endda fører til, at AWS opretter deres egen løsning SAM. Værktøjer som Jenkins har eksisteret lidt for CI / CD-delen af ​​tingene, men nu ser du Github, Gitlab og andre kildekontroludbydere levere deres egne løsninger og værktøjer som CircleCI, der hænger lige ind i dit projekt.

Det er heller ikke perfekt endnu - at skrive CloudFormation-skabeloner er skræmmende. At skrive automatiseringsskripter er heller ikke det sjoveste, selvom det er super givende, når det fungerer!

Men dette bliver bedre, det er her produkter som Netlify og Zeit passer ind. Mens de rodfæstes mere fra den statiske hosting-side af tingene, hvor du kompilerer din app og dumper den til opbevaring, vokser deres tilbud som Netlify's Funktioner, der er egentlig bare AWS Lambdas, der er lettere at konfigurere og implementere til et fuldt fungerende slutpunkt (det er seriøst super nemt).

Så hvad skal jeg lære?

Hvis det er første gang du indstiller denne slags ting, skal du starte med Netlify. Opret en React-app eller endda bare en simpel HTML-fil i et Github-arkiv, tilslut den til en ny Netlify-konto, og se den implementeres.

Derfra, eller hvis du allerede har en lille erfaring, skal du begynde at blive nysgerrig efter, hvad der foregår bag kulisserne. Netlify tager sandsynligvis din kode, kører de kommandoer, du opretter (som yarn build) i et virtuelt miljø, dumper de filer, der er indbygget i lager som S3, og lægger en CDN foran den som CloudFront til at tjene fra et slutpunkt.

Forsøg først at gøre det manuelt fra din computer ved hjælp af AWS-konsollen og deres CLI, og skriv derefter et script for at automatisere hele processen, der integreres med Circle CI i dit Github-projekt i stedet for Netlify for at få det faktisk implementeret i AWS.

At tage det op et hak vil omfatte spinding af tjenester, som din bagende muligvis har interface med. Har du en database, som dine tjenester bruger? Du kan automatisere spinding af denne database ved hjælp af CloudFormation eller bash-scripts.

Behandling af din infrastruktur som kode med disponible, let genoprettelige ressourcer hjælper dig og dine projekter med at blive mere fleksible og have en bedre evne til at dreje op igen i tilfælde af fiasko.

Og alt dette gælder for enhver cloud- eller CI / CD-udbyder, ikke kun AWS og Circle CI. Vælg dit foretrukne sky- og arbejdsflowværktøj, og kør med det. Pointen er, begynde at se på dit projekts behov og grave i, hvad der faktisk sker i de automatiske dele af stakken. Dette hjælper dig med at lære mere og blive mere ressourcefuld til dit projekts behov.

Ressourcer

  • “En trinvis vejledning: Implementering på Netlify” //www.netlify.com/blog/2016/09/29/a-step-by-step-guide-deploying-on-netlify/
  • “Oprettelse af et statisk websted” //docs.aws.amazon.com/AmazonS3/latest/dev/HostingWebsiteOnS3Setup.html
  • “AWS Certified Cloud Practitioner Training 2019 - Et gratis 4-timers videokursus” //www.freecodecamp.org/news/aws-certified-cloud-practitioner-training-2019-free-video-course/
  • Se Javascript-ressourcer i Front End ovenfor

Hvad med design?

Ja, du skal forstå det grundlæggende i design. Nej, du behøver ikke være designer.

Der er mange aspekter ved design, der vil fremskynde dine evner som udvikler. Mens vi alle ved, at de visuelle og UX-designere producerer magi, kan det at have en grundlæggende forståelse forhindre din applikation i at blive en enorm skuffelse.

Alle i udviklingsprocessen arbejder hen imod et mål, der påvirker en slutbruger på en eller anden måde. At kunne forstå, hvilke behov dit arbejde prøver at løse, og hvordan det påvirker brugerne, vil hjælpe teamet som helhed med at udvikle en mere omfattende slutløsning.

Overvej en backend-udvikler, der opretter en API for at tillade nogen at administrere brugere i en app. Kravene i API'en er ret magre og inkluderer kun brugerens navn. At give det som et enkelt "navn" -felt i stedet for "første" og "sidste" måske ikke er den mest intuitive løsning for de fleste. Men det kan være et tilsyn, der komplicerer, hvordan frontend-udvikleren udsætter det i brugergrænsefladen, hvilket ville gøre det smertefuldt for udvikleren at vise eller kunne gøre det forvirrende for slutbrugeren at forbruge.

Oven i det hele kan design direkte påvirke konvertering. Hvis du bygger i e-handelsområdet, kan det have en knap, der ikke ligner en knap, at forhindre folk i at tilføje et produkt til deres indkøbskurv. Dette vil naturligvis forhindre et køb, som er tabt indtægter. At forstå, hvordan man humaniserer brugergrænsefladen, selv i en grundlæggende forstand, kan bogstaveligt talt gøre dit projekt flere penge eller simpelthen hjælpe nogen med at bruge det lettere.

Og vigtigere er, at du vil have dit websted tilgængeligt. Mange mennesker har forskellige behov, uanset om de ikke kan se farverne ens eller ikke kan høre de lyde, din app producerer, vil du genkende andres behov og forsøge at designe på en måde, der gør din app anvendelig af alle.

Så hvad skal jeg lære?

Selvom jeg ikke forventer, at du tager et helt kursus for det, så prøv at være opmærksom og nysgerrig. Og måske spring ikke næste gang over den designartikel, du så, næste gang dukker op på freeCodeCamp twitter.

Når du opretter løsninger, skal du prøve at forestille dig, hvordan dit arbejde vil blive brugt. Hvad har de andre udviklere på dit team brug for fra din API? Hvad har de mennesker, der bruger din app, brug for fra din grænseflade?

Du kan også prøve at få inspiration fra, hvad andre laver i dit rum. Hvordan forventer du, at en app ser ud, når den leverer lignende funktionalitet? Dette er ikke licens til at kopiere eller stjæle, men du skal forstå de behov, deres løsning løser. Overvej hvorfor deres knap i indkøbskurv er så enorm, hvorfor de giver brugerne mulighed for at zoome ind på et produktfoto, eller hvordan du kan gøre et borddesign lidt mere anvendeligt.

Hvad angår tilgængelighed, så prøv at lære det grundlæggende. Der er en stigende mængde ressourcer til rådighed for at hjælpe dig med at forstå andres behov. Prøv at forstå, hvilke handicap der er, og hvordan de kan påvirke brugen af ​​din app. Måske se på et par almindelige mønstre om, hvordan man tackler disse bekymringer.

Oftere end ikke er det ikke for svært at inkorporere, og hvis du har en vane med at gøre det fra starten, vil du ikke engang tænke over det næste gang du bygger en app.

Ressourcer

  • Design til udviklere //thoughtbot.com/upcase/design-for-developers
  • Hack Design //hackdesign.org
  • Design til hackere //designforhackers.com/
  • Introduktion til webtilgængelighed //webaim.org/intro/

Andre ting, hvis du lige er kommet i gang

Meget af denne artikel antager, at du har nogle af de grundlæggende nede, såsom at forstå, hvad git og kildekontrol er, eller bare have din kodeditor oprettet. Hvis du virkelig lige er kommet i gang, vil du i det mindste have en simpel forståelse af disse begreber, da det hurtigt bliver mere udfordrende uden dem.

Der er også noget at sige om at lære at bruge din terminal. Det kan være overvældende at ikke bruge en GUI, hvis du er ny, men når du først bevæger dig, finder du hurtigt ud af, at du bliver mere produktiv ved at bruge en terminal, og mange projekter kræver alligevel terminalbrug.

Så hvad skal jeg lære?

Første ting først, skal du konfigurere din kodeditor. Visual Studio Code er helt raseri lige nu, men der er andre, der vil tjene dig godt afhængigt af dine præferencer som Atom eller Sublime Text. Du finder endda skybaserede IDE'er som Repl.it, eller du kan bare komme i gang med en lavere adgangsbarriere ved at lege rundt i CodePen eller JSFiddle.

Uanset hvad, når du er klar til at få kodning, vil du forstå, hvad kildekontrol er, hvor git er den største spiller lige nu. Git er et kraftfuldt værktøj, der giver dig mulighed for at spore ændringer til kode og blive mere produktive i samarbejde med andre udviklere.

Du vil gerne blive fortrolig med nogle af de grundlæggende kommandoer for git som at tilføje nye ændringer samt hvad filialer er, og hvordan man bruger dem. Git er en enorm verden, du behøver ikke at mestre den med det samme, du lærer hurtigt, at der er en uendelig mængde nye ting at lære på din rejse til at mestre din git fu.

For mange værktøjer, du bruger, er der GUI'er som GitKraken, men du vil stadig være lidt begrænset med hvad du kan gøre. At lære dig rundt i standardterminalerne på din maskine eller downloade andre muligheder som iterm2 (min præference) eller Xterm.js vil være din bedste chance. Bonus: du vil føle dig som en filmhacker hver gang du bruger den (eller er det bare mig?).

Ressourcer

  • Kom godt i gang med Visual Studio-kode //www.codecademy.com/articles/visual-studio-code
  • Git ressourcer fra Github //try.github.io/
  • Lær git ved at forgrene spillet //learngitbranching.js.org/
  • Introduktion til Mac-kommandolinjen //blog.teamtreehouse.com/introduction-to-the-mac-os-x-command-line

Andre ting, hvis du leder efter mere

Der er så meget mere, du hurtigt kan gå ned i et kaninhul med. Husk ikke at sprede dit fokus og prøv ikke at overvælde dig selv. Men hvis du har det godt, hvor du er, er der nogle andre koncepter, der kun hjælper, når du tackler udfordringer i den virkelige verden.

Test og de forskellige metoder

Skrivning af kode er en ting, men at være i stand til at oprette effektive tests vil hjælpe med at hærde din kode og forhindre fejl i at komme ud. Du ønsker ikke at spilde din fremtidige tid eller endda koste dit produkt penge, når webstedet går ned. At lære at skrive test og de forskellige tilgange er vigtigt for at størkne din kode.

Browserværktøjer som Chrome DevTools

Et af de mest kraftfulde værktøjer, du kan have, når du debugger, efter min mening er at kunne debugge din applikation i browseren.

Uanset om det ser på, hvordan DOM gengives, leger med CSS eller fejler dine netværksanmodninger, lærer du hurtigt, hvordan du sparer tid og lettere kan identificere, hvor fejlen kommer fra.

HTTP og hvordan man debugger anmodninger i netværkspanelet

Da internettet er baseret på internettet, vil din ansøgning i sidste ende stille anmodninger til andre servere. Når dette sker, kan forståelse af chokepoints for anmodning eller simpelthen hvordan en anmodning fremsættes hjælpe dig med at forstå, hvorfor din applikation ser ud til at være svag, eller hvorfor din gem-knap ikke fungerer.

At have en grundlæggende forståelse af, hvordan anmodninger fungerer, og hvordan man visualiserer dem til fejlfinding, vil gå langt i din rejse.

Open Source Software og pakkeforvaltere

Denne er ikke så meget af en færdighed eller et værktøj til at lære så meget som det er en måde, hvorpå software distribueres. Når du begynder at opbygge kodeløsninger, finder du ud af, at mange af os læner sig på open source-pakker. Det meste af tiden er det gennem npm, hvis du skriver Javascript, hvilket hjælper os med at blive mere produktive uden at skulle genopfinde hjulet hver gang.

Brug lidt tid på at forstå open source-konceptet, og overvej endda at give tilbage ved at bidrage til dit yndlingsprojekt. Udlån af en hånd er normalt super værdsat, hjælper dig med at få erfaring, og du kan endda være i stand til at score noget gratis swag på din første godkendte pull-anmodning! Bare vær respektfuld derude, der er også en rigtig person på den anden side af anmodningen.

Hvad ellers?

Denne liste kan fortsætte for evigt, da der er så meget i kodningsverdenen. Hvad synes du ellers er vigtigt i ens rejse for at blive udviklingsmester? Send mig en tweet eller DM, hvis du tror, ​​jeg mangler noget vigtigt!

Du er i brand! Trækker det hele sammen

I betragtning af al den erfaring, du har akkumuleret med ovenstående, skal du være i stand til at kunne oprette en hel app fra start til slut selv. Forstår du den magt, du har?

Det er her, det sjove starter. Prøv at oprette en ny app - betyder ikke noget, hvad det er, bare bygg noget. Det bedste, du kan gøre for at lære, er at få erfaring ved at gøre. Det betyder ikke noget, om det er en af ​​de millioner todo-tutorials, du finder, eller ved at lære dig selv at kode ved at opbygge et af de største sociale netværk som skaberen af ​​Instagram.

Herfra skal du være i stand til at oprette:

  • En webapp-frontend, der kører i browseren
  • Backend-tjenester, som din webapp kan anmode om via slutpunkter
  • Skriv et script, der skal tilsluttes et CI / CD-værktøj til at automatisere din build- og implementeringsproces
  • Bonus: at tage gode beslutninger om, hvordan din grænseflade ser ud, så folk faktisk kan bruge den!

Gå ud og bygg! Del med os din udviklingsrejse på Twitter ved hjælp af hashtag #codejourney. Vi vil meget gerne høre mere om, hvor du har været, og hvad du har bygget, eller hvor du skal hen, og hvad du vil bygge.

Følg mig for mere Javascript, UX og andre interessante ting!

  • ? Følg mig på Twitter
  • ? ️ Abonner på min Youtube
  • ✉️ Tilmeld dig mit nyhedsbrev