Nedávno som mal pohovor s JavaScript vývojárom, ktorý sa uchádzal o pozíciu seniora. Kolega, ktorý bol tiež prítomný na pohovore, požiadal kandidáta, aby napísal funkciu, ktorá vykonáva HTTP požiadavku a v prípade zlyhania ju zopakuje niekoľkokrát.
Písal kód priamo na tabuli, takže stačilo zobraziť niečo približné. Keby aspoň ukázal, že dobre rozumie podstate problému, boli by sme úplne spokojní. Ale, žiaľ, nenašiel úspešné riešenie. Potom sme sa, odvádzajúc to na nervozitu, rozhodli trošku uľahčiť úlohu a požiadali sme ho, aby premenil funkciu s návratovými užívateľskými funkciami na funkciu postavenú na promisoch.
Ale žiaľ. Bolo zjavné, že sa s takýmto kódom už predtým stretol. Všeobecne vedel, ako to funguje. Stačil by nám nákres riešenia, ktorý by demonštroval pochopenie konceptu. Avšak kód, ktorý kandidát napísal na tabuli, bol úplne nezmyselný. Mal veľmi neurčitú predstavu o tom, čo sú promisy v JavaScripte a nedokázal poriadne vysvetliť, prečo sú potrebné. Pre juniora by to bolo ešte ospravedlniteľné, ale na pozíciu seniora to rozhodne nestačilo. Ako by tento vývojár dokázal odstrániť chyby v komplikovanom reťazci s promisiami a vysvetliť ostatným, čo presne urobil?
Vývojári považujú hotový kód za samozrejmý.
Počas vývoja sa neustále stretávame s opakovateľnými materiálmi. Prenášame útržky kódu, aby sme sa nemuseli zakaždým znova zaoberať ich písaním. Sústredíme sa teda na kľúčové časti a na hotový kód sa pozeráme ako na niečo samozrejmé – jednoducho predpokladáme, že v ňom všetko funguje tak, ako má.
A zvyčajne to naozaj funguje, ale keď nastanú ťažkosti, pochopenie jeho mechaniky sa viac než vyplatí.
Takže náš kandidát na pozíciu senior vývojára považoval objekty promise za samozrejmé. Určite mal predstavu, ako s nimi zaobchádzať, keď sa objavujú niekde v cudzom kóde, ale celkový princíp nechápal a nedokázal ho sám zopakovať na pohovore. Možno si zapamätal útržok naspamäť – nie je to až také ťažké:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Aj ja som to robil – pravdepodobne sme to všetci niekedy robili. Jednoducho sme sa naučili kúsok kódu, aby sme ho neskôr mohli použiť v praxi, pričom sme mali len veľmi všeobecnú predstavu o tom, ako to všetko funguje. Ale keby vývojár skutočne chápal koncept, nemusel by si nič zapamätať – jednoducho by vedel, ako to urobiť, a bez námahy by reprodukoval všetko potrebné v kóde.
Obráťte sa na zdroje
V roku 2012, keď ešte nepanovalo dominovanie frontendových rámcov, svet ovládal jQuery a ja som čítal knihu , jej autorom bol John Resig, tvorca jQuery.
Kniha učí čitateľa, ako vytvoriť vlastné jQuery od základov a poskytuje jedinečnú príležitosť priblížiť sa k myšlienkovému procesu, ktorý viedol k vytvoreniu knižnice. V posledných rokoch jQuery stratilo svoju bývalú popularitu, ale knihu aj tak veľmi odporúčam. Najviac ma na nej prekvapilo pretrvávajúce pocity, že som to všetko mohol vymyslieť aj sám. Kroky, ktoré autor popisoval, sa zdali tak logické, tak zrozumiteľné, že som si vážne začal myslieť, že by som mohol bez problémov vytvoriť jQuery, ak by som sa len odhodlal.
Samozrejme, v skutočnosti by som nič podobné nedokázal – rozhodol by som sa, že je to nezvládnuteľne ťažké. Vlastné riešenia by sa mi zdali príliš jednoduché a naivné na to, aby fungovali, a vzdal by som to. jQuery by som považoval za niečo samozrejmé, v správnu funkciu ktorého by som musel jednoducho slepo veriť. Neskôr by som pravdepodobne nestrácal čas tým, aby som prenikal do mechanizmu tejto knižnice, a jednoducho by som ju používal ako nejakú čiernu skrinku.
Ale zoznámenie s touto knihou ma zmenilo. Začal som sa zaoberať zdrojovým kódom a zistil som, že implementácia mnohých riešení je v skutočnosti veľmi priehľadná, ba dokonca očividná. Nie, samozrejme, vymyslieť si niečo podobné – to je už iný príbeh. Ale práve štúdium cudzích kódov a reprodukcia už existujúcich riešení nám pomáha prísť na niečo vlastné.
Inšpirácia, ktorú načerpáte, a vzory, ktoré začnete zachytávať, vás zmenia ako vývojára. Zistíte, že tá úžasná knižnica, ktorú neustále používate a o ktorej ste si zvykli myslieť, že je magickým artefaktom, nefunguje len na základe magie, ale jednoducho efektívne rieši problém.
Niekedy sa budete musieť s kódom trápiť, rozoberať ho krok za krokom, ale práve takto, postupne po malých krokoch, budete môcť zopakovať cestu autora k riešeniu. To vám umožní hlbšie sa ponoriť do procesu písania kódu a dodá vám viac sebavedomia pri hľadaní vlastných riešení.
Keď som začal pracovať s prísľubmi, zdalo sa mi to ako číra mágia. Potom som sa dozvedel, že na ich základe sú rovnaké spätné volania, a môj programátorský svet sa prevrátil. Teda vzor, ktorého cieľom je zbaviť nás spätných volaní, sa sám realizuje pomocou spätných volaní?!
To mi pomohlo nazerať na veci inými očami a uvedomiť si, že predo mnou nie sú žiadne ťažké úseky kódu, ktorých zložitostiam sa nikdy nebudem schopný prispôsobiť. Sú to len vzory, s ktorými sa dá bez problémov vyrovnať, ak máte dostatočnú zvedavosť a hĺbku ponorenia. Takto sa ľudia učia programovať a rastú ako vývojári.
Znovu vynálezte toto koleso
Tak sa nebojte vynájsť kolesá: sami napíšte kód na prepojenie údajov, vytvorte domáci prísľub alebo si dokonca vyrobte riešenie na správu stavov.
Nezáleží na tom, že to nikto nikdy nebude používať – teraz to už viete. A ak neskôr dostanete možnosť použiť takéto výstupy vo vlastných projektoch, bude to úplne skvelé. Môžete ich rozvíjať a naučíte sa niečo nové.
Zmysel spočíva v tom, že neide o to, aby ste poslali svoj kód do produkcie, ale o to, aby ste sa naučili niečo nové. Samostatne písať implementáciu už existujúceho riešenia je skvelý spôsob, ako sa učiť od najlepších programátorov a tým zdokonaľovať svoje zručnosti.
Zdroj: habr.com
