Kitą dieną kalbinau „JavaScript“ kūrėją, kuris pretendavo į aukštas pareigas. Pokalbyje taip pat dalyvavęs kolega paprašė kandidato parašyti funkciją, kuri pateiktų HTTP užklausą ir, jei nepavyktų, kelis kartus bandytų dar kartą.
Kodą jis parašė tiesiai ant lentos, tad pakaktų ką nors apytiksliai nupiešti. Jei jis būtų tiesiog parodęs, kad gerai supranta, kas yra, būtume buvę visai patenkinti. Tačiau, deja, jam nepavyko rasti sėkmingo sprendimo. Tada mes, susijaudinę, nusprendėme šiek tiek palengvinti užduotį ir paprašėme jo funkciją su atgaliniais skambučiais paversti funkcija, pagrįsta pažadais.
Bet deja. Taip, buvo akivaizdu, kad su tokiu kodu jis buvo susidūręs ir anksčiau. Jis apskritai žinojo, kaip ten viskas veikia. Viskas, ko mums reikia, yra sprendimo eskizas, rodantis koncepcijos supratimą. Tačiau kodas, kurį kandidatas parašė lentoje, buvo visiška nesąmonė. Jis labai miglotai suprato, kokie pažadai buvo „JavaScript“, ir iš tikrųjų negalėjo paaiškinti, kodėl jie reikalingi. Jaunesniajam tai būtų buvę atleistina, bet jis nebetinka vyresniojo pareigoms. Kaip šis kūrėjas galėtų ištaisyti klaidas sudėtingoje pažadų grandinėje ir paaiškinti kitiems, ką tiksliai jis padarė?
Kūrėjai mano, kad paruoštas kodas yra savaime suprantamas dalykas
Kūrimo proceso metu nuolat susiduriame su atkuriamomis medžiagomis. Perkeliame kodo fragmentus, kad nereikėtų jų kiekvieną kartą rašyti iš naujo. Atitinkamai, sutelkdami visą savo dėmesį į pagrindines dalis, į baigtą kodą, su kuriuo dirbame, žiūrime kaip į savaime suprantamą dalyką – tiesiog darome prielaidą, kad viskas veiks taip, kaip turėtų.
Ir paprastai tai veikia, bet kai viskas tampa sudėtinga, suprasti mechaniką labiau apsimoka.
Taigi mūsų kandidatas į vyresniojo kūrėjo pareigas pažadų objektus laikė savaime suprantamais. Greičiausiai jis turėjo idėją, kaip su jais elgtis, kai jos atsiranda kažkur kieno nors kito kode, tačiau nesuprato bendro principo ir pats negalėjo to pakartoti pokalbio metu. Galbūt jis prisiminė fragmentą mintinai - tai nėra taip sunku:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Aš taip pat tai padariau – ir tikriausiai visi kažkada tai padarėme. Jie tiesiog įsiminė kodo fragmentą, kad vėliau galėtų jį panaudoti savo darbe, turėdami tik bendrą supratimą, kaip ten viskas veikia. Tačiau jei kūrėjas tikrai suprastų koncepciją, jam nereikėtų nieko prisiminti – jis tiesiog žinotų, kaip tai padaryti, ir lengvai atkurtų viską, ko jam reikia.
Grįžk prie šaknų
2012 m., kai dar nebuvo nustatytas priekinių sistemų dominavimas, jQuery valdė pasaulį, o aš perskaičiau knygą , kurio autorius Johnas Resigas, „jQuery“ kūrėjas.
Knyga moko skaitytoją, kaip sukurti savo „jQuery“ nuo nulio, ir suteikia unikalią įžvalgą apie minties procesą, kuris paskatino sukurti biblioteką. Pastaraisiais metais „jQuery“ prarado savo buvusį populiarumą, bet vis tiek labai rekomenduoju knygą. Mane labiausiai apie ją sukrėtė nuolatinis jausmas, kad aš pati galėjau apie visa tai pagalvoti. Autoriaus aprašyti žingsniai atrodė tokie logiški, tokie aiškūs, kad aš rimtai ėmiau galvoti, jog galėčiau nesunkiai sukurti „jQuery“, jei tik pasieksiu.
Žinoma, realiai aš nieko panašaus nebūčiau galėjęs – būčiau nusprendęs, kad tai buvo nepakeliamai sunku. Mano sprendimai atrodytų pernelyg paprasti ir naivūs, kad galėčiau dirbti, ir aš pasiduočiau. JQuery priskirčiau prie savaime suprantamų dalykų, kurių teisingu veikimu tereikia aklai tikėti. Vėliau vargu ar gaiščiau laiko gilindamasis į šios bibliotekos mechaniką, o tiesiog naudočiau ją kaip savotišką juodąją dėžę.
Tačiau skaitydama šią knygą tapau kitokiu žmogumi. Pradėjau skaityti šaltinio kodą ir sužinojau, kad daugelio sprendimų įgyvendinimas iš tikrųjų buvo labai skaidrus, netgi akivaizdus. Ne, žinoma, sugalvoti kažką panašaus vienam yra kita istorija. Tačiau kitų žmonių kodo studijavimas ir esamų sprendimų atkūrimas padeda mums sugalvoti kažką savo.
Įkvėpimas, kurį gausite, ir modeliai, kuriuos pradėsite pastebėti, pakeis jus kaip kūrėją. Pamatysite, kad ta nuostabi biblioteka, kuria nuolat naudojatės ir kurią esate įpratę galvoti kaip apie magišką artefaktą, visiškai neveikia magijos, o tiesiog lakoniškai ir išradingai išsprendžia problemą.
Kartais teks perskaityti kodą, jį analizuojant žingsnis po žingsnio, tačiau taip judant mažais, nuosekliais žingsneliais galima pakartoti autoriaus kelią į sprendimą. Tai leis jums giliau pasinerti į kodavimo procesą ir suteiks daugiau pasitikėjimo kuriant savo sprendimus.
Kai pradėjau dirbti su pažadais, man tai atrodė gryna magija. Tada sužinojau, kad jie buvo pagrįsti tais pačiais skambučiais, ir mano programavimo pasaulis apsivertė aukštyn kojomis. Taigi modelis, kurio tikslas yra išgelbėti mus nuo atgalinių skambučių, pats įgyvendinamas naudojant atgalinius skambučius?!
Tai padėjo man pažvelgti į šį reikalą kitomis akimis ir suprasti, kad tai nėra kažkoks absurdiškas kodo fragmentas priešais mane, kurio neįtikėtino sudėtingumo aš niekada gyvenime nesuvoksiu. Tai tik modeliai, kuriuos galima suprasti be problemų su deramu smalsumu ir giliai pasinėrus. Taip žmonės mokosi koduoti ir tobulėti kaip kūrėjai.
Išradinėk šį ratą iš naujo
Taigi pirmyn ir išraskite ratus iš naujo: parašykite savo duomenų susiejimo kodą, sukurkite namuose sukurtą pažadą ar net sukurkite savo valstybės valdymo sprendimą.
Nesvarbu, kad niekas to niekada nenaudos – bet dabar jūs žinote, kaip tai padaryti. Ir jei turite galimybę vėliau panaudoti tokius pokyčius savo projektuose, tai paprastai yra puiku. Galėsite juos tobulinti ir išmokti kažko kito.
Esmė yra ne siųsti savo kodą į gamybą, o išmokti ką nors naujo. Savo esamo sprendimo diegimo rašymas yra puikus būdas mokytis iš geriausių programuotojų ir taip patobulinti savo įgūdžius.
Šaltinis: www.habr.com