Miks on kasulik ratast leiutada

Hiljuti viisin läbi intervjuu JavaScript arendajaga, kes kandideeris senior positsioonile. Kaastöötaja, kes samuti intervjuul viibis, palus kandidaadil kirjutada funktsiooni, mis teeks HTTP-päringu ja ebaõnnestumise korral prooviks veel mitu korda.

Ta kirjutas koodi otse tahvlile, seega piisanuks lihtsalt umbkaudse esituse tegemisest. Kui ta oleks lihtsalt näidanud, et mõistab hästi, mis asi see on, oleksime täielikult rahul olnud. Kahjuks ei õnnestunud tal aga leida head lahendust. Nii et arvestades tema närvilisust, otsustasime ülesannet veidi kergendada ja palusime tal muuta tagasikutsumisega funktsioon lubadustel põhinevaks funktsiooniks.

Kahjuks. Jah, oli selge, et sarnast koodi oli ta varem näinud. Ta teadis üldiselt, kuidas seal kõik toimib. Me oleksime rahul olnud lahenduse visandiga, mis näitaks, et ta mõistab kontsepti. Siiski, kood, mida kandidaat tahvlil kirjutas, oli täielik mõttetuks. Tal oli äärmiselt ähmane arusaam sellest, mis on JavaScripti lubadused, ja ta ei suutnud korralikult selgitada, miks neid vaja on. Juniorina oleks see olnud veel andestatav, kuid vanema positsiooni jaoks ei olnud ta sobiv. Kuidas suudaks see arendaja parandada vigu keerulises lubaduste ahelas ja selgitada teistele, mida ta täpselt tegi?

Arendajad peavad valmis koodi iseenesestmõistetavaks.

Arendamise protsessis kohtame pidevalt korduvaid materjale. Me kopeerime koodifragmente, et mitte iga kord neid uuesti kirjutama hakata. Seetõttu, keskendudes kõige olulisematele osadele, vaatame valmis koodi, millega töötame, kui millegi iseenesestmõistetavaga – me lihtsalt eeldame, et see töötab nii, nagu peab.

Ja see tavaliselt tõesti töötab, kuid kui tekivad raskused, tasub tema mehhanika mõistmine rohkem kui positiivne.

Nii arvati, et meie kandidaat vanema arendaja positsioonile nägi promise objekti iseenesestmõistetavalt. Ta tõenäoliselt kujutas ette, kuidas nendega hakkama saada, kui nad kuskil teiste koodis esinevad, kuid üldist põhimõtet ta ei mõistnud ja ei suutnud seda intervjuul ise uuesti luua. Võib-olla mäletas ta fragmenti peast – see pole ju üldse nii keeruline:

return new Promise((resolve, reject) => {
  functionWithCallback((err, result) => {
   return err ? reject(err) : resolve(result);
  });
});

Mina tegin seda ka – tõenäoliselt oleme kõik mingil hetkel seda teinud. Lihtsalt õppisime koodi tükki peast, et hiljem seda oma töös kasutada, omades ainult üldist ettekujutust, kuidas seal kõik töötab. Kuid kui arendaja mõistaks tõeliselt kontsepti, ei peaks ta midagi meelde jätma – ta lihtsalt teaks, kuidas see käib, ja saaks kõik vajaliku koodis hõlpsasti uuesti luua.

Pöörduge juurte poole

2012. aastal, kui frontend raamistike valitsemine veel ei olnud kehtestatud, valitses maailmas jQuery, ja ma lugesin raamatut Secrets of the JavaScript Ninja, mille autor oli John Resig, jQuery looja.

Raamat õpetab lugejat, kuidas luua oma jQuery nullist ja annab ainulaadse võimaluse tutvuda mõtlemisega, mis viis raamatukogu loomisele. Viimastel aastatel on jQuery oma endise populaarsuse kaotanud, kuid ma soovitan seda raamatut siiski väga. Mis mind raamatust kõige rohkem üllatas, oli tungiv tunne, et ma oleksin võinud sellele ise mõelda. Autor kirjeldatud sammud tundusid nii loogilised ja arusaadavad, et mul hakkas tõsiselt tunduma, et ma oleksin ka vabalt võinud jQuery luua, kui oleksin vaid asja ette võtnud.

Muidugi, reaalsuses ma ei oleks sellega hakkama saanud – oleksin arvanud, et see on ülemäära keeruline. Omandatud lahendused tunduksid mulle liiga lihtsad ja naiivsed, et töötada, ja ma oleksin käed rüppes alla andnud. Ma oleksin pidanud jQuery enesestmõistetavaks asjaks, mille korralikku toimimist on lihtsalt pimesi usaldama. Hiljem ma tõenäoliselt ei oleks kulutanud aega, et mõista selle raamatukogu mehhanismi, vaid oleksin seda kasutanud kui mingit musta kasti.

Kuid selle raamatu tutvumine muutis mind teiseks inimeseks. Hakkasin süvenema lähtekoodi ja avastasin, et paljude lahenduste rakendamine on tegelikult väga läbipaistev, isegi ilmne. Loomulikult, et selleni jõuda – see on juba hoopis teine lugu. Kuid just teiste koodi uurimine ja juba olemasolevate lahenduste rekonstrueerimine aitab meil midagi uut välja mõelda.

Inspiratsioon, mida te saad, ja mustrid, mida hakkate märkama, muudavad teid arendajana. Te avastate, et see suurepärane teek, mida te pidevalt kasutate ja mille kohta olete harjunud mõtlema kui maagilisele artefaktille, ei toimi sugugi maagia põhjal, vaid lahendab probleemi lihtsalt ja leidlikult.

Mõnikord tuleb koodi kallal vaeva näha, seda samm-sammult lahti muukides, kuid just nii, liikudes väikeste järjestikuste sammudega, suudate te autori teekonna lahendusele korrata. See süvendab teie arusaamist koodi kirjutamisprotsessist ja annab rohkem enesekindlust oma lahenduste leidmisel.

Kui ma esmakordselt lubadustega töötama hakkasin, tundus see mulle nagu puhas maagia. Siis sain aru, et nende aluseks on samad tagasisidekutsed ning minu arendaja maailm pöördus peapeale. See tähendab, et mustrit, mille eesmärk on meid tagasisidest vabastada, rakendatakse ise tagasisidekutsede abil?!

See aitas mul vaadata asjadele uue nurga alt ja mõista, et minu ees ei ole mingid keerukad koodijupid, mille ületamatu keerukus jääb mulle elu lõpuni arusaamatuks. Need on lihtsalt mustrid, millega saab lihtsasti hakkama, kui on piisavalt uudishimu ja süvenemist. Just nii inimesed programmeerimist õpivad ja arendajatena kasvavad.

Leiutage see ratta uuesti

Nii et julgelt leiutage rattaid ümber: kirjutage ise kood andmete sidumiseks, looge kodune lubadus või tehke isegi oma kätega lahendus seisundite haldamiseks.
Pole tähtis, et keegi neist kunagi ei kasuta – nüüd oskate seda teha. Ja kui teil peaks hiljem olema võimalus neid töötulemusi oma projektides kasutada, on see suurepärane. Saate neid arendada ja õppida veel midagi uut.

Mõttepunkt ei ole oma koodi tootmisse saamine, vaid uue kogemuse omandamine. Juba olemasoleva lahenduse iseseisev rakendamine on suurepärane viis õppida parematelt programmeerijatelt ja teravdada oma oskusi.

Allikas: habr.com