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
