Onlangs interviewde ik een JavaScript-ontwikkelaar die solliciteerde naar een senior functie. Een collega, die ook bij het interview aanwezig was, vroeg de kandidaat een functie te schrijven die een HTTP-verzoek zou doen en, als dat niet lukt, het meerdere keren opnieuw zou proberen.
Hij schreef de code rechtstreeks op het bord, dus het zou voldoende zijn om iets bij benadering te tekenen. Als hij eenvoudigweg had laten zien dat hij goed begreep wat er aan de hand was, waren wij heel tevreden geweest. Maar helaas kon hij geen succesvolle oplossing vinden. Toen besloten we, uit opwinding, de taak een beetje eenvoudiger te maken en vroegen hem om van een functie met callbacks een functie te maken die op beloften was gebaseerd.
Maar helaas. Ja, het was duidelijk dat hij dergelijke code eerder was tegengekomen. Hij wist in grote lijnen hoe alles daar werkte. Het enige dat we nodig hebben is een schets van een oplossing waaruit blijkt dat we het concept begrijpen. De code die de kandidaat op het bord schreef was echter complete onzin. Hij had een heel vaag idee van wat beloftes in JavaScript waren en kon niet echt uitleggen waarom ze nodig waren. Voor een junior zou dit vergeven zijn, maar hij was niet langer geschikt voor de functie van senior. Hoe zou deze ontwikkelaar bugs in een complexe keten van beloften kunnen oplossen en aan anderen kunnen uitleggen wat hij precies deed?
Ontwikkelaars beschouwen kant-en-klare code als vanzelfsprekend
Tijdens het ontwikkelingsproces komen we voortdurend reproduceerbare materialen tegen. We dragen codefragmenten over, zodat we ze niet elke keer opnieuw hoeven te schrijven. Door al onze aandacht op de belangrijkste onderdelen te richten, beschouwen we de voltooide code waarmee we werken als iets vanzelfsprekends: we gaan er eenvoudigweg van uit dat alles zal werken zoals het zou moeten werken.
En meestal werkt het wel, maar als het lastig wordt, loont het meer dan de moeite om de mechanismen te begrijpen.
Onze kandidaat voor de functie van senior developer beschouwde belofteobjecten dan ook als vanzelfsprekend. Hij had waarschijnlijk wel een idee hoe hij ermee om moest gaan als ze ergens in de code van iemand anders voorkomen, maar hij begreep het algemene principe niet en kon het zelf niet herhalen tijdens het interview. Misschien herinnerde hij zich het fragment uit zijn hoofd - zo moeilijk is het niet:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Ik heb het ook gedaan, en we hebben het waarschijnlijk allemaal wel eens gedaan. Ze leerden eenvoudigweg een stukje code uit hun hoofd, zodat ze het later in hun werk konden gebruiken, terwijl ze slechts een algemeen idee hadden van hoe alles daar werkte. Maar als de ontwikkelaar het concept echt zou begrijpen, zou hij niets hoeven te onthouden; hij zou gewoon weten hoe hij het moest doen en alles wat hij nodig had gemakkelijk in code kunnen reproduceren.
Ga terug naar de wortels
In 2012, toen de dominantie van front-end frameworks nog niet was vastgesteld, regeerde jQuery de wereld, en ik las het boek , geschreven door John Resig, maker van jQuery.
Het boek leert de lezer hoe hij zijn eigen jQuery helemaal opnieuw kan maken en biedt een uniek inzicht in het denkproces dat heeft geleid tot de oprichting van de bibliotheek. De afgelopen jaren heeft jQuery zijn vroegere populariteit verloren, maar ik kan het boek nog steeds ten zeerste aanbevelen. Wat mij het meest bij haar opviel, was het aanhoudende gevoel dat ik dit allemaal zelf had kunnen bedenken. De stappen die de auteur beschreef leken zo logisch, zo duidelijk dat ik serieus begon te denken dat ik gemakkelijk jQuery zou kunnen maken als ik er maar mee aan de slag ging.
In werkelijkheid zou ik zoiets natuurlijk niet hebben kunnen doen - ik zou hebben besloten dat het ondraaglijk moeilijk was. Mijn eigen oplossingen zouden te simpel en naïef lijken om te werken, en ik zou het opgeven. Ik zou jQuery classificeren als vanzelfsprekende dingen, waarvan je de juiste werking gewoon blindelings moet geloven. Vervolgens zou ik nauwelijks tijd verspillen aan het verdiepen in de werking van deze bibliotheek, maar deze gewoon als een soort zwarte doos gebruiken.
Maar door dit boek te lezen ben ik een ander mens geworden. Ik begon de broncode te lezen en ontdekte dat de implementatie van veel oplossingen juist heel transparant was, zelfs voor de hand liggend. Nee, zoiets zelf bedenken is natuurlijk een ander verhaal. Maar het bestuderen van de code van anderen en het reproduceren van bestaande oplossingen helpt ons om met iets eigens te komen.
De inspiratie die je opdoet en de patronen die je begint op te merken, zullen je als ontwikkelaar veranderen. Je zult merken dat die prachtige bibliotheek die je voortdurend gebruikt en die je gewend bent te beschouwen als een magisch artefact helemaal niet op magie werkt, maar eenvoudigweg een probleem laconiek en vindingrijk oplost.
Soms zul je de code moeten doornemen en deze stap voor stap moeten analyseren, maar op deze manier kun je, in kleine, consistente stappen, het pad van de auteur naar de oplossing herhalen. Hierdoor kunt u dieper in het codeerproces duiken en krijgt u meer vertrouwen bij het bedenken van uw eigen oplossingen.
Toen ik voor het eerst met beloften begon te werken, leek het mij pure magie. Toen ontdekte ik dat ze op dezelfde callbacks waren gebaseerd, en mijn programmeerwereld stond op zijn kop. Dus het patroon, waarvan het doel is om ons te behoeden voor callbacks, wordt zelf geïmplementeerd met behulp van callbacks?!
Dit hielp me om met andere ogen naar de zaak te kijken en te beseffen dat dit niet een duister stukje code voor me is, waarvan ik de onbetaalbare complexiteit nooit in mijn leven zal begrijpen. Dit zijn slechts patronen die zonder problemen kunnen worden begrepen met de nodige nieuwsgierigheid en diepe onderdompeling. Dit is hoe mensen leren coderen en groeien als ontwikkelaars.
Vind dit wiel opnieuw uit
Dus ga je gang en vind de wielen opnieuw uit: schrijf je eigen databindende code, creëer een belofte van eigen bodem, of maak zelfs je eigen oplossing voor staatsbeheer.
Het maakt niet uit dat niemand dit allemaal ooit zal gebruiken, maar nu weet je hoe je het moet doen. En als je de mogelijkheid hebt om dergelijke ontwikkelingen vervolgens in je eigen projecten te gebruiken, dan is dat doorgaans prima. Je zult ze kunnen ontwikkelen en iets anders kunnen leren.
Het punt hier is niet om je code naar productie te sturen, maar om iets nieuws te leren. Het schrijven van uw eigen implementatie van een bestaande oplossing is een geweldige manier om van de beste programmeurs te leren en zo uw vaardigheden aan te scherpen.
Bron: www.habr.com