Онзи ден бях на интервю с разработчик на JavaScript, който кандидатстваше за старша позиция. Колега, който също присъства на интервюто, помоли кандидата да напише функция, която да направи HTTP заявка и в случай на неуспех да опита няколко пъти.
Той написа кода директно на дъската, така че ще бъде достатъчно да изобрази нещо приблизително. Ако той просто покаже, че разбира добре същността на въпроса, щяхме да сме доста доволни. Но, за съжаление, той не можа да намери добро решение. Тогава ние, като го отписахме като вълнение, решихме да направим задачата малко по-лесна и го помолихме да направи функция, изградена на обещания от функция с обратни извиквания.
Но уви. Да, очевидно беше, че е виждал подобен код и преди. Той знаеше в общи линии как работи всичко там. За нас ще бъде достатъчна скица на решението, което ще демонстрира разбиране на концепцията. Кодът, който кандидатът написал на бялата дъска обаче бил пълна глупост. Той имаше много неясна представа какво има обещания в JavaScript и не можеше да обясни защо са необходими. За младши това все още би било простимо, но позицията на старши вече не беше теглена. Как този разработчик би успял да поправи грешките в сложната обещаваща верига и да обясни на останалите какво точно е направил?
Разработчиците смятат завършения код за очевиден
По време на процеса на разработка непрекъснато се сблъскваме с възпроизводими материали. Преместваме кодовите фрагменти, така че да не се налага да ги пренаписваме всеки път. Съответно, съсредоточавайки цялото си внимание върху ключовите части, ние гледаме на готовия код, с който работим, като на нещо подразбиращо се – просто предполагаме, че всичко в него ще работи както трябва.
И обикновено работи, но когато нещата станат трудни, разбирането на неговата механика се отплаща повече.
Например, нашият кандидат за старши разработчик смята обещанията за очевидни. Вероятно си е представял как да се справи с тях, когато се появят някъде в кода на някой друг, но не е разбрал общия принцип и не е могъл да го повтори сам на интервюто. Може би той е запомнил фрагмента - не е толкова трудно:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});И аз съм го правил – да, вероятно всички сме го правили в даден момент. Те просто запомниха част от кода, за да могат по-късно да го използват в работата си, като само в общи линии си представят как работи всичко там. Но ако разработчикът наистина разбира концепцията, той няма да трябва да помни нищо - той просто ще знае как се прави и лесно ще възпроизведе всичко необходимо в кода.
Докоснете се до произхода
През 2012 г., преди доминирането на предните рамки, светът на jQuery управлява и аз четях книга от Джон Резиг, създател на jQuery.
Книгата учи читателя как да създаде свой собствен jQuery от нулата и предоставя уникална възможност да се включи в хода на мислите, довели до създаването на библиотеката. jQuery изпадна в немилост през последните години, но все още силно препоръчвам книгата. Това, което ме порази най-много в нея, беше нейното настойчиво усещане, че бих могъл да измисля всичко това сам. Стъпките, които описа авторът, изглеждаха толкова логични, толкова ясни, че наистина започна да ми се струва, че мога лесно да създам jQuery, ако просто се захвана с работата.
Разбира се, в действителност не бих овладял нищо подобно - щях да реша, че е непоносимо трудно. Моите собствени решения щяха да ми се сторят твърде прости и наивни, за да работят, и щях да се откажа. Бих класифицирал jQuery като самоочевидно нещо, в чиято правилна работа просто трябва сляпо да вярвате. Впоследствие едва ли бих прекарал време в ровене в механиката на тази библиотека, а просто бих я използвал като вид черна кутия.
Но прочитането на тази книга ме направи различен човек. Започнах да чета изходния код и открих, че внедряването на много решения всъщност е много прозрачно, дори очевидно. Не, разбира се, да измислиш нещо подобно е вече от друга опера. Но изучаването на кода на някой друг и възпроизвеждането на съществуващи решения ни помага да измислим нещо свое.
Вдъхновението, което получавате, и моделите, които започвате да забелязвате, ще ви променят като разработчик. Ще откриете, че прекрасната библиотека, която използвате през цялото време и смятате за магически артефакт, изобщо не работи върху магия, а просто решава проблема кратко и находчиво.
Понякога трябва да се впуснете в кода, като го разглобявате стъпка по стъпка, но ето как, движейки се на малки последователни стъпки, можете да повторите пътя на автора към решението. Това ще ви позволи да се потопите по-дълбоко в процеса на писане на код и ще ви даде повече увереност в намирането на ваши собствени решения.
Когато за първи път започнах да работя с обещания, мислех, че това е чиста магия. Тогава разбрах, че са базирани на едни и същи обратни извиквания и светът ми на програмиране се обърна с главата надолу. Тоест моделът, чиято цел е да ни спаси от обратни извиквания, сам по себе си се реализира с помощта на обратни извиквания?!
Това ми помогна да погледна на въпроса с други очи и да осъзная, че пред мен не стоят някакви сложни парчета код, трансцендентална сложност, които никога няма да разбера в живота си. Това са просто модели, които лесно могат да бъдат разбрани с необходимото любопитство и дълбоко потапяне. Ето как хората се учат да кодират и растат като разработчици.
Преоткрийте това колело
Така че не се колебайте да преоткриете колелото: напишете свой собствен код за обвързване на данни, създайте собствено обещание или дори направете свое собствено решение за управление на състоянието.
Няма значение, че никой никога няма да използва всичко това - но сега знаете как. И ако имате възможност впоследствие да използвате такива разработки в собствените си проекти, тогава това като цяло е чудесно. Можете да ги развиете и да научите нещо друго.
Въпросът тук не е да изпратите кода си в производство, а да научите нещо ново. Писането на ваша собствена реализация на съществуващо решение е чудесен начин да се учите от най-добрите програмисти и да усъвършенствате уменията си.
Източник: www.habr.com