Her om dagen intervjuet jeg en JavaScript-utvikler som søkte på en ledende stilling. En kollega, som også var til stede under intervjuet, ba kandidaten om å skrive en funksjon som ville lage en HTTP-forespørsel og, hvis det ikke lykkes, prøve på nytt flere ganger.
Han skrev koden direkte på tavlen, så det ville være nok å tegne noe omtrentlig. Hvis han rett og slett hadde vist at han skjønte godt hva saken var, hadde vi vært ganske fornøyde. Men dessverre klarte han ikke å finne en vellykket løsning. Så bestemte vi oss for å gjøre oppgaven litt enklere og ba ham gjøre om en funksjon med tilbakeringing til en funksjon bygget på løfter.
Men akk. Ja, det var tydelig at han hadde støtt på slik kode før. Han visste generelt hvordan alt fungerte der. Alt vi trenger er en skisse av en løsning som demonstrerer forståelse av konseptet. Koden som kandidaten skrev på tavlen var imidlertid fullstendig tull. Han hadde en veldig vag idé om hvilke løfter som var i JavaScript og kunne egentlig ikke forklare hvorfor de var nødvendige. For en junior ville dette vært tilgivelig, men han var ikke lenger egnet til seniorstillingen. Hvordan ville denne utvikleren være i stand til å fikse feil i en kompleks kjede av løfter og forklare andre hva han gjorde?
Utviklere anser ferdig kode som selvinnlysende
Under utviklingsprosessen møter vi stadig reproduserbare materialer. Vi overfører kodefragmenter slik at vi ikke trenger å skrive dem på nytt hver gang. Følgelig, ved å fokusere all vår oppmerksomhet på nøkkeldelene, ser vi på den ferdige koden vi jobber med som noe selvinnlysende - vi antar ganske enkelt at alt vil fungere som det skal.
Og vanligvis fungerer det, men når ting blir vanskelig, lønner det seg mer enn å forstå mekanikken.
Derfor anså vår kandidat til stillingen som seniorutvikler løfteobjekter som selvinnlysende. Han hadde sannsynligvis en ide om hvordan han skulle håndtere dem når de forekommer et sted i andres kode, men han forsto ikke det generelle prinsippet og kunne ikke gjenta det selv under intervjuet. Kanskje han husket fragmentet utenat - det er ikke så vanskelig:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Jeg gjorde det også – og vi har nok alle gjort det på et tidspunkt. De husket ganske enkelt et stykke kode slik at de senere kunne bruke det i arbeidet sitt, mens de bare hadde en generell ide om hvordan alt fungerte der. Men hvis utvikleren virkelig forsto konseptet, ville han ikke trenge å huske noe - han ville rett og slett vite hvordan han skulle gjøre det, og ville enkelt reprodusere alt han trengte i kode.
Gå tilbake til røttene
I 2012, da dominansen til frontend-rammeverk ennå ikke var etablert, styrte jQuery verden, og jeg leste boken , skrevet av John Resig, skaperen av jQuery.
Boken lærer leseren hvordan de kan lage sin egen jQuery fra bunnen av og gir et unikt innblikk i tankeprosessen som førte til bibliotekets opprettelse. De siste årene har jQuery mistet sin tidligere popularitet, men jeg anbefaler fortsatt boken på det varmeste. Det som slo meg mest med henne var den vedvarende følelsen av at jeg kunne ha tenkt på alt dette selv. Trinnene som forfatteren beskrev virket så logiske, så klare at jeg seriøst begynte å tenke at jeg enkelt kunne lage jQuery hvis jeg bare kom til det.
Selvfølgelig ville jeg i realiteten ikke ha klart å gjøre noe slikt – jeg ville ha bestemt meg for at det var uutholdelig vanskelig. Mine egne løsninger ville virke for enkle og naive til å fungere, og jeg ville gi opp. Jeg vil klassifisere jQuery som selvinnlysende ting, i den korrekte driften som du bare trenger å tro blindt på. Deretter ville jeg neppe kastet bort tid på å fordype meg i mekanikken til dette biblioteket, men ville ganske enkelt bruke det som en slags svart boks.
Men å lese denne boken gjorde meg til en annen person. Jeg begynte å lese kildekoden og oppdaget at implementeringen av mange løsninger faktisk var veldig transparent, til og med åpenbar. Nei, selvfølgelig, å tenke på noe slikt på egenhånd er en annen historie. Men det er å studere andres kode og reprodusere eksisterende løsninger som hjelper oss å komme opp med noe eget.
Inspirasjonen du får og mønstrene du begynner å legge merke til vil endre deg som utvikler. Du vil oppdage at det fantastiske biblioteket som du stadig bruker og som du er vant til å tenke på som en magisk artefakt ikke fungerer på magi i det hele tatt, men rett og slett løser et problem lakonisk og ressurssterkt.
Noen ganger må du granske koden, analysere den trinnvis, men slik kan du, i små, konsekvente trinn, gjenta forfatterens vei til løsningen. Dette vil tillate deg å dykke dypere inn i kodingsprosessen og gi deg mer selvtillit når du kommer opp med dine egne løsninger.
Da jeg først begynte å jobbe med løfter, virket det for meg som ren magi. Så fant jeg ut at de var basert på de samme tilbakeringingene, og programmeringsverdenen min ble snudd på hodet. Så mønsteret, hvis formål er å redde oss fra tilbakeringinger, implementeres i seg selv ved hjelp av tilbakeringinger?!
Dette hjalp meg til å se på saken med andre øyne og innse at dette ikke er en grov kode foran meg, den uoverkommelige kompleksiteten jeg aldri kommer til å forstå i mitt liv. Dette er bare mønstre som kan forstås uten problemer med tilbørlig nysgjerrighet og dyp fordypning. Dette er hvordan folk lærer å kode og vokse som utviklere.
Oppfinn dette hjulet på nytt
Så fortsett og oppfinn hjulene på nytt: skriv din egen databindende kode, lag et hjemmelaget løfte, eller lag din egen løsning for statlig administrasjon.
Det spiller ingen rolle at ingen noen gang vil bruke alt dette - men nå vet du hvordan du gjør det. Og hvis du i etterkant har mulighet til å bruke slike utviklinger i dine egne prosjekter, så er det generelt bra. Du vil kunne utvikle dem og lære noe annet.
Poenget her er ikke å sende koden din til produksjon, men å lære noe nytt. Å skrive din egen implementering av en eksisterende løsning er en fin måte å lære av de beste programmererne og dermed finpusse ferdighetene dine.
Kilde: www.habr.com