HÀromdagen genomförde jag en intervju med en JavaScript-utvecklare som ansökte om en seniorposition. En kollega, som ocksÄ var nÀrvarande vid intervjun, bad kandidaten att skriva en funktion som skulle göra en HTTP-förfrÄgan och, om den misslyckades, försöka flera gÄnger.
Han skrev koden direkt pÄ tavlan, sÄ det skulle ha rÀckt med att skissa nÄgot ungefÀrligt. Om han bara hade visat att han förstod vad som var kÀrnan i uppgiften, skulle vi ha varit ganska nöjda. Men tyvÀrr lyckades han inte hitta en bra lösning. DÄ beslutade vi, med hÀnvisning till nervositet, att göra uppgiften lite enklare och bad honom att omvandla funktionen med callbacks till en funktion baserad pÄ promises.
Men tyvÀrr. Ja, det var uppenbart att han hade stött pÄ liknande kod tidigare. Han visste i stora drag hur allt fungerade dÀr. Det hade rÀckt med en skisslösning som visade förstÄelse för konceptet. Men koden som kandidaten skrev pÄ tavlan var fullstÀndig nonsens. Han hade en mycket vag uppfattning om vad promises Àr i JavaScript och han kunde inte riktigt förklara varför de behövs. För en junior hade detta varit mer förlÄtligt, men för en seniorposition rÀckte det inte till. Hur skulle denna utvecklare kunna fixa buggar i en komplex kedja av promises och förklara för andra vad han faktiskt gjorde?
Utvecklare anser att fÀrdig kod Àr sjÀlvklar.
Under utvecklingsprocessen stöter vi stĂ€ndigt pĂ„ Ă„teranvĂ€nda material. Vi kopierar kodfragment sĂ„ att vi inte behöver skriva dem frĂ„n grunden varje gĂ„ng. DĂ€rför, nĂ€r vi fokuserar all uppmĂ€rksamhet pĂ„ de viktigaste delarna, ser vi pĂ„ den fĂ€rdiga koden vi arbetar med som nĂ„got sjĂ€lvklart â vi förutsĂ€tter helt enkelt att det fungerar som det ska.
Och vanligtvis fungerar det verkligen, men nÀr problem uppstÄr lönar det sig mer Àn vÀl att förstÄ dess mekanik.
SĂ„ vĂ„r kandidat för seniorutvecklarpositionen ansĂ„g att promise-objekt var sjĂ€lvklara. Han kunde nog förestĂ€lla sig hur man hanterar dem nĂ€r de dyker upp nĂ„gon annanstans i andras kod, men han förstod inte den allmĂ€nna principen och kunde inte Ă„terge den vid intervjun. Kanske hade han memorerat ett fragment utantill â det Ă€r inte sĂ„ svĂ„rt:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Jag gjorde ocksĂ„ sĂ„ â och vi har nog alla gjort det nĂ„gon gĂ„ng. Vi lĂ€rde oss en bit kod utantill för att sedan anvĂ€nda den i vĂ„rt arbete, medan vi bara hade en allmĂ€n förstĂ„else för hur allt fungerade. Men om utvecklaren verkligen hade förstĂ„tt konceptet, skulle han inte behöva memorera nĂ„got â han skulle bara veta hur det görs och utan anstrĂ€ngning reproducera allt som behövs i koden.
GÄ tillbaka till kÀllorna
à r 2012, nÀr ramverken för frontend Ànnu inte hade tagit över, sÄ dominerade jQuery, och jag lÀste boken , skriven av John Resig, skaparen av jQuery.
Boken lÀr lÀsaren hur man skapar sitt eget jQuery frÄn grunden och ger en unik möjlighet att förstÄ tankesÀttet som ledde till skapandet av biblioteket. Under de senaste Ären har jQuery tappat sin tidigare popularitet, men jag rekommenderar ÀndÄ boken starkt. Det som imponerade mig mest var den ihÀrdiga kÀnslan av att jag ocksÄ skulle kunna ha kommit pÄ allt detta sjÀlv. Stegen som författaren beskrev verkade sÄ logiska och sÄ tydliga att jag uppriktigt började tro att jag skulle kunna skapa jQuery enkelt om jag bara satte igÄng.
SjĂ€lvklart skulle jag i verkligheten aldrig klara nĂ„got sĂ„dant â jag skulle tycka att det var alldeles för svĂ„rt. Mina egna lösningar skulle verka för enkla och naiva för att fungera, och jag skulle ha gett upp. Jag skulle ha sett jQuery som nĂ„got sjĂ€lvklart, dĂ€r man bara behövde tro blind pĂ„ att det fungerade. Senare skulle jag knappast ha lagt tid pĂ„ att förstĂ„ mekaniken bakom detta bibliotek och bara anvĂ€nt det som en sorts svart lĂ„da.
Men bekantskapen med denna bok gjorde mig till en annan person. Jag började lÀsa kÀllkoden noggrant och upptÀckte att implementeringen av mÄnga lösningar i sjÀlva verket Àr mycket tydlig, till och med uppenbar. Nej, att sjÀlv komma pÄ nÄgot sÄdant Àr en helt annan sak. Men just studiet av andras kod och reproduktionen av redan existerande lösningar hjÀlper oss att hitta pÄ nÄgot eget.
Inspiration that you will draw and patterns that you will start to notice will change you as a developer. You will discover that the wonderful library you constantly use and think of as a magical artifact operates not on magic, but simply solves problems concisely and resourcefully.
Sometimes you'll have to toil over the code, breaking it down step by step, but that's how you can echo the author's path to the solution through small, sequential steps. This will allow you to dive deeper into the coding process and build more confidence in finding your own solutions.
When I first started working with promises, it seemed to me like pure magic. Then I learned that they are based on the same callbacks, and my programming world turned upside down. So the pattern aimed at freeing us from callbacks is implemented with callbacks?!
This helped me look at things differently and realize that what I faced wasnât some incomprehensible pieces of code with an extreme level of complexity that I would never grasp in my life. They are just patterns that can be easily understood with curiosity and deep immersion. Thatâs how people learn to code and grow as developers.
Reinvent the wheel
So feel free to reinvent wheels: write your own code for data binding, create a homemade promise, or even build your own state management solution.
It doesn't matter that no one will ever use all of this â at least now you know how to do it. And if you have the chance to use such developments in your own projects later, thatâs even better. You will be able to expand them and learn something new.
The point here isn't to push your code to production, but to master something new. Implementing already existing solutions on your own is a great way to learn from the best programmers and refine your skills.
KĂ€lla: habr.com
