Herenegun, goi kargua eskatzen ari zen JavaScript garatzaile bat elkarrizketatu nuen. Lankide batek, bera ere elkarrizketan egon zen, hautagaiari HTTP eskaera bat egingo zuen funtzio bat idazteko eskatu zion eta, arrakastarik ezean, hainbat aldiz berriro saiatzeko.
Zuzenean kodea idatzi zuen arbelean, beraz, nahikoa izango litzateke gutxi gorabeherako zerbait marraztea. Gaia zer den ondo ulertzen zuela erakutsi izan balu, nahiko konforme geratuko ginateke. Baina, zoritxarrez, ezin izan zuen irtenbide arrakastatsurik aurkitu. Orduan, ilusioari esker, zeregina apur bat erraztea erabaki genuen eta deiak dituen funtzio bat promesetan eraikitako funtzio bat bihurtzeko eskatu zion.
Baina ai. Bai, bistakoa zen lehenago topatu zuela halako kode. Orokorrean bazekien dena nola funtzionatzen zuen bertan. Kontzeptuaren ulermena erakusten duen irtenbide baten zirriborroa besterik ez dugu behar. Hala ere, hautagaiak arbelean idatzi zuen kodea erabateko zentzugabekeria zen. Oso ideia lausoa zuen JavaScript-en zer promes zeuden eta ezin zuen azaldu zergatik behar ziren. Junior batentzat hori barkagarria izango zen, baina jada ez zegoen senior baten posturako egokia. Nola lortuko luke garatzaile honek promes-kate konplexu batean akatsak konpondu eta besteei zer egin duen zehazki?
Garatzaileek prest egindako kodea nabaritzat jotzen dute
Garapen prozesuan zehar, material erreproduzigarriak topatzen ditugu etengabe. Kode zatiak transferitzen ditugu, aldi bakoitzean berriro idatzi behar ez izateko. Horren arabera, gure arreta guztia funtsezko ataletan jarrita, lan egiten dugun kodea amaitutakoari begi bistakoa den zerbait bezala ikusten dugu; besterik gabe, dena behar bezala funtzionatuko duela suposatzen dugu.
Eta normalean funtzionatzen du, baina gauzak zailak direnean, mekanika ulertzeak balio du.
Hala, garatzaile senior posturako gure hautagaiak agintzen dituen objektuak begi-bistakotzat jo zituen. Seguruenik, beste norbaiten kodean gertatzen direnean nola tratatu ideia bat izan zuen, baina ez zuen printzipio orokorra ulertzen eta ezin izan zuen elkarrizketan zehar errepikatu. Beharbada zatia gogoan izan zuen - ez da hain zaila:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Nik ere egin nuen, eta ziurrenik denok egin dugu noizbait. Kode zati bat besterik ez zuten memorizatu, gero beren lanean erabili ahal izateko, dena nola funtzionatzen zuenaren ideia orokorra besterik ez zuten izan. Baina garatzaileak kontzeptua benetan ulertuko balu, ez luke ezer gogoratu beharko; besterik gabe, nola egiten den jakingo luke eta behar zuen guztia kodean erraz erreproduzituko luke.
Itzuli sustraietara
2012an, frontend-esparruen nagusitasuna oraindik ezarri gabe zegoenean, jQueryk mundua gobernatu zuen, eta liburua irakurri nuen. , John Resig-en egilea, jQuery-ren sortzailea.
Liburuak irakurleari bere jQuery hutsetik nola sortzen irakasten dio eta liburutegia sortzea ekarri zuen pentsamendu-prozesuaren ikuspegi paregabea eskaintzen du. Azken urteotan, jQuery-k lehengo ospea galdu du, baina oraindik liburua gomendatzen dut. Berari buruz gehien harritu ninduena hau guztia neuk pentsa nezakeenaren sentimendu iraunkorra izan zen. Egileak deskribatu zituen urratsak hain logikoak ziruditen, hain argiak ezen serio hasi nintzen pentsatzen jQuery erraz sortu nezakeela horretara iritsiz gero.
Noski, errealitatean ezingo nuke horrelako ezer egin - ezinezko zaila zela erabakiko nuke. Nire irtenbideak sinpleegiak eta inozoegiak irudituko litzaidake lan egiteko, eta amore emango nuke. Nik jQuery gauza ageriko gisa sailkatuko nuke, funtzionamendu egokian itsu-itsuan sinetsi besterik ez duzu behar. Gerora, ia ez nuke denbora galduko liburutegi honen mekanikan sakontzen, baizik eta kutxa beltz moduko bat bezala erabiliko nuke.
Baina liburu hau irakurtzeak beste pertsona bat bihurtu nau. Iturburu-kodea irakurtzen hasi nintzen eta irtenbide askoren ezarpena oso gardena zela konturatu nintzen, baita agerikoa ere. Ez, noski, zure kabuz horrelako zerbait pentsatzea beste istorio bat da. Baina besteen kodea aztertzea eta lehendik dauden soluzioak erreproduzitzea da, gure zerbait lortzen laguntzen diguna.
Lortzen duzun inspirazioa eta nabaritzen hasten zaren ereduak garatzaile gisa aldatuko zaitu. Konturatuko zara etengabe erabiltzen duzun eta artefaktu magiko gisa pentsatzera ohituta zauden liburutegi zoragarri horrek ez duela magian batere funtzionatzen, baizik eta arazo bat lakonikoki eta baliabidez konpontzen duela.
Batzuetan, kodea aztertu beharko duzu, pausoz pauso aztertuz, baina horrela, urrats txiki eta koherenteetan mugituz, egilearen konponbiderako bidea errepika dezakezu. Horrek kodetze-prozesuan sakontzeko aukera emango dizu eta konfiantza gehiago emango dizu zure irtenbideak lortzeko.
Promesekin lanean hasi nintzenean, magia hutsa iruditu zitzaidan. Orduan jakin nuen dei berdinetan oinarritzen zirela, eta nire programazio mundua hankaz gora jarri zen. Beraz, eredua, zeinaren helburua dei-itzultzeetatik salbatzea da, bera dei-itzulerak erabiliz inplementatzen da?!
Honek gaia beste begi batzuekin aztertzen lagundu zidan eta konturatu nintzen hori ez dela nire aurrean kode-zati abstruso bat, bizitzan inoiz ulertuko ez dudan konplexutasun debekua. Jakin-min eta murgiltze sakonarekin arazorik gabe uler daitezkeen ereduak besterik ez dira. Honela ikasten du jendeak kodetzen eta garatzaile gisa hazten.
Gurpil hau berrasmatu
Beraz, aurrera eta berrasmatu gurpilak: idatzi zure datuak lotzeko kodea, sortu etxeko promesa bat edo egin zure egoera kudeatzeko irtenbidea ere.
Berdin du inork ez duela inoiz hori guztia erabiliko, baina orain badakizu nola egin. Eta gerora zure proiektuetan horrelako garapenak erabiltzeko aukera baduzu, hori oso ona da. Horiek garatu eta beste zerbait ikasi ahal izango duzu.
Kontua ez da zure kodea produkziora bidaltzea, zerbait berria ikastea baizik. Lehendik dagoen soluzio baten inplementazioa idaztea modu bikaina da programatzaile onenengandik ikasteko eta horrela zure gaitasunak hobetzeko.
Iturria: www.habr.com