Ինչու՞ է օգտակար անիվները նորից հորինելը:

Օրերս ես հարցազրույց վերցրեցի 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-ն կդասակարգեի որպես ինքնին հասկանալի բաներ, որոնց ճիշտ աշխատանքին ուղղակի պետք է կուրորեն հավատալ։ Հետագայում ես դժվար թե ժամանակ վատնեմ՝ խորանալով այս գրադարանի մեխանիզմների մեջ, այլ պարզապես կօգտագործեի այն որպես մի տեսակ սև արկղ:

Բայց այս գիրքը կարդալն ինձ ուրիշ մարդ դարձրեց: Ես սկսեցի կարդալ սկզբնաղբյուրը և հայտնաբերեցի, որ շատ լուծումների իրականացումն իրականում շատ թափանցիկ էր, նույնիսկ ակնհայտ: Ոչ, իհարկե, ինքնուրույն նման բան մտածելն այլ պատմություն է: Բայց դա ուսումնասիրում է այլ մարդկանց ծածկագիրը և վերարտադրում առկա լուծումները, որոնք օգնում են մեզ գտնել մեր սեփականը:

Ձեր ձեռք բերած ոգեշնչումը և այն օրինաչափությունները, որոնք դուք սկսում եք նկատել, կփոխեն ձեզ որպես մշակողի: Դուք կգտնեք, որ այդ հրաշալի գրադարանը, որը դուք անընդհատ օգտագործում եք, և որը սովոր եք մտածել որպես կախարդական արտեֆակտ, ամենևին էլ չի աշխատում մոգության վրա, այլ պարզապես լուծում է խնդիրը լակոնիկորեն և հնարամտորեն:

Երբեմն ստիպված կլինեք ծակել ծածկագիրը՝ քայլ առ քայլ վերլուծելով այն, բայց այսպես, փոքր, հետևողական քայլերով շարժվելով, կարող եք կրկնել հեղինակի ուղին դեպի լուծում: Սա թույլ կտա ձեզ ավելի խորը սուզվել կոդավորման գործընթացի մեջ և ձեզ ավելի վստահություն կտա ձեր սեփական լուծումները գտնելու հարցում:

Երբ ես նոր սկսեցի աշխատել խոստումներով, ինձ թվում էր, թե դա մաքուր մոգություն է: Հետո ես պարզեցի, որ դրանք հիմնված են նույն զանգերի վրա, և իմ ծրագրավորման աշխարհը գլխիվայր շուռ եկավ։ Այսպիսով, օրինաչափությունը, որի նպատակը մեզ հետադարձ զանգերից փրկելն է, ինքնին իրականացվում է հետադարձ զանգերի միջոցով:

Սա օգնեց ինձ այլ աչքերով նայել խնդրին և հասկանալ, որ սա իմ առջև դրված ինչ-որ անհեթեթ կոդ չէ, որի արգելող բարդությունը ես երբեք չեմ հասկանա իմ կյանքում: Սրանք պարզապես օրինաչափություններ են, որոնք կարելի է հասկանալ առանց խնդիրների պատշաճ հետաքրքրասիրության և խորը ընկղմման միջոցով: Ահա թե ինչպես են մարդիկ սովորում կոդավորել և աճել որպես ծրագրավորողներ:

Նորից հայտնագործեք այս անիվը

Այսպիսով, առաջ գնացեք և նորից հայտնագործեք անիվները. գրեք ձեր սեփական տվյալների պարտադիր ծածկագիրը, ստեղծեք տնային խոստում կամ նույնիսկ պատրաստեք ձեր սեփական պետական ​​կառավարման լուծումը:
Կարևոր չէ, որ ոչ ոք երբեք չի օգտագործի այս ամենը, բայց հիմա դուք գիտեք, թե ինչպես դա անել: Եվ եթե դուք հնարավորություն ունեք հետագայում օգտագործելու նման զարգացումները ձեր սեփական նախագծերում, ապա դա ընդհանուր առմամբ հիանալի է: Դուք կկարողանաք զարգացնել դրանք և այլ բան սովորել:

Խնդիրն այստեղ ոչ թե ձեր կոդը արտադրություն ուղարկելն է, այլ նոր բան սովորելը: Գոյություն ունեցող լուծման ձեր սեփական ներդրումը գրելը հիանալի միջոց է սովորելու լավագույն ծրագրավորողներից և այդպիսով կատարելագործելու ձեր հմտությունները:

Source: www.habr.com