De oare deis ynterviewde ik in JavaScript-ûntwikkelder dy't oanfrege foar in senior posysje. In kollega, dy't ek oanwêzich wie by it fraachpetear, frege de kandidaat om in funksje te skriuwen dy't in HTTP-fersyk meitsje soe en, as it net slagget, ferskate kearen opnij besykje.
Hy skreau de koade direkt op it boerd, dus it soe genôch wêze om wat sawat te tekenjen. As er samar sjen litten hie dat er goed begriep wat der oan de hân wie, dan hiene wy aardich tefreden west. Mar, spitigernôch, koe hy gjin suksesfolle oplossing fine. Doe besleaten wy, dy't it oant opwining krigen, de taak wat makliker te meitsjen en fregen him om in funksje mei callbacks te feroarjen yn in funksje boud op beloften.
Mar ach. Ja, it wie dúdlik dat er sa'n koade earder tsjinkaam. Hy wist yn algemiene termen hoe't alles dêr wurke. Alles wat wy nedich binne is in skets fan in oplossing dy't in begryp fan it konsept toant. De koade dy't de kandidaat op it boerd skreau wie lykwols folsleine ûnsin. Hy hie in heul vague idee fan hokker beloften yn JavaScript wiene en koe net echt útlizze wêrom't se nedich wiene. Foar in junior hie dat ferjaan west, mar hy wie net mear geskikt foar de funksje fan senior. Hoe soe dizze ûntwikkelder bugs kinne reparearje yn in komplekse keatling fan beloften en oan oaren útlizze wat hy krekt die?
Ûntwikkelers beskôgje klearmakke koade sels-evident
Tidens it ûntwikkelingsproses komme wy konstant reprodusearjende materialen tsjin. Wy drage koadefragminten oer, sadat wy se net elke kear opnij hoege te skriuwen. Dêrtroch, troch al ús oandacht te rjochtsjen op 'e wichtige dielen, sjogge wy nei de ôfmakke koade wêrmei wy wurkje as iets fansels - wy geane gewoan oan dat alles sil wurkje sa't it moat.
En meastentiids wurket it, mar as dingen lestich wurde, wurdt it begripen fan 'e meganika mear dan betelle.
Sa, ús kandidaat foar de posysje fan senior ûntwikkelder beskôge belofte objekten te wêzen fansels. Hy hie wierskynlik in idee fan hoe't se mei har omgean moatte as se earne yn 'e koade fan in oar foarkomme, mar hy begriep it algemiene prinsipe net en koe it sels net werhelje tidens it ynterview. Miskien tocht er it fragmint út it hert - it is net sa dreech:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Ik die it ek - en wy hawwe it wierskynlik allegear op in stuit dien. Se hawwe gewoan in stik koade memorisearre, sadat se it letter yn har wurk kinne brûke, wylst se allinich in algemien idee hawwe fan hoe't alles dêr wurke. Mar as de ûntwikkelder it konsept wirklik begrepen, soe hy neat hoege te ûnthâlden - hy soe gewoan witte hoe't it moat dwaan, en soe maklik alles reprodusearje wat er nedich wie yn koade.
Gean werom nei de woartels
Yn 2012, doe't de dominânsje fan front-end frameworks noch net fêststeld wie, regearre jQuery de wrâld, en ik lies it boek , skreaun troch John Resig, skepper fan jQuery.
It boek leart de lêzer hoe't se har eigen jQuery fanôf it begjin meitsje en jout in unyk ynsjoch yn it gedachteproses dat late ta de skepping fan 'e bibleteek. Yn 'e ôfrûne jierren hat jQuery syn eardere populariteit ferlern, mar ik advisearje it boek noch sterk. Wat my it meast opfoel oan har, wie it oanhâldende gefoel dat ik dit alles sels betinke koe. De stappen dy't de skriuwer beskreau liken sa logysk, sa dúdlik dat ik serieus begon te tinken dat ik maklik jQuery koe meitsje as ik der gewoan oan kaam.
Fansels soe ik yn werklikheid net sa'n ding dwaan kinnen hawwe - ik soe besletten hawwe dat it ûnferdraachlik lestich wie. Myn eigen oplossings soe lykje te simpel en naïve te wurkjen, en ik soe jaan op. Ik soe klassifisearjen jQuery as fanselssprekkend dingen, yn 'e goede wurking wêrfan jo gewoan moatte blyn leauwe. Ferfolgens soe ik amper tiid fergrieme mei it ferdjipjen yn 'e meganika fan dizze bibleteek, mar soe it gewoan brûke as in soarte fan swarte doaze.
Mar it lêzen fan dit boek makke my in oare persoan. Ik begon de boarnekoade te lêzen en ûntduts dat de ymplemintaasje fan in protte oplossingen yn feite heul transparant wie, sels fanselssprekkend. Nee, fansels, om soks sels te betinken is in oar ferhaal. Mar it is it bestudearjen fan de koade fan oaren en it reprodusearjen fan besteande oplossingen dy't ús helpt mei wat fan ús eigen te kommen.
De ynspiraasje dy't jo krije en de patroanen dy't jo begjinne te merken sille jo feroarje as ûntwikkelder. Jo sille fine dat dy prachtige bibleteek dy't jo hyltyd brûke en wêr't jo wend binne om te tinken as in magysk artefakt, hielendal net wurket op magy, mar in probleem gewoan lakonysk en ynsjoch oplost.
Soms sille jo de koade moatte poarje, it stap foar stap analysearje, mar dit is hoe't jo, yn lytse, konsekwinte stappen, it paad fan 'e auteur nei de oplossing kinne werhelje. Hjirmei kinne jo djipper yn it kodearringproses dûke en jo mear fertrouwen jaan om mei jo eigen oplossingen te kommen.
Doe't ik earst mei beloften begon te wurkjen, like it my suvere magy. Doe fûn ik út dat se wiene basearre op deselde callbacks, en myn programmearring wrâld draaide op 'e kop. Dat it patroan, wêrfan it doel is om ús te rêden fan callbacks, wurdt sels ymplementearre mei callbacks?!
Dit holp my mei oare eagen nei de saak te sjen en te realisearjen dat dit net ien of oare abstrus stik koade foar my is, de ferbeane kompleksiteit wêrfan ik yn myn libben noait sil begripe. Dit binne gewoan patroanen dy't kinne wurde begrepen sûnder problemen mei due nijsgjirrigens en djippe ûnderdompeling. Dit is hoe't minsken leare te koade en te groeien as ûntwikkelders.
Útfine dit tsjil opnij
Dus gean foarút en útfine de tsjillen op 'e nij: skriuw jo eigen data-binende koade, meitsje in eigen groeide belofte, of meitsje sels jo eigen steatbehearoplossing.
It makket net út dat gjinien dit alles ea sil brûke - mar no wite jo hoe't jo it moatte dwaan. En as jo de kâns hawwe om soksoarte ûntjouwings neitiid te brûken yn jo eigen projekten, dan is dat oer it algemien geweldich. Jo sille se kinne ûntwikkelje en wat oars leare.
It punt hjir is net om jo koade nei produksje te stjoeren, mar om wat nijs te learen. It skriuwen fan jo eigen ymplemintaasje fan in besteande oplossing is in geweldige manier om te learen fan 'e bêste programmeurs en sa jo feardigens te ferbetterjen.
Boarne: www.habr.com