Një ditë tjetër intervistova një zhvillues JavaScript i cili po aplikonte për një pozicion të lartë. Një koleg, i cili ishte gjithashtu i pranishëm në intervistë, i kërkoi kandidatit të shkruante një funksion që do të bënte një kërkesë HTTP dhe, nëse nuk kishte sukses, do të provonte përsëri disa herë.
Ai e shkroi kodin direkt në tabelë, kështu që do të mjaftonte të vizatohej diçka e përafërt. Nëse ai thjesht do të kishte treguar se e kuptonte mirë se çfarë ishte çështja, do të ishim mjaft të kënaqur. Por, për fat të keq, ai nuk ishte në gjendje të gjente një zgjidhje të suksesshme. Më pas, ne, duke e çuar deri në entuziazëm, vendosëm ta bënim detyrën pak më të lehtë dhe i kërkuam që të kthente një funksion me kthime të thirrjeve në një funksion të ndërtuar mbi premtime.
Por mjerisht. Po, ishte e qartë se ai kishte hasur në një kod të tillë më parë. Ai e dinte në përgjithësi se si funksiononte gjithçka atje. Gjithçka që na nevojitet është një skicë e një zgjidhjeje që demonstron një kuptim të konceptit. Megjithatë, kodi që kandidati ka shkruar në tabelë ishte absurditet i plotë. Ai kishte një ide shumë të paqartë se cilat ishin premtimet në JavaScript dhe nuk mund të shpjegonte vërtet pse duheshin. Për një junior kjo do të ishte e falshme, por ai nuk ishte më i përshtatshëm për pozicionin e një të moshuari. Si do të ishte në gjendje ky zhvillues të rregullonte gabimet në një zinxhir kompleks premtimesh dhe t'u shpjegonte të tjerëve se çfarë bëri saktësisht?
Zhvilluesit e konsiderojnë kodin e gatshëm të vetëkuptueshëm
Gjatë procesit të zhvillimit, ne vazhdimisht hasim materiale të riprodhueshme. Ne transferojmë fragmente kodi në mënyrë që të mos na duhet t'i rishkruajmë ato çdo herë. Prandaj, duke e përqendruar të gjithë vëmendjen tonë në pjesët kryesore, ne e shikojmë kodin e përfunduar me të cilin punojmë si diçka të vetëkuptueshme - thjesht supozojmë se gjithçka do të funksionojë ashtu siç duhet.
Dhe zakonisht funksionon, por kur gjërat bëhen të ndërlikuara, të kuptuarit e mekanikës më shumë sesa shpërblehet.
Kështu, kandidati ynë për pozicionin e zhvilluesit të lartë i konsideroi objektet e premtimit si të vetëkuptueshme. Ai ndoshta kishte një ide se si t'i trajtonte ato kur ato ndodhin diku në kodin e dikujt tjetër, por ai nuk e kuptoi parimin e përgjithshëm dhe nuk mund ta përsëriste vetë gjatë intervistës. Ndoshta ai e kujtoi fragmentin përmendësh - nuk është aq e vështirë:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});E bëra edhe unë - dhe ndoshta të gjithë e kemi bërë në një moment. Ata thjesht mësuan përmendësh një pjesë të kodit në mënyrë që të mund ta përdornin më vonë në punën e tyre, ndërsa kishin vetëm një ide të përgjithshme se si funksiononte gjithçka atje. Por nëse zhvilluesi do ta kuptonte vërtet konceptin, ai nuk do të duhej të mbante mend asgjë - ai thjesht do të dinte ta bënte atë dhe do të riprodhonte lehtësisht gjithçka që i nevojitej në kod.
Kthehuni te rrënjët
Në vitin 2012, kur dominimi i kornizave të përparme nuk ishte vendosur ende, jQuery sundoi botën dhe unë lexova librin , me autor John Resig, krijues i jQuery.
Libri i mëson lexuesit se si të krijojë jQuery-n e tij nga e para dhe ofron një pasqyrë unike në procesin e të menduarit që çoi në krijimin e bibliotekës. Vitet e fundit, jQuery ka humbur popullaritetin e tij të mëparshëm, por unë ende e rekomandoj shumë librin. Ajo që më goditi më shumë tek ajo ishte ndjenja e vazhdueshme që mund t'i kisha menduar vetë të gjitha këto. Hapat që përshkroi autori më dukeshin aq logjikë, aq të qartë sa fillova të mendoj seriozisht se mund të krijoja lehtësisht jQuery nëse thjesht do të merresha me të.
Sigurisht, në realitet nuk do të kisha mundur të bëja diçka të tillë - do të kisha vendosur që ishte jashtëzakonisht e vështirë. Zgjidhjet e mia do të dukeshin shumë të thjeshta dhe naive për të punuar, dhe unë do të hiqja dorë. Unë do ta klasifikoja jQuery si gjëra të vetëkuptueshme, në funksionimin e duhur të të cilave thjesht duhet të besosh verbërisht. Më pas, vështirë se do të humbisja kohë duke u thelluar në mekanikën e kësaj biblioteke, por thjesht do ta përdorja atë si një lloj kutie të zezë.
Por leximi i këtij libri më bëri një person tjetër. Fillova të lexoja kodin burimor dhe zbulova se zbatimi i shumë zgjidhjeve ishte në fakt shumë transparent, madje i dukshëm. Jo, sigurisht, të mendosh për diçka të tillë vetë është një histori tjetër. Por është studimi i kodit të njerëzve të tjerë dhe riprodhimi i zgjidhjeve ekzistuese që na ndihmon të arrijmë diçka tonën.
Frymëzimi që fitoni dhe modelet që filloni të vini re do t'ju ndryshojnë si zhvillues. Do të zbuloni se ajo bibliotekë e mrekullueshme që përdorni vazhdimisht dhe që jeni mësuar ta mendoni si një objekt magjik nuk funksionon aspak me magji, por thjesht zgjidh një problem në mënyrë lakonike dhe me shkathtësi.
Ndonjëherë do t'ju duhet të hidheni mbi kodin, duke e analizuar atë hap pas hapi, por kështu, duke lëvizur në hapa të vegjël dhe të qëndrueshëm, mund të përsërisni rrugën e autorit drejt zgjidhjes. Kjo do t'ju lejojë të zhyteni më thellë në procesin e kodimit dhe t'ju japë më shumë besim për të gjetur zgjidhjet tuaja.
Kur fillova të punoja për herë të parë me premtime, më dukej si magji e pastër. Pastaj kuptova se ato bazoheshin në të njëjtat kthime të thirrjeve dhe bota ime e programimit u kthye përmbys. Pra, modeli, qëllimi i të cilit është të na shpëtojë nga kthimet e thirrjeve, është zbatuar vetë duke përdorur kthimet e thirrjeve?!
Kjo më ndihmoi ta shikoja çështjen me sy të ndryshëm dhe të kuptoja se ky nuk është një kod i çuditshëm përpara meje, kompleksitetin ndalues të të cilit nuk do ta kuptoj kurrë në jetën time. Këto janë vetëm modele që mund të kuptohen pa probleme me kuriozitetin e duhur dhe zhytjen e thellë. Kjo është mënyra se si njerëzit mësojnë të kodojnë dhe rriten si zhvillues.
Rishpikeni këtë rrotë
Pra, vazhdoni dhe rishpikni rrotat: shkruani kodin tuaj të lidhjes së të dhënave, krijoni një premtim të brendshëm ose madje bëni zgjidhjen tuaj të menaxhimit të shtetit.
Nuk ka rëndësi që askush nuk do t'i përdorë të gjitha këto - por tani ju e dini se si ta bëni atë. Dhe nëse keni mundësinë të përdorni më pas zhvillime të tilla në projektet tuaja, atëherë kjo është përgjithësisht e mrekullueshme. Ju do të jeni në gjendje t'i zhvilloni ato dhe të mësoni diçka tjetër.
Çështja këtu nuk është të dërgoni kodin tuaj në prodhim, por të mësoni diçka të re. Shkrimi i zbatimit tuaj të një zgjidhjeje ekzistuese është një mënyrë e shkëlqyer për të mësuar nga programuesit më të mirë dhe për të përmirësuar kështu aftësitë tuaja.
Burimi: www.habr.com