Um daginn tók ég viðtal við JavaScript forritara sem var að sækja um háttsetta stöðu. Samstarfsmaður, sem einnig var viðstaddur viðtalið, bað umsækjanda að skrifa aðgerð sem myndi gera HTTP beiðni og, ef það tekst ekki, reyna aftur nokkrum sinnum.
Hann skrifaði kóðann beint á töfluna, svo það væri nóg að teikna eitthvað áætlað. Ef hann hefði einfaldlega sýnt að hann skildi vel hvað málið snýst um, þá hefðum við verið nokkuð sáttir. En því miður tókst honum ekki að finna farsæla lausn. Þá ákváðum við, krítuðum það til spennu, að gera verkefnið aðeins auðveldara og báðum hann um að breyta aðgerð með svarhringingum í aðgerð sem byggð er á loforðum.
En því miður. Já, það var augljóst að hann hafði lent í slíkum kóða áður. Hann vissi almennt hvernig allt virkaði þar. Allt sem við þurfum er skissa af lausn sem sýnir skilning á hugmyndinni. Kóðinn sem frambjóðandinn skrifaði á töfluna var hins vegar algjört bull. Hann hafði mjög óljósa hugmynd um hvaða loforð væru í JavaScript og gat í raun ekki útskýrt hvers vegna þeirra var þörf. Fyrir yngri hefði þetta verið fyrirgefanlegt, en hann hentaði ekki lengur stöðu eldri. Hvernig myndi þessi verktaki geta lagað villur í flókinni keðju loforða og útskýrt fyrir öðrum hvað hann gerði nákvæmlega?
Hönnuðir telja tilbúinn kóða sjálfsagðan
Meðan á þróunarferlinu stendur lendum við stöðugt í endurgeranleg efni. Við flytjum kóðabrot svo að við þurfum ekki að endurskrifa þau í hvert sinn. Í samræmi við það, með því að beina allri athygli okkar að lykilhlutunum, lítum við á fullunna kóðann sem við vinnum með sem eitthvað sjálfsagt - við gerum einfaldlega ráð fyrir að allt muni virka eins og það ætti að gera.
Og venjulega virkar það, en þegar hlutirnir verða erfiðir borgar sig meira en að skilja vélfræðina.
Þannig taldi umsækjandi okkar um stöðu eldri framkvæmdaraðila loforðshluti sjálfsagða. Hann hafði líklega hugmynd um hvernig ætti að takast á við þau þegar þau koma fyrir einhvers staðar í kóða einhvers annars, en hann skildi ekki almennu meginregluna og gat ekki endurtekið það sjálfur í viðtalinu. Kannski mundi hann eftir brotinu utanað - það er ekki svo erfitt:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Ég gerði það líka - og við höfum líklega öll gert það á einhverjum tímapunkti. Þeir lögðu einfaldlega kóða á minnið svo þeir gætu síðar notað hann í vinnu sinni, á meðan þeir höfðu aðeins almenna hugmynd um hvernig allt virkaði þar. En ef verktaki skilur raunverulega hugmyndina, þyrfti hann ekki að muna neitt - hann myndi einfaldlega vita hvernig á að gera það og myndi auðveldlega endurskapa allt sem hann þyrfti í kóða.
Farðu aftur að rótunum
Árið 2012, þegar yfirráðum framenda ramma hafði ekki enn verið komið á, stjórnaði jQuery heiminum og ég las bókina , höfundur John Resig, skapara jQuery.
Bókin kennir lesandanum hvernig á að búa til sína eigin jQuery frá grunni og veitir einstaka innsýn í hugsunarferlið sem leiddi til stofnunar bókasafnsins. Undanfarin ár hefur jQuery tapað fyrri vinsældum sínum en ég mæli samt eindregið með bókinni. Það sem sló mig mest við hana var sú þráláta tilfinning að ég hefði getað hugsað um þetta allt sjálfur. Skrefin sem höfundur lýsti virtust svo rökrétt, svo skýr að ég fór alvarlega að hugsa um að ég gæti auðveldlega búið til jQuery ef ég færi bara að því.
Auðvitað hefði ég í raun og veru ekki getað gert neitt svona - ég hefði ákveðið að þetta væri óþolandi erfitt. Mínar eigin lausnir virðast of einfaldar og barnalegar til að virka og ég myndi gefast upp. Ég myndi flokka jQuery sem sjálfsagða hluti, í réttum rekstri sem þú þarft bara að trúa í blindni. Í framhaldinu myndi ég varla eyða tíma í að kafa ofan í vélfræði þessa bókasafns, heldur einfaldlega nota það sem eins konar svartan kassa.
En lestur þessarar bókar gerði mig að annarri manneskju. Ég fór að lesa frumkóðann og komst að því að innleiðing margra lausna var í raun mjög gagnsæ, jafnvel augljós. Nei, auðvitað, að hugsa um eitthvað svona upp á eigin spýtur er önnur saga. En það er að rannsaka kóða annarra og endurskapa núverandi lausnir sem hjálpa okkur að koma með eitthvað okkar eigin.
Innblásturinn sem þú færð og mynstrin sem þú byrjar að taka eftir mun breyta þér sem þróunaraðila. Þú munt komast að því að þetta dásamlega bókasafn sem þú notar stöðugt og sem þú ert vanur að hugsa um sem töfragrip virkar alls ekki á töfra, heldur leysir vandamálið einfaldlega á lakonulegan og útsjónarsaman hátt.
Stundum verður þú að fara yfir kóðann, greina hann skref fyrir skref, en þannig geturðu, með litlum, samkvæmum skrefum, endurtekið leið höfundar að lausninni. Þetta gerir þér kleift að kafa dýpra í kóðunarferlið og gefa þér meira sjálfstraust í að koma með þínar eigin lausnir.
Þegar ég byrjaði að vinna með loforðum fannst mér það hreinn galdur. Svo komst ég að því að þær byggðust á sömu símhringingunum og forritunarheimurinn minn fór á hvolf. Þannig að mynstrið, sem hefur þann tilgang að bjarga okkur frá svarhringingum, er sjálft útfært með því að nota svarhringingar?!
Þetta hjálpaði mér að horfa á málið með öðrum augum og átta mig á því að þetta er ekki einhver ómerkilegur kóði fyrir framan mig, sem ég mun aldrei átta mig á á ævinni hversu flókið það er. Þetta eru bara mynstur sem hægt er að skilja án vandræða með tilhlýðilegri forvitni og djúpri niðurdýfingu. Þetta er hvernig fólk lærir að kóða og vaxa sem forritarar.
Finndu upp þetta hjól aftur
Svo farðu á undan og finndu upp hjólin aftur: skrifaðu þinn eigin gagnabindingarkóða, búðu til heimatilbúið loforð eða búðu til þína eigin ríkisstjórnunarlausn.
Það skiptir ekki máli að enginn mun nokkurn tíma nota allt þetta - en nú veistu hvernig á að gera það. Og ef þú hefur tækifæri til að nota slíka þróun í eigin verkefnum, þá er það almennt frábært. Þú munt geta þróað þau og lært eitthvað annað.
Aðalatriðið hér er ekki að senda kóðann þinn í framleiðslu, heldur að læra eitthvað nýtt. Að skrifa eigin útfærslu á núverandi lausn er frábær leið til að læra af bestu forriturunum og bæta þannig færni þína.
Heimild: www.habr.com