Teisel päeval intervjueerisin JavaScripti arendajat, kes kandideeris kõrgemale ametikohale. Ka vestlusel viibinud kolleeg palus kandidaadil kirjutada funktsioon, mis teeks HTTP päringu ja kui see ei õnnestu, prooviks mitu korda uuesti.
Ta kirjutas koodi otse tahvlile, nii et piisaks sellest, kui joonistada midagi ligikaudset. Kui ta oleks lihtsalt näidanud, et saab hästi aru, milles asi, oleksime päris rahul olnud. Kuid kahjuks ei suutnud ta leida edukat lahendust. Seejärel otsustasime seda põnevust tekitades ülesande pisut lihtsamaks muuta ja palusime tal muuta tagasihelistamisega funktsioon lubadustele üles ehitatud funktsiooniks.
Aga paraku. Jah, oli näha, et ta oli sellise koodiga varem kokku puutunud. Ta teadis üldiselt, kuidas seal kõik toimib. Kõik, mida vajame, on lahenduse eskiis, mis näitab kontseptsiooni mõistmist. Kood, mille kandidaat tahvlile kirjutas, oli aga täielik jama. Tal oli väga ebamäärane ettekujutus JavaScriptis sisalduvatest lubadustest ja ta ei osanud tegelikult selgitada, miks neid vaja on. Juuniori jaoks olnuks see andestatav, kuid seeniori ametikohale ta enam ei sobinud. Kuidas suudaks see arendaja keerulises lubaduste ahelas vigu parandada ja teistele selgitada, mida ta täpselt tegi?
Arendajad peavad valmiskoodi iseenesestmõistetavaks
Arendusprotsessi käigus puutume pidevalt kokku reprodutseeritavate materjalidega. Me edastame koodifragmendid, et me ei peaks neid iga kord uuesti kirjutama. Seega, keskendudes kogu oma tähelepanu võtmeosadele, vaatame valmis koodi, millega töötame, kui midagi iseenesestmõistetavat – eeldame lihtsalt, et kõik töötab nii nagu peab.
Ja tavaliselt see töötab, kuid kui asjad muutuvad keeruliseks, tasub mehaanika mõistmine rohkem kui ära.
Seega pidas meie kandidaat vanemarendaja ametikohale lubadusobjekte iseenesestmõistetavaks. Tõenäoliselt oli tal idee, kuidas nendega toime tulla, kui need kuskil kellegi teise koodis esinevad, kuid ta ei mõistnud üldist põhimõtet ega saanud seda intervjuu ajal ise korrata. Võib-olla mäletas ta seda fragmenti peast - see pole nii raske:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Mina tegin seda ka – ja ilmselt oleme kõik seda mingil hetkel teinud. Nad lihtsalt jätsid koodijupi pähe, et saaksid seda hiljem oma töös kasutada, omades samas ainult üldist ettekujutust, kuidas kõik seal toimis. Kuid kui arendaja kontseptsioonist tõeliselt aru sai, ei peaks ta midagi meeles pidama – ta lihtsalt teaks, kuidas seda teha, ja reprodutseerib hõlpsalt kõik, mida vaja, koodis.
Mine tagasi juurte juurde
2012. aastal, kui esiotsa raamistike domineerimine polnud veel välja kujunenud, valitses maailma jQuery ja ma lugesin raamatut , mille autoriks on jQuery looja John Resig.
Raamat õpetab lugejale, kuidas luua oma jQuery nullist, ja annab ainulaadse ülevaate mõtteprotsessist, mis viis raamatukogu loomiseni. Viimastel aastatel on jQuery oma endise populaarsuse kaotanud, kuid soovitan raamatut siiski soojalt. Tema juures rabas mind kõige enam püsiv tunne, et oleksin võinud sellele kõigele ka ise mõelda. Autori kirjeldatud sammud tundusid nii loogilised, nii selged, et hakkasin tõsiselt mõtlema, et saaksin lihtsalt jQuery luua, kui selleni jõuan.
Muidugi, tegelikkuses poleks ma midagi sellist teha saanud – oleksin otsustanud, et see oli väljakannatamatult raske. Minu enda lahendused tunduksid toimimiseks liiga lihtsad ja naiivsed ning ma annaksin alla. Mina liigitaksin jQuery enesestmõistetavateks asjadeks, mille õigesse toimimisse tuleb lihtsalt pimesi uskuda. Edaspidi ma vaevalt aega raiskaksin selle raamatukogu mehaanikasse süvenemisele, vaid kasutaksin seda lihtsalt omamoodi musta kastina.
Kuid selle raamatu lugemine tegi minust hoopis teise inimese. Hakkasin lugema lähtekoodi ja avastasin, et paljude lahenduste rakendamine oli tegelikult väga läbipaistev, isegi ilmne. Ei, muidugi, kui midagi sellist omaette välja mõelda, on hoopis teine lugu. Kuid see on teiste inimeste koodide uurimine ja olemasolevate lahenduste reprodutseerimine, mis aitab meil midagi omaette välja mõelda.
Saadud inspiratsioon ja mustrid, mida hakkad märkama, muudavad sind kui arendajat. Leiate, et see imeline raamatukogu, mida te pidevalt kasutate ja mida olete harjunud pidama maagiliseks artefaktiks, ei tööta üldse maagial, vaid lihtsalt lahendab probleemi lakooniliselt ja leidlikult.
Mõnikord peate koodi üle uurima, analüüsides seda samm-sammult, kuid nii saate väikeste järjepidevate sammude kaupa korrata autori teed lahenduseni. See võimaldab teil sukelduda kodeerimisprotsessi sügavamale ja annab teile rohkem kindlustunnet oma lahenduste leidmisel.
Kui ma esimest korda lubadustega tööd alustasin, tundus see mulle puhta maagiana. Siis sain teada, et need põhinevad samadel tagasihelistustel ja minu programmeerimismaailm pöördus pea peale. Nii et muster, mille eesmärk on päästa meid tagasihelistamisest, on ise realiseeritud tagasihelistamiste abil?!
See aitas mul asjale teise pilguga otsa vaadata ja aru saada, et see ei ole mingi abstraktne koodijupp mu ees, mille ülemäärasest keerukusest ma oma elus aru ei saa. Need on lihtsalt mustrid, millest saab ilma probleemideta aru saada piisava uudishimu ja sügava keelekümbluse korral. Nii õpivad inimesed kodeerima ja arenema arendajana.
Leiutage see ratas uuesti
Nii et minge edasi ja leiutage rattad uuesti: kirjutage oma andmete sidumiskood, looge omakasutatud lubadus või looge isegi oma riigihalduslahendus.
Pole tähtis, et keegi seda kõike kunagi ei kasuta – aga nüüd teate, kuidas seda teha. Ja kui teil on võimalus selliseid arendusi hiljem oma projektides kasutada, on see üldiselt suurepärane. Saate neid arendada ja midagi muud õppida.
Siin pole mõtet koodi tootmisse saata, vaid õppida midagi uut. Olemasoleva lahenduse enda teostuse kirjutamine on suurepärane võimalus õppida parimatelt programmeerijatelt ja seeläbi oma oskusi lihvida.
Allikas: www.habr.com