Minule som robil rozhovor s vývojárom JavaScriptu, ktorý sa uchádzal o vedúcu pozíciu. Kolega, ktorý bol tiež prítomný na pohovore, požiadal kandidáta, aby napísal funkciu, ktorá vykoná HTTP požiadavku a v prípade neúspešnosti to skúsi niekoľkokrát.
Kód napísal priamo na tabuľu, takže by stačilo nakresliť niečo približné. Keby jednoducho ukázal, že dobre rozumie, o čo ide, boli by sme celkom spokojní. Žiaľ, nepodarilo sa mu nájsť úspešné riešenie. Potom sme sa s nadšením rozhodli túto úlohu trochu uľahčiť a požiadali sme ho, aby premenil funkciu so spätnými volaniami na funkciu postavenú na sľuboch.
Ale žiaľ. Áno, bolo zrejmé, že sa s takýmto kódom už stretol. Vo všeobecnosti vedel, ako tam všetko funguje. Všetko, čo potrebujeme, je náčrt riešenia, ktorý demonštruje pochopenie konceptu. Kód, ktorý kandidát napísal na tabuľu, bol však úplný nezmysel. Mal veľmi nejasnú predstavu o tom, aké sľuby sú v JavaScripte, a nedokázal skutočne vysvetliť, prečo sú potrebné. Pre juniora by sa to dalo odpustiť, ale na pozíciu seniora sa už nehodil. Ako by tento vývojár mohol opraviť chyby v zložitom reťazci sľubov a vysvetliť ostatným, čo presne urobil?
Vývojári považujú hotový kód za samozrejmosť
Počas procesu vývoja sa neustále stretávame s reprodukovateľnými materiálmi. Prenášame fragmenty kódu, aby sme ich nemuseli zakaždým prepisovať. V súlade s tým, keď sústredíme všetku svoju pozornosť na kľúčové časti, pozeráme sa na hotový kód, s ktorým pracujeme, ako na niečo samozrejmé – jednoducho predpokladáme, že všetko bude fungovať tak, ako má.
A zvyčajne to funguje, ale keď sú veci zložité, porozumieť mechanike sa viac ako vypláca.
Náš kandidát na pozíciu senior developer teda považoval sľubované objekty za samozrejmosť. Pravdepodobne mal predstavu, ako sa s nimi vysporiadať, keď sa vyskytnú niekde v cudzom kóde, ale nerozumel všeobecnému princípu a sám to počas rozhovoru nedokázal zopakovať. Možno si pamätal fragment naspamäť - nie je to také ťažké:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Urobil som to aj ja – a už sme to niekedy asi urobili všetci. Jednoducho si zapamätali kúsok kódu, aby ho mohli neskôr použiť vo svojej práci, pričom mali len všeobecnú predstavu o tom, ako tam všetko funguje. Ak by však vývojár konceptu skutočne rozumel, nemusel by si nič pamätať – jednoducho by vedel, ako na to, a všetko, čo potrebuje, by ľahko reprodukoval v kóde.
Vráťte sa ku koreňom
V roku 2012, keď ešte nebola stanovená dominancia front-end frameworkov, jQuery vládlo svetu a ja som čítal knihu , ktorého autorom je John Resig, tvorca jQuery.
Kniha učí čitateľa, ako si vytvoriť svoj vlastný jQuery od začiatku, a poskytuje jedinečný pohľad na myšlienkový proces, ktorý viedol k vytvoreniu knižnice. V posledných rokoch stratil jQuery svoju niekdajšiu popularitu, no aj tak knihu vrelo odporúčam. Najviac ma na nej zarazil ten pretrvávajúci pocit, že som si toto všetko mohol myslieť aj ja. Kroky, ktoré autor opísal, sa mi zdali tak logické, také jasné, že som si vážne začal myslieť, že by som mohol ľahko vytvoriť jQuery, keby som sa do toho pustil.
Samozrejme, v skutočnosti by som nič také nedokázala – usúdila by som, že je to neznesiteľne ťažké. Moje vlastné riešenia by sa mi zdali príliš jednoduché a naivné na to, aby fungovali, a ja by som to vzdal. jQuery by som zaradil medzi samozrejmé veci, v správne fungovanie ktorých stačí slepo veriť. Následne by som len ťažko strácal čas ponorením sa do mechaniky tejto knižnice, ale jednoducho by som ju použil ako akúsi čiernu skrinku.
Ale čítanie tejto knihy zo mňa urobilo iného človeka. Začal som čítať zdrojový kód a zistil som, že implementácia mnohých riešení bola v skutočnosti veľmi transparentná, ba priam očividná. Nie, samozrejme, vymyslieť niečo také na vlastnú päsť je iný príbeh. Ale je to štúdium kódu iných ľudí a reprodukovanie existujúcich riešení, čo nám pomáha prísť s niečím vlastným.
Inšpirácia, ktorú získate, a vzory, ktoré si začnete všímať, vás ako vývojára zmenia. Zistíte, že tá nádherná knižnica, ktorú neustále používate a ktorú ste zvyknutí považovať za magický artefakt, na mágiu vôbec nefunguje, ale jednoducho lakonicky a vynaliezavo rieši problém.
Niekedy sa budete musieť ponoriť do kódu a analyzovať ho krok za krokom, ale takto môžete v malých, konzistentných krokoch zopakovať cestu autora k riešeniu. To vám umožní ponoriť sa hlbšie do procesu kódovania a poskytne vám väčšiu istotu pri vymýšľaní vlastných riešení.
Keď som prvýkrát začal pracovať so sľubmi, zdalo sa mi to ako čistá mágia. Potom som zistil, že sú založené na rovnakých spätných volaniach a môj programátorský svet sa obrátil hore nohami. Takže vzorec, ktorého účelom je zachrániť nás pred spätnými volaniami, je sám implementovaný pomocou spätných volaní?!
To mi pomohlo pozrieť sa na vec inými očami a uvedomiť si, že toto nie je nejaký nezrozumiteľný kúsok kódu, ktorý mám pred sebou, ktorého neúmernú zložitosť nikdy v živote nepochopím. Sú to len vzory, ktoré sa dajú bez problémov pochopiť s patričnou zvedavosťou a hlbokým ponorením. Takto sa ľudia učia kódovať a rastú ako vývojári.
Objavte znovu toto koleso
Takže pokračujte a objavte kolesá: napíšte svoj vlastný kód viazania údajov, vytvorte domáci prísľub alebo dokonca vytvorte svoje vlastné riešenie správy štátu.
Nezáleží na tom, že toto všetko nikto nikdy nepoužije – ale teraz už viete, ako na to. A ak máte možnosť následne použiť takýto vývoj vo svojich vlastných projektoch, potom je to vo všeobecnosti skvelé. Budete ich môcť rozvíjať a naučiť sa niečo iné.
Zmyslom tu nie je poslať svoj kód do výroby, ale naučiť sa niečo nové. Písanie vlastnej implementácie existujúceho riešenia je skvelý spôsob, ako sa učiť od najlepších programátorov a zdokonaľovať si tak svoje zručnosti.
Zdroj: hab.com