Пре неки дан сам интервјуисао ЈаваСцрипт програмера који је конкурисао за вишу позицију. Колега, који је такође био присутан на интервјуу, замолио је кандидата да напише функцију која ће направити ХТТП захтев и, ако не успе, поновити неколико пута.
Шифру је написао директно на табли, па би било довољно нацртати нешто приближно. Да је једноставно показао да добро разуме о чему се ради, били бисмо сасвим задовољни. Али, нажалост, није успео да пронађе успешно решење. Онда смо, приписујући то узбуђењу, одлучили да мало олакшамо задатак и замолили смо га да претвори функцију са повратним позивима у функцију изграђену на обећањима.
Али авај. Да, било је очигледно да се и раније сусрео са таквим кодом. Он је уопштено знао како тамо све функционише. Све што нам треба је скица решења која показује разумевање концепта. Међутим, шифра коју је кандидат написао на табли је била потпуна глупост. Имао је веома нејасну представу о томе шта су обећања у ЈаваСцрипт-у и није могао да објасни зашто су она потребна. За јуниора би то било опростиво, али он више није одговарао позицији сениора. Како би овај програмер могао да поправи грешке у сложеном ланцу обећања и објасни другима шта је тачно урадио?
Програмери сматрају да је готов код очигледан
Током процеса развоја, стално се сусрећемо са поновљивим материјалима. Преносимо фрагменте кода тако да не морамо сваки пут да их поново пишемо. Сходно томе, фокусирајући сву нашу пажњу на кључне делове, на готов код са којим радимо гледамо као на нешто што је само по себи разумљиво – једноставно претпостављамо да ће све радити како треба.
И обично функционише, али када ствари постану незгодне, разумевање механике се више него исплати.
Тако је наш кандидат за позицију старијег програмера сматрао да су обећани објекти очигледни. Вероватно је имао идеју како да се носи са њима када се појаве негде у туђем коду, али није разумео општи принцип и није могао сам да га понови током интервјуа. Можда је запамтио фрагмент напамет - није тако тешко:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});И ја сам то урадио - и вероватно смо сви то урадили у неком тренутку. Једноставно су запамтили део кода како би га касније могли користити у свом раду, док су имали само општу представу о томе како све тамо функционише. Али ако би програмер заиста разумео концепт, не би морао ништа да памти – он би једноставно знао како то да уради и лако би репродуковао све што му је потребно у коду.
Врати се коренима
Године 2012, када доминација фронт-енд оквира још није била успостављена, јКуери је владао светом, а ја сам прочитао књигу , чији је аутор Џон Ресиг, творац јКуери-ја.
Књига учи читаоца како да креира сопствени јКуери од нуле и пружа јединствен увид у мисаони процес који је довео до стварања библиотеке. Последњих година, јКуери је изгубио своју некадашњу популарност, али и даље топло препоручујем књигу. Оно што ме је највише погодило код ње је упорно осећање да сам све ово могао и сам да смислим. Кораци које је аутор описао чинили су се тако логичним, толико јасним да сам озбиљно почео да размишљам да бих лако могао да креирам јКуери ако се само ухватим тога.
Наравно, у стварности не бих могао овако нешто - одлучио бих да је то неподношљиво тешко. Моја сопствена решења би изгледала превише једноставна и наивна да би функционисала, и одустао бих. Ја бих јКуери сврстао у саморазумљиве ствари у чије исправно функционисање треба само слепо веровати. Након тога, тешко да бих губио време упуштајући се у механику ове библиотеке, већ бих је једноставно користио као неку врсту црне кутије.
Али читање ове књиге учинило ме је другачијом особом. Почео сам да читам изворни код и открио да је имплементација многих решења у ствари била веома транспарентна, чак очигледна. Не, наравно, да сами смислите нешто овако је друга прича. Али проучавање кода других људи и репродуковање постојећих решења нам помаже да смислимо нешто своје.
Инспирација коју добијете и обрасци које почнете да примећујете промениће вас као програмера. Видећете да та дивна библиотека коју стално користите и коју сте навикли да сматрате магичним артефактом уопште не делује на магију, већ једноставно решава проблем лаконски и сналажљиво.
Понекад ћете морати да проучите код, анализирајући га корак по корак, али овако, крећући се малим, доследним корацима, можете поновити ауторов пут до решења. Ово ће вам омогућити да дубље зароните у процес кодирања и даће вам више самопоуздања у проналажењу сопствених решења.
Када сам тек почео да радим са обећањима, то ми се чинило као чиста магија. Онда сам сазнао да су засновани на истим повратним позивима и мој свет програмирања се окренуо наглавачке. Дакле, образац, чија је сврха да нас спаси од повратних позива, сам се имплементира помоћу повратних позива?!
То ми је помогло да сагледам ствар другим очима и схватим да то није неки замућени комад кода преда мном, чију превисоку сложеност никада у животу нећу схватити. Ово су само обрасци који се могу разумети без проблема уз дужну радозналост и дубоко урањање. Овако људи уче да кодирају и расту као програмери.
Поново измислите овај точак
Зато само напред и поново измислите точкове: напишите сопствени код за везивање података, креирајте домаће обећање или чак направите сопствено решење за управљање стањем.
Није важно што све ово нико никада неће користити - али сада знате како то да урадите. А ако имате прилику да касније користите такав развој у својим пројектима, онда је то генерално одлично. Моћи ћете да их развијете и научите нешто друго.
Поента овде није да пошаљете свој код у производњу, већ да научите нешто ново. Писање сопствене имплементације постојећег решења је одличан начин да учите од најбољих програмера и тако усавршите своје вештине.
Извор: ввв.хабр.цом