Kohët e fundit, kam zhvilluar një intervistë me një zhvillues JavaScript që pretendonte për pozitat e seniorit. Një koleg, i pranishëm gjithashtu 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 disa herë.
Ai shkroi kodin drejtpërdrejt në tabelë, kështu që mjaftonte të paraqiste diçka të përafërt. Po të kishte treguar se kuptonte mirë thelbin e çështjes, ne do të ishim të kënaqur. Por, fatkeqësisht, ai nuk mundi të gjejë një zgjidhje të mirë. Atëherë, duke e përmendur këtë si një rast nervozizmi, vendosëm të lehtësojmë pak punën dhe kërkuam që ta shndërronte funksionin me kthime në një funksion të ndërtuar mbi premtimet.
Por, fatkeqësisht. Po, ishte e qartë se një kod i tillë i ishte paraqitur më parë. Ai në përgjithësi e dinte se si funksiononte, por na mjaftonte vetëm një skicë zgjidhjeje që do të tregonte kuptimin e konceptit. Megjithatë, kodi që kandidat shkruante në tabelë ishte një përllogaritje e plotë. Ai kishte një ide të paqartë se çfarë ishin premtimet në JavaScript dhe nuk mundi të shpjegonte dot pse ishin të nevojshme. Për një junior do të kishte qenë akoma e pranueshme, por për një pozita seniori nuk ishte e mjaftueshme. Si do të arrinte ky zhvillues të eliminonte bug-ët në një zinxhir kompleks me premtimet dhe ta shpjegonte atë për të tjerët?
Zhvilluesit e konsiderojnë kodin e gatshëm vetëkuptues.
Gjatë zhvillimit, ne përballemi vazhdimisht me materiale të riprodhueshme. Ne transferojmë fragmente kodi për të mos pasur nevojë që t'i shkruajmë nga e para çdo herë. Duke u fokusuar në pjesët kyçe, ne e shohim kodin e gatshëm që përdorim si diçka të vetëkuptueshme - thjesht supozojmë se gjithçka do të funksionojë si duhet.
Dhe zakonisht, ai vërtet funksionon, por kur ndodhin vështirësi, kuptimi i mekanizmit të tij e shpërblen tej mase.
Kështu, kandidati ynë për pozitat e zhvilluesit senior e konsideronte objektin promise si të vetëkuptueshëm. Ndoshta ai e kishte idenë se si të menaxhohej kur ato shfaqeshin në kodin e dikujt tjetër, por nuk e kuptonte parimin e përgjithshëm dhe nuk arriti ta përsëriste atë gjatë intervistës. Ndoshta ai kishte mësuar një fragment 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Ă«tĂ« â ndoshta tĂ« gjithĂ« ne, ndonjĂ«herĂ« e kemi bĂ«rĂ« kĂ«tĂ«. Thjesht e kemi mĂ«suar njĂ« copĂ« kod, qĂ« ta pĂ«rdorim mĂ« vonĂ« nĂ« punĂ«, duke pasur nĂ« mendje vetĂ«m njĂ« pĂ«rshkrim tĂ« pĂ«rgjithshĂ«m se si funksionon. Por nĂ«se njĂ« zhvillues do tĂ« kuptonte vĂ«rtet konceptin, nuk do t'i duhej tĂ« mĂ«sonte asgjĂ« â ai do ta dinte se si bĂ«het, dhe do ta riprodhonte lehtĂ«sisht gjithçka tĂ« nevojshme nĂ« kod.
Kthehuni te burimet
Në 2012, kur dominimi i frame work-eve të frontendit nuk ishte vendosur ende, bota e udhëhiqte jQuery, dhe unë isha duke lexuar një libër , autori i të cilit ishte John Resig, krijuesi i jQuery.
Libri e mëson lexuesin se si të krijojë jQuery-në e tij nga e para dhe ofron një mundësi unike për t'u njohur me mënyrën e të menduarit që çoi në krijimin e bibliotekës. Në vitet e fundit, jQuery ka humbur popullaritetin e saj të dikurshëm, por unë ende shumë e rekomandoj librin. Ajo që më befasoi më shumë është ndjenja e vazhdueshme se edhe unë mund të kisha arritur në këtë përfundim vetë. Hapat që përshkruante autori duken kaq logjikë, kaq të qartë, saqë fillova seriozisht të mendoj se mund ta kisha krijuar lehtësisht jQuery-në, nëse do të kisha nisur punën.
Sigurisht, nĂ« realitet, nuk do tĂ« isha pĂ«rballuar me diçka tĂ« tillĂ« â do ta kisha vendosur se ishte shumĂ« e vĂ«shtirĂ«. Zgjidhjet e mia do tĂ« mĂ« dukeshin tepĂ«r tĂ« thjeshta dhe naive pĂ«r t'u funksionuar, dhe do tĂ« dorĂ«zoja duart. UnĂ« do ta kisha konsideruar jQuery-nĂ« si diçka tĂ« dukshme, nĂ« korrektĂ«sinĂ« e tĂ« cilĂ«s thjesht duhej tĂ« besonim verbĂ«risht. NĂ« vijim, sigurisht qĂ« nuk do tĂ« kisha humbur kohĂ« pĂ«r tĂ« kuptuar mekanikĂ«n e kĂ«saj biblioteke, por do tĂ« kisha pĂ«rdorur atĂ« si njĂ« lloj kutie tĂ« zezĂ«.
Por njohja me kĂ«tĂ« libĂ«r mĂ« ka bĂ«rĂ« njĂ« person tjetĂ«r. Kam filluar tĂ« lexoj kodin burimor dhe kam zbuluar se implementimi i shumĂ« zgjidhjeve nĂ« tĂ« vĂ«rtetĂ« Ă«shtĂ« shumĂ« i qartĂ«, madje edhe i dukshĂ«m. Jo, sigurisht, qĂ« tĂ« arrish nĂ« diçka tĂ« tillĂ« â Ă«shtĂ« njĂ« tjetĂ«r storie. Por pikĂ«risht studimi i kodit tĂ« tĂ« tjerĂ«ve dhe riprodhimi i zgjidhjeve ekzistuese na ndihmon tĂ« krijojmĂ« diçka tonĂ«n.
Inspiarja që do të merrni dhe modelet që do të filloni të vini re do t'ju ndryshojnë si zhvillues. Do të zbuloni se ajo bibliotekë e shkëlqyer që përdorni vazhdimisht dhe mbi të cilën jeni mësuar të mendoni si një artefakt magjik, nuk funksionon në asnjë mënyrë magjike, por thjesht zgjidh problemin në një mënyrë të qartë dhe ingenioze.
Ndonjëherë do të duhet të punoni me kodin, duke e shqyrtuar atë hap pas hapi, por pikërisht duke ecur me hapa të vegjël e të vazhdueshëm, do të mund të përsërisni rrugën e autorit drejt zgjidhjes. Kjo do t'ju lejojë të thelloheni më thellë në procesin e shkrimit të kodit dhe do t'ju japë më shumë besim në kërkimin e zgjidhjeve të njëjta.
Kur fillova të punoja me premtimet, më dukej se ishte magji e pastër. Pastaj mësova se ato bazohen në të njëjtit thirrje të prapsht, dhe bota ime si programues iu kthye përmbys. Pra, një model, që ka si qëllim të na çlirojë nga thirrjet e prapshta, realizohet vetë me anë të thirrjeve të prapshta?!
Kjo më ndihmoi të shikoj punët nga një këndvështrim tjetër dhe të kuptoj se përpara meje nuk ka ndonjë copë kodi komplekse të pakuptueshme që kurrë në jetën time nuk do të arrij ta kuptoj. Janë thjesht modele, në të cilat mund të kuptoheni pa probleme nëse keni kuriozitet të mjaftueshëm dhe të thelloheni. Kështu njerëzit mësojnë të programojnë dhe rriten si zhvillues.
Ribëni këtë rrotë
Prandaj mos ngurroni të ribëni rrotat: shkruani vetë kodin për lidhjen e të dhënave, krijoni një premtim të bërë në shtëpi ose madje bëni vetë një zgjidhje për menaxhimin e gjendjeve.
Nuk ka rëndësi se askush nuk do ta përdorë këtë, sepse tani ju e dini këtë. Dhe nëse do të keni mundësinë ta përdorni më vonë një punë të tillë në projektet tuaja, është për të ardhur mirë. Do të jeni në gjendje t'i zhvilloni ato dhe do të mësoni diçka më shumë.
Këtu nuk është e rëndësishme 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 artin tuaj.
Burimi: habr.com
