Disa ditë më parë bova një intervistë me një zhvillues JavaScript, i cili aplikonte për pozitën e seniorit. Një koleg, që gjithashtu ishte prezent në intervistë, i kërkoi kandidatit të shkruajë një funksion që do të bënte një kërkesë HTTP dhe, në rast dështimi, do të përpiqej përsëri disa herë.
Ai shkruante kodin direkt në bord, kështu që do të ishte mjaft e mjaftueshme të ilustronte diçka të afërt. Nëse ai do të kishte treguar thjesht se e kupton mirë thelbin e çështjes, do të ishim shumë të kënaqur. Por, fatkeqësisht, ai nuk arriti të gjente një zgjidhje të mirë. Atëherë, duke e konsideruar këtë si një rezultat të nervozizmit, vendosëm të lehtësojmë pak detyrën dhe e kërkuam të bënte nga funksioni me thirrje për prapa një funksion të ndërtuar mbi premtimet.
Por fat, ishte e qartë se një kod i tillë kishte ndodhur më parë për të. Ai e dinte në përgjithësi se si funksiononte gjithçka atje. Na mjaftonte një skicë zgjidhjeje që do të tregonte kuptimin e konceptit. Megjithatë, kodi që kandidati shkroi në bord ishte një paqartësi totale. Ai kishte një ide tepër të paqartë se çfarë janë premtimet në JavaScript dhe nuk mundi të shpjegonte saktësisht pse ato janë të nevojshme. Kjo do të ishte akoma e pranueshme për një junior, por për një pozitë si senior nuk jetësohej. Si do të ishte ky zhvillues në gjendje të rregullonte defektet në një zinxhir të komplikuar me premtimet dhe të shpjegonte të tjerëve se çfarë kishte bërë?
Zhvilluesit e konsiderojnë kodin e gatshëm si të vetëkuptueshëm
Në procesin e zhvillimit, ne vazhdimisht përballemi me materiale të riprodhueshme. Ne transferojmë fragmente kodi që të mos na duhet t'i shkruajmë ato nga e para çdo herë. Prandaj, duke fokusuar gjithë vëmendjen në pjesët kyçe, ne e shohim kodin e gatshëm me të cilin punojmë si diçka të vetëkuptueshme - ne thjesht supozojmë se gjithçka do të funksionojë siç duhet në të.
Dhe zakonisht funksionon në të vërtetë, por kur shfaqen vështirësi, kuptimi i mekanikës së tij ia vlen shumë.
Kështu, kandidati ynë për pozitat e zhvilluesit të nivelit të lartë e konsideronte obiektet promise si diçka të dukshme. Ai ndoshta e paraqiste se si të merrej me to kur shfaqeshin diku në kodin e dikujt tjetër, por nuk e kuptonte parimin e përgjithshëm dhe nuk arriti ta përsërisë atë gjatë intervistas. Ndoshta e kishte mësuar një pjesë përmendësh – nuk është aq e vështirë:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Edhe unë e kam bërë kështu – po, të gjithë ne, gjashtë do ta kemi bërë këtë ndonjëherë. Thjesht mësuam një copë kod për ta përdorur më vonë në punë, duke pasur vetëm në përgjithësi një ide sesi funksionohej gjithçka. Por, sikur zhvilluesi të kishte kuptuar vërtet konceptin, nuk do t'i duheshin t'i mësonte asgjë – do ta dinte thjesht se si të bëhej dhe do ta riprodhonte pa mundim gjithçka të nevojshme në kod.
Kërkoni burimet
Në vitin 2012, kur dominimi i framework-eve të frontend-it ende nuk ishte krijuar, jQuery mbante në duar botën dhe unë po lexoja një libër , autor i të cilit ishte John Resig, krijuesi i jQuery.
Libri i mëson lexuesin si të krijojë jQuery-n e vet nga zero dhe ofron një mundësi unike për t'u njohur me procesin e mendimit që çoi në krijimin e bibliotekës. Në vitet e fundit, jQuery ka humbur popullaritetin e saj, por unë gjithsesi e rekomandoj këtë libër. Ajo që më goditi më shumë në të, ishte ndjenja e fortë se unë do të isha në gjendje të arrija gjithashtu diçka të tillë vetë. Hapat që përshkruante autori duken kaq logjikë, kaq të kuptueshme, saqë më dukej seriozisht se unë mund të krijoja lehtësisht jQuery nëse do të isha angazhuar për të.
Natyrisht, në realitet unë nuk do të arrija ashtu siç e kam përshkruar – do të mendohesha se është shumë e vështirë. Zgjidhjet e mia do të dukeshin shumë të thjeshta dhe naive për të funksionuar, dhe do të dorëzoja duar. Unë do ta konsideroja jQuery si një gjë të vetëkuptueshme, në funksionimin e saktë të së cilës duhet të besohej verbërisht. Më vonë, ndoshta nuk do të shpenzoja kohë për të kuptuar mekanikën e kësaj biblioteke, por do ta përdorja atë si një kuti të zezë.
Njohja me këtë libër më bëri një njeri tjetër. Fillova të studioj kodin burimor dhe zbulova se realizimi i shumë zgjidhjeve është në të vërtetë shumë i qartë, madje edhe i dukshëm. Po, natyrisht, vetë t'u arrish deri te diçka të tillë – kjo është një tjetër histori. Por pikërisht studimi i kodit të tjerë dhe riprodhimi i zgjidhjeve tashmë ekzistuese na ndihmon të krijojmë diçka të vetën.
Inspirtimi që do të merrni dhe modelet që do të filloni të vëreni do t'ju transformojnë si zhvillues. Do të zbuloni se ai bibliotekë e mrekullueshme, me të cilin vazhdimisht punoni dhe për të cilën jeni zakonsht menduar si një artefakt magjik, nuk funksionon me magji, por thjesht zgjidh një problem në mënyrë të këndshme dhe dinake.
Ndonjëherë do të duhet të punoni me kodin, duke e analizuar atë hap pas hapi, por ashtu, duke u avancuar me hapa të vegjël të rregullta, do të mund të përsërisni rrugën e autorit drejt zgjidhjes. Kjo do t'ju lejojë të zhytni më thellë në procesin e kodimit dhe do t'ju japë më shumë besim në kërkimin e zgjidhjeve tuaja.
Kur fillova të punoj me premtimet, më dukej se ishte magji e pastër. Pastaj mësova se në themel të tyre qëndrojnë të njëjtat thirrje të prapshme, dhe bota ime si programues u përmbys. Domethënë, modeli që synon të na çlirojë nga thirrjet e prapme, realizohet vetë me ndihmën e thirrjeve të prapme?!
Kjo më ndihmoi të shoh gjërat ndryshe dhe të kuptoj se përpara meje nuk qëndrojnë disa pjesë kodesh të ndërlikuara, një kompleksitet që nuk do ta arrija kurrë në jetë. Ato janë thjesht modele, të cilat mund të kuptohen lehtësisht me pak kuriozitet dhe një zhytje të thellë. Pikërisht kështu njerëzit mësojnë programimin dhe rriten si zhvillues.
Rinnovoni këtë rrotë
Pra, mos hezitoni të rivendosni rrotat: shkruani vetë kodin për lidhjen e të dhënave, krijoni një premtim të bërë ndërsa vetë ose madje bëni një zgjidhje për menaxhimin e gjendjeve.
Nuk ka rëndësi që asnjë njeri nuk do ta përdorë ndonjëherë këtë – por tani ju e keni këtë aftësi. Dhe nëse do të keni mundësinë ta përdorni këtë punë në projektet tuaja në të ardhmen, atëherë kjo është madhe. Do të jeni në gjendje ta zhvilloni atë dhe do të mësoni diçka tjetër.
Qëllimi këtu nuk është të dërgoni kodin tuaj në prodhim, por të mësoni diçka të re. Të shkruani vetë realizimin e një zgjidhjeje ekzistuese është një mënyrë e shkëlqyer për të mësuar nga programuesit më të mirë dhe për të rafinuar aftësitë tuaja.
Burimi: habr.com
