Nedávno jsem vedl pohovor s vývojářem JavaScriptu, který se ucházel o pozici seniora. Kolega, který se také zúčastnil pohovoru, požádal kandidáta, aby napsal funkci, která provede HTTP požadavek, a v případě neúspěchu se pokusí znovu několikrát.
Kód psal přímo na tabuli, takže stačilo nakreslit něco přiblížného. Kdyby pouze ukázal, že dobře rozumí podstatě věci, byli bychom spokojeni. Bohužel se mu však nedařilo najít uspokojivé řešení. Poté jsme, přičítaje to nervozitě, rozhodli úkol trochu zjednodušit a požádali ho, aby přeměnil funkci s návratovými voláními na funkci postavenou na promisech.
Ale bohužel. Ano, bylo jasné, že s takovým kódem se už dříve setkal. V obecných rysech věděl, jak to funguje. Dostali bychom dostatečně rozpracované řešení, které by demonstrovalo porozumění konceptu. Nicméně kód, který kandidát psal na tabuli, byl naprostou nesmyslností. Měl naprosto nejasnou představu o tom, co jsou promises v JavaScriptu a nedokázal pořádně vysvětlit, k čemu jsou dobré. Pro juniory by to bylo ještě omluvitelné, ale na pozici seniora už to nestačilo. Jak by ten vývojář dokázal odstranit chyby ve složité řetězec s promises a vysvětlit ostatním, co vlastně udělal?
Vývojáři považují hotový kód za samozřejmost.
V procesu vývoje se neustále setkáváme s reprodukovatelnými materiály. Přenášíme úryvky kódu, abychom je nemuseli každou chvíli psát znovu. Soustředíme se tedy na klíčové části a na hotový kód, se kterým pracujeme, se díváme jako na něco samozřejmého – zkrátka předpokládáme, že v něm všechno bude fungovat tak, jak má.
A obvykle to skutečně funguje, ale když nastanou složitosti, porozumění jeho mechanice se více než vyplatí.
Tak náš kandidát na pozici vývojáře seniora považoval objekty promise za samozřejmé. Pravděpodobně si představoval, jak s nimi zacházet, když se někde ve cizím kódu objeví, ale celkový princip nechápal a nedokázal ho na pohovoru zopakovat. Možná si zapamatoval úryvek zpaměti – to není tak obtížné:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Také jsem to tak dělal – asi to dělal každý z nás někdy. Jen jsme se naučili kus kódu, abychom ho pak použili v práci, přičemž jsme si přitom představovali jen v hrubých rysech, jak to všechno funguje. Ale pokud by vývojář skutečně rozuměl konceptu, nemusel by si nic pamatovat – jednoduše by věděl, jak to udělat, a bez potíží by reprodukoval vše potřebné v kódu.
Oslovte zdroje
V roce 2012, kdy ještě nebyla dominace front-endových frameworků, vládl světem jQuery, a já jsem četl knihu , jejímž autorem byl John Resig, tvůrce jQuery.
Kniha učí čtenáře, jak vytvořit vlastní jQuery od nuly a dává jedinečnou příležitost přiblížit se myšlenkovému procesu, který vedl k vytvoření knihovny. V posledních letech jQuery ztratila svou dřívější popularitu, ale tuto knihu opravdu doporučuji. To, co mě na ní nejvíce překvapilo, bylo vytrvalé přesvědčení, že bych na to všechno mohl přijít sám. Kroky, které autor popisoval, se zdály být tak logické, tak srozumitelné, že jsem vážně začal věřit, že bych mohl snadno vytvořit jQuery, kdybych se do toho pustil.
Samozřejmě, ve skutečnosti bych nic podobného nezvládl – myslel bych si, že je to nesmírně těžké. Vlastní řešení by mi připadala příliš jednoduchá a naivní, aby fungovala, a vzdal bych to. Považoval bych jQuery za samozřejmou věc, v jejíž správnou funkčnost je třeba prostě slepě věřit. V budoucnu bych pravděpodobně netrávil čas tím, abych se zabýval mechanikou této knihovny, ale prostě bych ji používal jako nějakou černou skříňku.
Ale seznámení s touto knihou ze mě učinilo jiného člověka. Začal jsem se podrobně zabývat zdrojovým kódem a zjistil, že realizace mnoha řešení je ve skutečnosti velmi transparentní, dokonce zřejmá. Ne, samozřejmě, přijít na něco podobného – to už je z jiné opery. Ale právě studium cizího kódu a replikace již existujících řešení nám pomáhá vymýšlet něco vlastního.
Inspirace, kterou získáte, a vzory, které začnete vnímat, vás jako vývojáře změní. Zjistíte, že ta skvělá knihovna, kterou neustále používáte a kterou jste si přivykli považovat za magický artefakt, nefunguje na magii, ale prostě řeší problém stručně a vynalézavě.
Někdy budete muset na kódem pracovat a rozebrat ho krok za krokem, ale právě tak, když se posunujete malými souvislými kroky, budete moci zopakovat cestu autora k řešení. To vám umožní hluboce se ponořit do procesu psaní kódu a dá vám více sebedůvěry při nalezení vlastních řešení.
Když jsem poprvé začal pracovat s promisy, zdálo se mi, že je to čistá magie. Pak jsem se dozvěděl, že v jejich základu jsou stejné zpětné volání, a můj programátorský svět se změnil. To znamená, že vzor, jehož cílem je zbavit nás zpětných volání, se sám realizuje pomocí zpětných volání?!
Pomohlo mi to podívat se na věc jinýma očima a uvědomit si, že před sebou nemám nějaké složité kusy kódu, jejichž extrémní složitost nikdy v životě nepochopím. Jsou to prostě vzory, se kterými se dá bez problémů vyrovnat s dostatečnou zvědavostí a hloubkovým ponořením. Právě tak se lidé učí programovat a rostou jako vývojáři.
Znovu vynalezněte toto kolo
Nebojte se tedy znovu vynalézat kola: sami napište kód pro propojení dat, vytvořte domácí promisy nebo si dokonce vyrobte vlastní řešení pro správu stavů.
Není důležité, že tímto nikdo nikdy nebude používat – ale teď už to umíte. A pokud budete mít možnost následně použít takové výtvory ve vlastních projektech, bude to skvělé. Můžete je rozvíjet a naučíte se něco nového.
Smysl zde nespočívá v tom, poslat svůj kód do produkce, ale naučit se něco nového. Samostatné napsání implementace již existujícího řešení je skvělý způsob, jak se učit od nejlepších programátorů a zdokonalit své dovednosti.
Zdroj: habr.com
