Onehdy jsem dělal rozhovor s vývojářem JavaScriptu, který se ucházel o vedoucí pozici. Kolega, který byl také přítomen pohovoru, požádal kandidáta, aby napsal funkci, která vytvoří HTTP požadavek a v případě neúspěšnosti to několikrát zopakuje.
Kód napsal přímo na tabuli, takže by stačilo nakreslit něco přibližného. Kdyby prostě ukázal, že dobře rozumí, o co jde, byli bychom docela spokojeni. Ale bohužel se mu nepodařilo najít úspěšné řešení. Pak jsme se s nadšením rozhodli úkol trochu usnadnit a požádali jsme ho, aby přeměnil funkci se zpětnými voláními na funkci postavenou na slibech.
Ale bohužel. Ano, bylo zřejmé, že se s takovým kódem už setkal. Věděl obecně, jak tam všechno funguje. Vše, co potřebujeme, je náčrt řešení, který demonstruje pochopení konceptu. Ovšem kód, který kandidát napsal na tabuli, byl úplný nesmysl. Měl velmi mlhavou představu o tom, jaké sliby jsou v JavaScriptu, a nedokázal skutečně vysvětlit, proč jsou potřebné. U juniora by se to dalo odpustit, ale na pozici seniora se už nehodil. Jak by tento vývojář mohl opravit chyby ve složitém řetězci slibů a vysvětlit ostatním, co přesně udělal?
Vývojáři považují hotový kód za samozřejmý
Během procesu vývoje se neustále setkáváme s reprodukovatelnými materiály. Přenášíme fragmenty kódu, abychom je nemuseli pokaždé přepisovat. Soustředíme-li veškerou pozornost na klíčové části, díváme se na hotový kód, se kterým pracujeme, jako na něco samozřejmého – prostě předpokládáme, že vše bude fungovat, jak má.
A obvykle to funguje, ale když jsou věci zapeklité, pochopení mechaniky se více než vyplatí.
Náš kandidát na pozici senior developer tak považoval příslibové objekty za samozřejmost. Pravděpodobně měl představu, jak se s nimi vypořádat, když se vyskytnou někde v cizím kódu, ale nerozuměl obecnému principu a sám to během rozhovoru nedokázal zopakovat. Možná si ten fragment pamatoval zpaměti - není to tak těžké:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Udělal jsem to taky – a asi jsme to někdy udělali všichni. Jednoduše si zapamatovali kus kódu, aby ho mohli později použít ve své práci, přičemž měli pouze obecnou představu o tom, jak tam všechno funguje. Pokud by ale vývojář konceptu skutečně rozuměl, nemusel by si nic pamatovat – jednoduše by věděl, jak na to, a vše potřebné by snadno reprodukoval v kódu.
Vraťte se ke kořenům
V roce 2012, kdy dominance front-end frameworků ještě nebyla stanovena, jQuery vládlo světu a já četl knihu , jehož autorem je John Resig, tvůrce jQuery.
Kniha učí čtenáře, jak vytvořit vlastní jQuery od nuly, a poskytuje jedinečný vhled do myšlenkového procesu, který vedl k vytvoření knihovny. V posledních letech jQuery ztratil na své dřívější oblibě, ale i tak knihu vřele doporučuji. Nejvíc mě na ní zarazil ten přetrvávající pocit, že jsem si tohle všechno mohl myslet sám. Kroky, které autor popsal, se zdály tak logické, tak jasné, že jsem vážně začal přemýšlet o tom, že bych mohl snadno vytvořit jQuery, kdybych se do toho pustil.
Samozřejmě, ve skutečnosti bych nic takového nedokázal – usoudil bych, že je to neúnosně těžké. Moje vlastní řešení by mi připadalo příliš jednoduché a naivní na to, aby fungovalo, a já bych to vzdal. jQuery bych zařadil mezi samozřejmé věci, v jejichž správné fungování stačí slepě věřit. Následně bych stěží ztrácel čas ponořením se do mechaniky této knihovny, ale jednoduše bych ji použil jako jakousi černou skříňku.
Ale čtení této knihy ze mě udělalo jiného člověka. Začal jsem číst zdrojový kód a zjistil jsem, že implementace mnoha řešení byla ve skutečnosti velmi transparentní, až zřejmá. Ne, samozřejmě, vymyslet něco takového samostatně, to je jiný příběh. Ale je to studium kódu jiných lidí a reprodukování existujících řešení, které nám pomáhá přijít s něčím vlastním.
Inspirace, kterou získáte, a vzory, kterých si začnete všímat, vás jako vývojáře změní. Zjistíte, že ta nádherná knihovna, kterou neustále používáte a kterou jste zvyklí považovat za magický artefakt, na magii vůbec nefunguje, ale jednoduše lakonicky a vynalézavě řeší problém.
Někdy budete muset kód prozkoumat a analyzovat jej krok za krokem, ale takto můžete postupováním v malých, konzistentních krocích zopakovat cestu autora k řešení. To vám umožní ponořit se hlouběji do procesu kódování a poskytne vám větší jistotu při vymýšlení vlastních řešení.
Když jsem poprvé začal pracovat se sliby, připadalo mi to jako čistá magie. Pak jsem zjistil, že jsou založeny na stejných zpětných voláních a můj programovací svět se obrátil vzhůru nohama. Takže vzorec, jehož účelem je zachránit nás před zpětnými voláními, je sám implementován pomocí zpětných volání?!
To mi pomohlo podívat se na věc jinýma očima a uvědomit si, že to není nějaký nejasný kód přede mnou, jehož neúnosnou složitost nikdy v životě nepochopím. Jsou to jen vzory, které lze bez problémů pochopit s patřičnou zvědavostí a hlubokým ponořením. Takto se lidé učí kódovat a rostou jako vývojáři.
Objevte znovu toto kolo
Takže pokračujte a znovu vynalézejte kola: napište svůj vlastní kód datové vazby, vytvořte domácí slib nebo dokonce vytvořte své vlastní řešení správy státu.
Nezáleží na tom, že tohle všechno nikdo nikdy nepoužije – ale teď už víte, jak na to. A pokud máte možnost následně použít takový vývoj ve svých vlastních projektech, pak je to obecně skvělé. Budete je moci rozvíjet a naučit se něco jiného.
Tady nejde o to poslat svůj kód do výroby, ale naučit se něco nového. Psaní vlastní implementace stávajícího řešení je skvělý způsob, jak se učit od nejlepších programátorů a zdokonalovat tak své dovednosti.
Zdroj: www.habr.com