Miks on kasulik rattaid välja mõelda

Hiljuti korraldasin intervjueerimise JavaScript arendajaga, kes kandideeris vanema positsioonile. Kaaslane, kes samuti ajaloos kohal viibis, palus kandidaadil kirjutada funktsioon, mis teeks HTTP päringu ja probleemide korral prooviks mitu korda uuesti.

Ta kirjutas koodi kohe tahvlile, seetõttu oleks olnud piisav joonistada midagi umbkaudu. Kui ta oleks lihtsalt näidanud, et mõistab hästi, mille poolest tegu, oleksime rahul olnud. Kuid kahjuks tal ei õnnestunud leida head lahendust. Siis, olles seda närvilisusega ette heitnud, otsustasime veidi ülesannet lihtsustada ja palusime tal muuta tagasisidefunktsioon promisse kasutavaks funktsiooniks.

Kahjuks. Jah, oli ilmne, et selline kood oli talle varem tuntud. Ta teadis üldiselt, kuidas see kõik toimib. Meile oleks piisanud lahenduse visandist, mis näitas arusaamist kontseptsioonist. Kuid kood, mille kandidaat tahvlile kirjutas, oli täielik mõttetuseks. Tal oli väga udune arusaam sellest, mis on JavaScriptis promissid ning ta ei osanud hästi selgitada, miks need vajalikud on. Junior arendaja puhul oleks see veel aktsepteeritav, kuid vanema positsioonile ta ei sobinud. Kuidas suudaks see arendaja lahendada vigu keerulises promisside ahelas ja selgitada teistele, mida täpselt ta tegi?

Arendajad peavad valmis koodi enesestmõistetavaks.

Arendusprotsessis puutume pidevalt kokku korduvate materjalidega. Me jagame koodifragmente, et ei peaks neid iga kord uuesti kirjutama. Seega, keskendudes kõikidele põhiosadele, vaatame valmis koodi, millega töötame, kui midagi enesestmõistetavat – me lihtsalt eeldame, et see töötab nagu peab.

Ja tavaliselt see tõepoolest töötab, kuid kui tekivad probleemid, tasub aru saada selle mehhanismist üle mõistmise.

Nii arvas meie kandidaat vanema arendaja positsioonile, et promise objektid on enesestmõistetavad. Tõenäoliselt oskas ta ette kujutada, kuidas nendega hallata, kui need ilmuvad kuskil väliskoodis, kuid ta ei mõistnud üldpõhimõtet ja ei suutnud seda ise intervjuul korrata. Võib-olla oli ta mingit fragmenti meelde jätnud – see pole sugugi keeruline:

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

Mina ka tegin – me kõik oleme tõenäoliselt kunagi nii teinud. Lihtsalt õppisime koodi osa peast, et hiljem seda töös kasutada, omamata üldiselt aimu, kuidas kõik tegelikult töötab. Kuid kui arendaja oleks tõeliselt mõistnud kontseptsiooni, ei oleks tal olnud midagi meelde jätta – ta oleks lihtsalt teadnud, kuidas seda teha, ja oleks muretult kõik vajaliku koodis taastanud.

Pöörduge allikate poole

2012. aastal, mil esimesed front-end raamistikud ei olnud veel populaarsust kogunud, valitses maailmas jQuery ja ma lugesin raamatut Secrets of the JavaScript Ninja, mille autoriks oli John Resig, jQuery looja.

Raamat õpetab lugema, kuidas luua oma jQuery nullist ja annab ainulaadse võimaluse tutvuda mõtlemise käiguga, mis viis raamatukogu loomisele. Viimastel aastatel on jQuery kaotanud oma endise populaarsuse, kuid ma soovitan raamatut siiski väga. Mis mind enim veretavalt üllatas – oli püsiv tunne, et oleksin võinud ise sellele järeldusele tulla. Autor kirjeldatud sammud tundusid nii loogilised ja arusaadavad, et mul oli tõsiselt tunne, nagu saaksin kergesti jQuery luua, kui vaid asjaga pihta hakkaksin.

Muidugi, reaalsuses ma ei oleks midagi sellist suurt osanud – oleksin arvanud, et see on ületamatult keeruline. Omandatud lahendused tunduksid mulle liiga lihtsate ja naiivsetena, et töötada, ja ma oleksin käed alla lasknud. Ma oleksin pidanud jQuery'd iseenesestmõistetavaks asjaks, mille korrektsesse toimimisse tuleb lihtsalt pimesi uskuda. Edasi ei oleks ma ilmselt raisanud aega, et läheneda selle raamatukogu mehhanikale, vaid oleksin lihtsalt kasutanud seda musta kasti moodi.

Kuid see raamat tegi minust teise inimese. Hakkasin süvenema lähtekoodi ja avastasin, et paljude lahenduste rakendamine on tegelikult väga transparantne, isegi ilmne. Ei, muidugi, ise sarnasele tasemele jõudmine on juba hoopis teine lugu. Kuid just teiste koodi uurimine ja juba olemasolevate lahenduste taastamine aitab meil midagi uut välja mõelda.

Inspireerige end ja märkige mustreid, mis teid arendajana muudavad. Te avastate, et see suurepärane teekogu, mida te pidevalt kasutate ja milles te olete harjunud mõtlema kui maagilises artefaktis, ei toimi mitte maagia, vaid lihtsalt lahendab probleemi nutikalt ja lakooniliselt.

Mõnikord tuleb koodiga vaeva näha, liigendades seda samm-sammult, kuid just nii, edasi liikudes väikeste järkjärgsete sammudega, suudate te autori teed lahenduse leidmisel jäljendada. See võimaldab teil sügavamalt süveneda koodikirjutamise protsessi ja suurendab teie enesekindlust oma lahenduste otsimisel.

Kui ma alles hakkasin promesse kasutama, tundus, et see on puhas maagia. Seejärel sain ma teada, et nende aluseks on samad tagasisidekutsed, ja minu arendaja maailm pöördus pea peale. See tähendab, et muster, mille eesmärk on vabastada meid tagasisidekutsest, rakendub ise tagasisidekutsede abil?!

See aitas mul vaadata asju teise nurga alt ja mõista, et minu ees ei ole mõningaid arusaamatuid kooditükke, mille äärmiselt keerulist olemust ma kunagi ei mõista. Need on lihtsalt mustrid, milles on lihtne orienteeruda, kui vaid on piisavalt uudishimu ja süvenemist. Just niimoodi õpetavad inimesed end programmeerima ja kasvavad arendajatena.

Leiutage see ratta uuesti

Seega leiutage rattaid julgelt uuesti: kirjutage ise kood andmete sidumiseks, looge kodune promiss või isegi tehke oma kätega lahendus olekute haldamiseks.
Pole tähtis, et keegi nendele kunagi ei kasuta – oluline on, et nüüd oskate te seda. Ja kui teil on hiljem võimalus neid saavutusi oma projektides kasutada, siis on see tõeliselt suurepärane. Saate neid arendada ja õppida veel rohkem.

Siin ei ole mõte saata oma koodi tootmisse, vaid õppida midagi uut. Omakäeliselt olemasoleva lahenduse rakendamine on suurepärane viis õppida parimatelt arendajatelt ja selle kaudu oma oskusi arendada.

Allikas: habr.com