Forleden interviewede jeg en JavaScript-udvikler, som søgte en ledende stilling. En kollega, som også var til stede ved interviewet, bad kandidaten om at skrive en funktion, der ville lave en HTTP-anmodning og, hvis det ikke lykkes, prøve igen flere gange.
Han skrev koden direkte på tavlen, så det ville være nok at tegne noget omtrentligt. Hvis han blot havde vist, at han godt forstod, hvad sagen var, ville vi have været ganske tilfredse. Men han var desværre ikke i stand til at finde en vellykket løsning. Så besluttede vi, kridtet det til spænding, at gøre opgaven lidt nemmere og bad ham om at lave en funktion med tilbagekald til en funktion bygget på løfter.
Men ak. Ja, det var tydeligt, at han havde stødt på sådan en kode før. Han vidste generelt, hvordan alt fungerede der. Alt, hvad vi behøver, er en skitse af en løsning, der demonstrerer en forståelse af konceptet. Koden, som kandidaten skrev på tavlen, var dog fuldstændig nonsens. Han havde en meget vag idé om, hvilke løfter der var i JavaScript og kunne ikke rigtig forklare, hvorfor de var nødvendige. For en junior ville dette have været tilgiveligt, men han var ikke længere egnet til stillingen som senior. Hvordan ville denne udvikler være i stand til at rette fejl i en kompleks kæde af løfter og forklare andre, hvad han præcist gjorde?
Udviklere betragter færdiglavet kode som indlysende
Under udviklingsprocessen støder vi konstant på reproducerbare materialer. Vi overfører kodefragmenter, så vi ikke behøver at omskrive dem hver gang. Ved at fokusere al vores opmærksomhed på nøgledelene ser vi derfor på den færdige kode, vi arbejder med, som noget selvindlysende - vi antager simpelthen, at alt vil fungere, som det skal.
Og normalt virker det, men når tingene bliver vanskelige, betaler det sig mere end at forstå mekanikken.
Vores kandidat til stillingen som seniorudvikler anså således løfteobjekter for at være indlysende. Han havde sandsynligvis en idé om, hvordan han skulle håndtere dem, når de opstår et sted i en andens kode, men han forstod ikke det generelle princip og kunne ikke gentage det selv under interviewet. Måske huskede han fragmentet udenad - det er ikke så svært:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Det gjorde jeg også – og vi har nok alle sammen gjort det på et tidspunkt. De huskede simpelthen et stykke kode, så de senere kunne bruge det i deres arbejde, mens de kun havde en generel idé om, hvordan alt fungerede der. Men hvis udvikleren virkelig forstod konceptet, ville han ikke skulle huske noget - han ville simpelthen vide, hvordan man gør det, og ville nemt gengive alt, hvad han havde brug for i kode.
Gå tilbage til rødderne
I 2012, da dominansen af front-end frameworks endnu ikke var etableret, regerede jQuery verden, og jeg læste bogen , forfattet af John Resig, skaberen af jQuery.
Bogen lærer læseren at skabe deres eget jQuery fra bunden og giver et unikt indblik i den tankeproces, der førte til bibliotekets oprettelse. I de senere år har jQuery mistet sin tidligere popularitet, men jeg kan stadig varmt anbefale bogen. Det, der slog mig mest ved hende, var den vedvarende følelse af, at jeg selv kunne have tænkt på alt dette. De trin, som forfatteren beskrev, virkede så logiske, så klare, at jeg for alvor begyndte at tro, at jeg sagtens kunne lave jQuery, hvis jeg bare kom til det.
Selvfølgelig ville jeg i virkeligheden ikke have kunnet gøre sådan noget – jeg ville have besluttet, at det var ulidelig svært. Mine egne løsninger ville virke for enkle og naive til at fungere, og jeg ville give op. Jeg vil klassificere jQuery som selvindlysende ting, i den korrekte drift, som du blot skal tro blindt på. Efterfølgende ville jeg næppe spilde tid på at dykke ned i mekanikken i dette bibliotek, men ville blot bruge det som en slags sort boks.
Men at læse denne bog gjorde mig til en anden person. Jeg begyndte at læse kildekoden og opdagede, at implementeringen af mange løsninger faktisk var meget gennemsigtig, endda indlysende. Nej, selvfølgelig, at tænke på sådan noget på egen hånd er en anden historie. Men det er at studere andres kode og reproducere eksisterende løsninger, der hjælper os med at finde på noget helt eget.
Den inspiration, du får, og de mønstre, du begynder at lægge mærke til, vil ændre dig som udvikler. Du vil opdage, at det vidunderlige bibliotek, som du konstant bruger, og som du er vant til at tænke på som en magisk artefakt, slet ikke virker på magi, men blot løser et problem lakonisk og ressourcestærkt.
Nogle gange bliver du nødt til at gennemsøge koden og analysere den trin for trin, men sådan kan du, i små, konsekvente trin, gentage forfatterens vej til løsningen. Dette vil give dig mulighed for at dykke dybere ned i kodningsprocessen og give dig mere selvtillid til at komme med dine egne løsninger.
Da jeg først begyndte at arbejde med løfter, virkede det for mig som ren magi. Så fandt jeg ud af, at de var baseret på de samme tilbagekald, og min programmeringsverden vendte op og ned. Så mønsteret, hvis formål er at redde os fra tilbagekald, er i sig selv implementeret ved hjælp af tilbagekald?!
Dette hjalp mig til at se på sagen med andre øjne og indse, at dette ikke er et eller andet ufatteligt stykke kode foran mig, hvis uoverkommelige kompleksitet jeg aldrig vil forstå i mit liv. Det er blot mønstre, der kan forstås uden problemer med behørig nysgerrighed og dyb fordybelse. Det er sådan, folk lærer at kode og vokse som udviklere.
Genopfind dette hjul
Så fortsæt og genopfind hjulene: skriv din egen databindende kode, skab et hjemmelavet løfte, eller lav endda din egen statsadministrationsløsning.
Det gør ikke noget, at ingen nogensinde vil bruge alt dette - men nu ved du, hvordan du gør det. Og hvis du har mulighed for efterfølgende at bruge sådanne udviklinger i dine egne projekter, så er det generelt fantastisk. Du vil være i stand til at udvikle dem og lære noget andet.
Pointen her er ikke at sende din kode til produktion, men at lære noget nyt. At skrive din egen implementering af en eksisterende løsning er en fantastisk måde at lære af de bedste programmører og dermed finpudse dine færdigheder.
Kilde: www.habr.com