Зошто е корисно повторно да се измислуваат тркала?

Зошто е корисно повторно да се измислуваат тркала?

Пред некој ден интервјуирав развивач на JavaScript кој аплицираше за висока позиција. Еден колега, кој исто така беше присутен на интервјуто, го замоли кандидатот да напише функција што ќе направи барање за HTTP и, доколку не успее, ќе се обиде повторно неколку пати.

Ја напиша шифрата директно на таблата, па би било доволно да нацрта нешто приближно. Едноставно да покажеше дека добро разбира што е работата, ќе бевме сосема задоволни. Но, за жал, тој не успеа да најде успешно решение. Тогаш ние, кревајќи ја до возбуда, решивме малку да ја олесниме задачата и го замоливме функцијата со повратни повици да ја претвори во функција изградена на ветувања.

Но за жал. Да, очигледно беше дека претходно се сретнал со таков код. Тој знаеше генерално како се работи таму. Сè што ни треба е скица на решение кое покажува разбирање на концептот. Но, шифрата што кандидатот ја напиша на таблата беше целосна глупост. Тој имаше многу нејасна идеја за тоа какви ветувања се во JavaScript и не можеше навистина да објасни зошто се потребни. За помладиот ова би можело да се прости, но повеќе не му одговараше на позицијата сениор. Како овој развивач би можел да ги поправи грешките во сложениот синџир на ветувања и да им објасни на другите што точно направил?

Програмерите сметаат дека готовиот код е очигледен

Во текот на процесот на развој, постојано се среќаваме со материјали кои можат да се репродуцираат. Ги пренесуваме фрагментите од кодот за да не мораме да ги препишуваме секој пат. Според тоа, со фокусирање на целото внимание на клучните делови, го гледаме готовиот код со кој работиме како нешто очигледно - едноставно претпоставуваме дека сè ќе функционира како што треба.

И обично тоа функционира, но кога работите стануваат незгодни, разбирањето на механиката повеќе отколку што се исплати.

Така, нашиот кандидат за позицијата постар програмер ги сметаше ветените објекти за очигледни. Веројатно имал идеја како да се справи со нив кога ќе се појават некаде во туѓ код, но не го разбирал општиот принцип и не можел да го повтори за време на интервјуто. Можеби тој се сети на фрагментот напамет - не е толку тешко:

return new Promise((resolve, reject) => {
  functionWithCallback((err, result) => {
   return err ? reject(err) : resolve(result);
  });
});

И јас го направив тоа - и веројатно сите сме го направиле во одреден момент. Тие едноставно запамтиле парче код за подоцна да го користат во нивната работа, а притоа да имаат само општа претстава за тоа како сè функционира таму. Но, доколку развивачот навистина го разбрал концептот, не би морал да запомни ништо - едноставно би знаел како да го направи тоа и лесно би репродуцирал сè што му треба во код.

Вратете се на корените

Во 2012 година, кога сè уште не беше воспоставена доминацијата на предните рамки, jQuery владееше со светот, а јас ја прочитав книгата Тајните на JavaScript Ninja, чиј автор е Џон Ресиг, креатор на jQuery.

Книгата го учи читателот како да креира сопствен jQuery од нула и дава уникатен увид во процесот на размислување што доведе до создавање на библиотеката. Во последниве години, jQuery ја изгуби својата поранешна популарност, но сепак силно ја препорачувам книгата. Она што најмногу ме погоди кај неа беше упорното чувство дека можев сам да размислувам за сето ова. Чекорите што ги опиша авторот ми изгледаа толку логични, толку јасни што сериозно почнав да мислам дека лесно би можел да создадам jQuery ако само се фатам за тоа.

Се разбира, во реалноста немаше да можам да направам ништо вакво - ќе решев дека е неподносливо тешко. Моите решенија би изгледале премногу едноставни и наивни за работа, и јас би се откажал. Јас би го класифицирал jQuery како саморазбирливи работи, во чие правилно функционирање треба само слепо да верувате. Последователно, тешко дека би губел време истражувајќи во механиката на оваа библиотека, туку едноставно би ја користел како еден вид црна кутија.

Но, читањето на оваа книга ме направи поинаква личност. Почнав да го читам изворниот код и открив дека имплементацијата на многу решенија е всушност многу транспарентна, дури и очигледна. Не, се разбира, да смислиш вакво нешто самостојно е друга приказна. Но, тоа е проучување на кодот на другите луѓе и репродукција на постоечки решенија што ни помага да дојдеме до нешто свое.

Инспирацијата што ја добивате и шаблоните што почнувате да ги забележувате ќе ве променат како развивач. Ќе откриете дека таа прекрасна библиотека што постојано ја користите и која сте навикнати да ја сметате за магичен артефакт воопшто не работи на магија, туку едноставно лаконски и снаодливо решава проблем.

Некогаш ќе треба да го навлезете кодот, анализирајќи го чекор по чекор, но вака, движејќи се во мали, конзистентни чекори, можете да го повторите патот на авторот до решението. Ова ќе ви овозможи да се нурнете подлабоко во процесот на кодирање и ќе ви даде поголема доверба во доаѓањето до сопствени решенија.

Кога првпат почнав да работам со ветувања, ми се чинеше како чиста магија. Потоа дознав дека тие се базирани на истите повратни повици и мојот програмски свет се преврте наопаку. Значи шаблонот чија цел е да не спаси од повратни повици, сам по себе се имплементира со помош на повратни повици?!

Ова ми помогна да ја погледнам работата со поинакви очи и да сфатам дека ова не е некој невнимателен дел од кодот пред мене, чијашто забранувачка сложеност никогаш нема да ја сфатам во мојот живот. Ова се само обрасци кои можат да се разберат без проблеми со должната љубопитност и длабоко потопување. Така луѓето учат да кодираат и растат како програмери.

Повторно измисли го ова тркало

Затоа, продолжете и повторно измислите ги тркалата: напишете ваш сопствен обврзувачки код за податоци, создадете домашно ветување или дури и направете сопствено решение за управување со државата.
Не е важно дека никој никогаш нема да го искористи сето ова - но сега знаете како да го направите тоа. И ако имате можност последователно да ги користите таквите случувања во вашите сопствени проекти, тогаш тоа е генерално одлично. Ќе можете да ги развиете и да научите нешто друго.

Поентата овде не е да го испратите вашиот код до производство, туку да научите нешто ново. Пишувањето сопствена имплементација на постоечко решение е одличен начин да научите од најдобрите програмери и на тој начин да ги усовршите своите вештини.

Извор: www.habr.com

Додадете коментар