На днях я праводзіў гутарку з распрацоўшчыкам на JavaScript, які прэтэндаваў на пазіцыю сеніёра. Калега, які таксама прысутнічаў на сумоўі, папрасіў кандыдата напісаць функцыю, якая б рабіла HTTP запыт і ў выпадку няўдачы паўтарала спробу некалькі разоў.
Ён пісаў код адразу на дошцы, таму дастаткова было б адлюстраваць нешта прыблізнае. Калі б ён проста паказаў, што добра разумее, у чым сутнасць справы, мы засталіся б цалкам задаволены. Але, на жаль, яму не ўдавалася знайсці ўдалага рашэння. Тады мы, спісаўшы гэта на хваляванне, вырашылі крыху палегчыць задачу і папрасілі яго зрабіць з функцыі са зваротнымі выклікамі функцыю, пабудаваную на промісах.
Але нажаль. Так, было відавочна, што падобны код сустракаўся яму раней. Ён у агульных рысах ведаў, як там усё працуе. Нам хапіла б накіда рашэння, які дэманстраваў бы разуменне канцэпта. Аднак код, які кандыдат пісаў на дошцы, быў поўнай бязглуздзіцай. У яго склалася вельмі туманнае ўяўленне аб тым, што такое промісы ў JavaScript і ён не мог толкам растлумачыць, навошта яны патрэбныя. Для джуніёра гэта было б яшчэ даравальна, але на пазіцыю сеніёра ўжо не цягнула. Як бы гэты распрацоўшчык здолеў ухіліць багі ў складаным ланцужку з промісамі і растлумачыць астатнім, што менавіта ён зрабіў?
Распрацоўнікі лічаць гатовы код самавідавочным
У працэсе распрацоўкі мы ўвесь час сутыкаемся з узнаўляльнымі матэрыяламі. Мы пераносім фрагменты кода, каб не прыходзілася кожны раз прапісваць іх нанова. Адпаведна, засяроджваючы ўсю ўвагу на ключавых частках, мы глядзім на гатовы код, з якім працуем, як на нешта відавочнае - мы проста мяркуем, што ў ім усё будзе працаваць як трэба.
І звычайна ён сапраўды працуе, але калі ўзнікаюць складанасці, разуменне яго механікі больш за акупляецца.
Так, наш кандыдат на пазіцыю распрацоўшчыка-сеніёра лічыў відавочнымі аб'екты promise. Ён, напэўна, уяўляў, як з імі спраўляцца, калі яны сустракаюцца недзе ў чужым кодзе, але агульны прынцып не разумеў і не змог сам яго паўтарыць на сумоўі. Магчыма, ён запомніў фрагмент на памяць - гэта не так ужо складана:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Я таксама так рабіў - ды ўсе мы, верагодна, калі-небудзь так рабілі. Проста завучвалі кавалак кода, каб потым выкарыстоўваць яго ў працы, пры гэтым толькі ў агульных рысах уяўляючы, як там усё ўладкована. Але калі б распрацоўшчык па-сапраўднаму разумеў канцэпт, запамінаць бы яму нічога не прыйшлося - ён проста ведаў бы, як гэта робіцца, і без працы аднавіў бы ўсё неабходнае ў кодзе.
Звяртайцеся да вытокаў
У 2012, калі яшчэ не ўсталявалася панаванне фрэймворкаў фронтэнда, светам кіраваў jQuery, і я чытаў кнігу , аўтарам якой быў Джон Рэзіг, стваральнік jQuery.
Кніга вучыць чытача, як стварыць уласную jQuery з нуля і дае ўнікальную магчымасць далучыцца да ходу думкі, які прывёў да стварэння бібліятэкі. У апошнія гады jQuery страціла сваю былую папулярнасць, але кнігу я ўсё ж такі вельмі рэкамендую. Што мяне больш за ўсё ў ёй ўразіла - гэта настойлівае пачуццё, што я мог бы перш за ўсё дадумацца і сам. Крокі, якія распісваў аўтар, здаваліся настолькі лагічнымі, настолькі зразумелымі, што мне ўсур'ёз стала здавацца, быццам і я мог бы проста стварыць jQuery, калі б толькі ўзяўся за справу.
Зразумела, у рэальнасці нічога падобнага я б не здужаў - вырашыў бы, што гэта непад'ёмна цяжка. Уласныя рашэнні падаліся б мне занадта простымі і наіўнымі, каб спрацаваць, і я б апусціў рукі. Я б аднёс jQuery да відавочных рэчаў, у карэктную працу якіх трэба проста слепа верыць. Пасля я наўрад ці пачаў бы марнаваць час на тое, каб унікаць у механіку гэтай бібліятэкі, а проста карыстаўся б ёй як нейкай чорнай скрыняй.
Але знаёмства з гэтай кнігай зрабіла мяне іншым чалавекам. Я стаў учытвацца ў зыходны код і выявіў, што рэалізацыя шматлікіх рашэнняў на справе вельмі празрыстая, нават відавочная. Не, вядома, самому дадумацца да падобнага - гэта ўжо з іншай оперы. Але менавіта вывучэнне чужога кода і ўзнаўленне ўжо існых рашэнняў і дапамагае нам прыдумляць нешта сваё.
Натхненне, якое вы атрымаеце, і патэрны, якія пачняце заўважаць, зменяць вас як распрацоўніка. Вы выявіце, што тая выдатная бібліятэка, якой вы ўвесь час карыстаецеся і аб якой абвыклі думаць як аб магічным артэфакце, працуе зусім не на магіі, а проста вырашае праблему лаканічна і знаходліва.
Часам над кодам прыйдзецца сядзець круком, разбіраючы яго крок за крокам, але менавіта так, прасоўваючыся дробнымі паслядоўнымі крокамі, вы зможаце паўтарыць шлях аўтара да рашэння. Гэта дазволіць вам глыбей акунуцца ў працэс напісання кода і дасць больш упэўненасці пры пошуку ўласных рашэнняў.
Калі я толькі пачаў працаваць з промісамі, мне здавалася, што гэта чыстая магія. Пасля я даведаўся, што ў іх аснове ляжаць тыя ж зваротныя выклікі, і мой праграмісцкі свет перавярнуўся. Гэта значыць патэрн, мэта якога - пазбавіць нас ад зваротных выклікаў, сам рэалізуецца пры дапамозе зваротных выклікаў?!
Гэта дапамагло мне зірнуць на справу іншымі вачыма і ўсвядоміць, што перада мной не нейкія мудрагелістыя кавалкі кода, залімітавую складанасць якія мне ніколі ў жыцці не спасцігнуць. Гэта ўсяго толькі патэрны, у якіх без праблем можна разабрацца пры належнай дапытлівасці і глыбокім апусканні. Менавіта так людзі вучацца праграмаваць і растуць як распрацоўшчыкі.
Вынайдзіце гэта кола нанова
Так што адважна перавынайце колы: самі прапішыце код для звязвання дадзеных, стварыце дамарослы проміс ці нават зрабіце сваімі рукамі рашэнне для кіравання станамі.
Не мае значэння, што ўсім гэтым ніхто ніколі не будзе карыстацца - затое вы зараз гэта ўмееце. А калі ў вас будзе магчымасць пасля выкарыстоўваць такія напрацоўкі ва ўласных праектах, то гэта ўвогуле выдатна. Вы зможаце іх развіваць і навучыцеся яшчэ чаму-небудзь.
Сэнс тут не ў тым, каб адправіць свой код у прадакшн, а ў тым, каб асвоіць нешта новае. Самастойна прапісваць рэалізацыю ўжо існуючага рашэння - выдатны спосаб вучыцца ў лепшых праграмістаў і тым навострываць сваё майстэрства.
Крыніца: habr.com