Forleden havde jeg et interview med en JavaScript-udvikler, der ansøgte om en seniorposition. En kollega, som også var til stede ved interviewet, bad kandidaten om at skrive en funktion, der kunne udføre et HTTP-anmodning og forsøge igen flere gange i tilfælde af fejl.
Han skrev koden direkte på tavlen, så det ville have været tilstrækkeligt at skitsere noget omtrentligt. Hvis han bare havde vist, at han havde en god forståelse for det grundlæggende, ville vi have været ganske tilfredse. Men desværre kunne han ikke finde en tilfredsstillende løsning. Derfor, i takt med at vi tilskrev det nervøsitet, besluttede vi at lette opgaven lidt og bad ham om at ændre funktionen med callback til en funktion baseret på promises.
Men desværre. Ja, det var tydeligt, at han tidligere havde set lignende kode. Han havde en overordnet forståelse af, hvordan det hele fungerede. Vi ville have været glade for et udkast til en løsning, der demonstrerede forståelsen af konceptet. Men koden, kandidater skrev på tavlen, var total nonsens. Han havde et meget uklart begreb om, hvad promises er i JavaScript og kunne ikke forklare, hvorfor de er nødvendige. For en junior ville det have været tilgivet, men til en seniorposition var det ikke tilstrækkeligt. Hvordan kunne denne udvikler finde og rette fejl i en kompleks kæde af promises og forklare de andre, hvad han havde gjort?
Udviklere anser færdig kode for at være indlysende.
Under udviklingen støder vi konstant på reproducerbare materialer. Vi overfører kodefragmenter, så vi ikke behøver at skrive dem igen hver gang. Derfor, når vi fokuserer al vores opmærksomhed på de centrale dele, ser vi på den færdige kode, vi arbejder med, som noget indlysende – vi antager bare, at det fungerer som det skal.
Og normalt virker det også, men når der opstår problemer, er forståelsen af dets mekanik mere end det værd.
Så vores kandidat til seniorudviklerpositionen anså objects promises for at være indlysende. Han forestillede sig nok, hvordan man håndterer dem, når de optræder i andres kode, men han forstod ikke det overordnede princip og kunne ikke reproducere det under interviewet. Måske huskede han et fragment udenad – det er ikke så svært:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Jeg gjorde også det – ja, vi har sikkert alle gjort det på et tidspunkt. Man lærte bare en sektion af koden for senere at bruge den i arbejdet, mens man kun havde en generel idé om, hvordan det hele fungerede. Men hvis udvikleren virkelig forstod konceptet, ville han ikke have behov for at huske noget - han ville bare vide, hvordan det gøres, og uden besvær genskabe alt det nødvendige i koden.
Gå til kilden
I 2012, da der stadig ikke var etableret dominans af frontend-rammer, herskede jQuery, og jeg læste bogen , skrevet af John Resig, skaberen af jQuery.
Bogen lærer læseren, hvordan man bygger sin egen jQuery fra bunden og giver en unik mulighed for at forstå tankegangen, som førte til oprettelsen af biblioteket. I de seneste år har jQuery tabt sin tidligere popularitet, men jeg anbefaler stadig bogen meget. Det, der imponerede mig mest ved den, var den vedholdende følelse af, at jeg sagtens kunne have kommet på det selv. Trinene, som forfatteren beskrev, virkede så logiske, så forståelige, at det virkelig begyndte at føles som om, jeg uden problemer kunne skabe jQuery, hvis jeg bare tog fat på det.
Selvfølgelig ville jeg i virkeligheden ikke have klaret det – jeg ville konkludere, at det var alt for vanskeligt. Mine egne løsninger ville have virket alt for enkle og naive til at fungere, og jeg ville have givet op. Jeg ville have betragtet jQuery som en selvfølge, i hvis korrekte funktion man bare burde have blind tillid. I fremtiden ville jeg næppe bruge tid på at dykke ned i mekanikken bag dette bibliotek og blot have brugt det som en form for sort boks.
Men mødet med denne bog gjorde mig til en anden person. Jeg begyndte at studere kildekoden og opdagede, at implementeringen af mange løsninger i virkeligheden er meget gennemsigtig, endda åbenlys. Nej, selvfølgelig ville det at finde på noget lignende selv være noget helt andet. Men netop studiet af andres kode og reproduktionen af allerede eksisterende løsninger hjælper os med at finde på noget eget.
Den inspiration, du vil hente, og de mønstre, du begynder at bemærke, vil ændre dig som udvikler. Du vil opdage, at det vidunderlige bibliotek, du konstant bruger, og som du er vant til at tænke på som en magisk artefakt, slet ikke fungerer på magi, men blot løser problemet på en elegant og kreativ måde.
Nogle gange må du kæmpe med koden, tage den trin for trin, men netop ved at tage små, sekventielle skridt kan du gentage forfatterens rejse mod løsningen. Det vil give dig en dybere forståelse af kodningsprocessen og give dig mere selvtillid i din egen søgen efter løsninger.
Da jeg først begyndte at arbejde med promises, syntes jeg, at det var ren magi. Så fandt jeg ud af, at de er baseret på de samme callbacks, og min programmeringsverden blev vendt op og ned. Altså mønsteret, hvis formål er at befri os fra callbacks, реализируется ved hjælp af callbacks?!
Det hjalp mig med at se sagen fra en anden vinkel og indse, at jeg ikke stod over for nogle komplekse kodestykker, som jeg aldrig ville kunne forstå. Det er blot mønstre, der kan forstås uden problemer, hvis man har den rette nysgerrighed og dybe indlevelse. Det er sådan, folk lærer at programmere og vokser som udviklere.
Opfind hjulet på ny
Så vær ikke bange for at genopfinde hjulene: skriv selv koden til datalinkning, lav din egen promise eller endda skab dine egne løsninger til tilstandsadministration.
Det er ligegyldigt, at ingen nogensinde vil bruge det, for nu kan du det. Og hvis du senere får mulighed for at anvende sådanne indsigter i dine egne projekter, så er det bare fantastisk. Du kan udvikle dem yderligere og lære endnu mere.
Pointen her er ikke at få din kode i produktion, men at lære noget nyt. At implementere eksisterende løsninger selv er en fantastisk måde at lære fra de bedste programmører og dermed forfine dine færdigheder.
Kilde: habr.com
