Ek het nou die dag 'n onderhoud gevoer met 'n JavaScript-ontwikkelaar wat vir 'n senior pos aansoek gedoen het. 'n Kollega, wat ook by die onderhoud teenwoordig was, het die kandidaat gevra om 'n funksie te skryf wat 'n HTTP-versoek sou maak en, indien onsuksesvol, verskeie kere weer probeer.
Hy het die kode direk op die bord geskryf, so dit sal genoeg wees om iets by benadering te teken. As hy bloot gewys het dat hy goed verstaan wat die saak is, sou ons heel tevrede gewees het. Maar ongelukkig kon hy nie 'n suksesvolle oplossing vind nie. Toe het ons dit tot opgewondenheid gekritiseer, besluit om die taak 'n bietjie makliker te maak en hom gevra om 'n funksie met terugbelopings te omskep in 'n funksie wat op beloftes gebou is.
Maar helaas. Ja, dit was duidelik dat hy al voorheen sulke kode teëgekom het. Hy het in algemene terme geweet hoe alles daar werk. Al wat ons nodig het is 'n skets van 'n oplossing wat 'n begrip van die konsep demonstreer. Die kode wat die kandidaat op die bord geskryf het, was egter volslae onsin. Hy het 'n baie vae idee gehad van watter beloftes in JavaScript was en kon nie regtig verduidelik hoekom dit nodig was nie. Vir 'n junior sou dit vergeeflik gewees het, maar hy was nie meer geskik vir die pos van 'n senior nie. Hoe sou hierdie ontwikkelaar foute in 'n komplekse reeks beloftes kon regmaak en aan ander verduidelik wat hy presies gedoen het?
Ontwikkelaars beskou klaargemaakte kode as vanselfsprekend
Tydens die ontwikkelingsproses kom ons voortdurend reproduceerbare materiale teë. Ons dra kodefragmente oor sodat ons dit nie elke keer hoef te herskryf nie. Gevolglik, deur al ons aandag op die sleuteldele te fokus, kyk ons na die voltooide kode waarmee ons werk as iets vanselfsprekend – ons aanvaar eenvoudig dat alles sal werk soos dit moet.
En gewoonlik werk dit wel, maar wanneer dinge moeilik raak, is dit beter om die meganika te verstaan.
Ons kandidaat vir die pos van senior ontwikkelaar het dus beloftevoorwerpe as vanselfsprekend beskou. Hy het waarskynlik 'n idee gehad van hoe om hulle te hanteer wanneer hulle iewers in iemand anders se kode voorkom, maar hy het nie die algemene beginsel verstaan nie en kon dit nie self tydens die onderhoud herhaal nie. Miskien het hy die fragment uit sy kop onthou - dit is nie so moeilik nie:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Ek het dit ook gedoen – en ons het dit seker al een of ander tyd al gedoen. Hulle het eenvoudig 'n stukkie kode gememoriseer sodat hulle dit later in hul werk kon gebruik, terwyl hulle net 'n algemene idee gehad het van hoe alles daar gewerk het. Maar as die ontwikkelaar die konsep werklik verstaan, sou hy niks hoef te onthou nie - hy sou eenvoudig weet hoe om dit te doen, en sou maklik alles wat hy nodig het in kode weergee.
Gaan terug na die wortels
In 2012, toe die oorheersing van front-end-raamwerke nog nie vasgestel was nie, het jQuery die wêreld regeer, en ek het die boek gelees , geskryf deur John Resig, skepper van jQuery.
Die boek leer die leser hoe om hul eie jQuery van nuuts af te skep en bied 'n unieke insig in die denkproses wat gelei het tot die biblioteek se skepping. In onlangse jare het jQuery sy vorige gewildheid verloor, maar ek beveel die boek steeds sterk aan. Wat my die meeste van haar opgeval het, was die aanhoudende gevoel dat ek self aan dit alles kon dink. Die stappe wat die skrywer beskryf het, het so logies gelyk, so duidelik dat ek ernstig begin dink het dat ek maklik jQuery kan skep as ek net daarby uitkom.
Natuurlik sou ek in werklikheid nie so iets kon doen nie – ek sou besluit het dat dit ondraaglik moeilik is. My eie oplossings lyk te eenvoudig en naïef om te werk, en ek sal tou opgooi. Ek sal jQuery as vanselfsprekende dinge klassifiseer, in die korrekte werking waarvan jy net blindelings moet glo. Vervolgens sou ek skaars tyd mors om in die meganika van hierdie biblioteek te delf, maar sou dit bloot as 'n soort swart boks gebruik.
Maar die lees van hierdie boek het my 'n ander mens gemaak. Ek het die bronkode begin lees en ontdek dat die implementering van baie oplossings in werklikheid baie deursigtig was, selfs voor die hand liggend. Nee, natuurlik, om op jou eie aan so iets te dink is 'n ander storie. Maar dit is om ander mense se kode te bestudeer en bestaande oplossings te reproduseer wat ons help om met iets van ons eie vorendag te kom.
Die inspirasie wat jy kry en die patrone wat jy begin raaksien, sal jou as ontwikkelaar verander. Jy sal vind dat daardie wonderlike biblioteek wat jy gedurig gebruik en waaraan jy gewoond is om as 'n magiese artefak te dink glad nie op toorkuns werk nie, maar bloot 'n probleem lakoniek en vindingryk oplos.
Soms sal jy oor die kode moet kyk en dit stap vir stap ontleed, maar dit is hoe jy, met klein, konsekwente stappe, die skrywer se pad na die oplossing kan herhaal. Dit sal jou toelaat om dieper in die koderingsproses te duik en jou meer selfvertroue te gee om met jou eie oplossings vorendag te kom.
Toe ek die eerste keer met beloftes begin werk het, het dit vir my na pure magie gelyk. Toe vind ek uit dat hulle op dieselfde terugbelopings gebaseer is, en my programmeringswêreld het onderstebo gekeer. So die patroon, waarvan die doel is om ons van terugbelopings te red, word self geïmplementeer deur terugbelopings?!
Dit het my gehelp om met ander oë na die saak te kyk en te besef dat dit nie die een of ander onduidelike stukkie kode voor my is nie, waarvan ek die buitensporige kompleksiteit nooit in my lewe sal begryp nie. Dit is net patrone wat sonder probleme met die nodige nuuskierigheid en diep onderdompeling verstaan kan word. Dit is hoe mense leer om te kodeer en as ontwikkelaars te groei.
Herontdek hierdie wiel
So gaan voort en herontdek die wiele: skryf jou eie data-bindende kode, skep 'n tuisgemaakte belofte, of maak selfs jou eie staatsbestuursoplossing.
Dit maak nie saak dat niemand dit alles ooit sal gebruik nie - maar nou weet jy hoe om dit te doen. En as jy die geleentheid het om sulke ontwikkelings later in jou eie projekte te gebruik, dan is dit oor die algemeen wonderlik. Jy sal hulle kan ontwikkel en iets anders leer.
Die punt hier is nie om jou kode na produksie te stuur nie, maar om iets nuuts te leer. Om jou eie implementering van 'n bestaande oplossing te skryf is 'n goeie manier om by die beste programmeerders te leer en sodoende jou vaardighede te slyp.
Bron: will.com