Մաքուր կոդը որպես պրոյեկտի հաջողության գրավական

Ողջույն սիրելի ընթերցողներ😊։ Այսօր մեր front-end developer Սամվելը խոսելու է մի  թեմայից, որը թույլ կտա ոլորտ մուտք գործողներին ստանալ հետաքրքիր ինֆորմացիա, ինչը կարող է հաստատել կամ մերժել IT ոլորտ մուտք գործելու իրենց որոշումը, իսկ ոլորտում գտնվողներին՝ ստանալ seniority level-ին հատուկ գործելաոճին վերաբերող տեղեկատվություն։

Մենք գիտենք, որ ծրագրավորումը հրամանների մասին է և վստահ կարող ենք ասել, որ կոդը նախատեսված է խնդիրների լուծման համար։ Մենք վերարտադրում ենք բարդ task-ը կամ գործողությունների շարքը՝ վերածելով այն եզակի պրոցեսի, որը հեշտությամբ օգտագործվում է user–ի կողմից։

 

Կոդի միջոցով մենք փոխանցում ենք մեր մտադրությունները 🤔

💡 Կոդը որպես հուշող մտադրություն

Մենք հաճախ կարծում ենք, որ կոդը պարզ հրահանգների շարք է, որը իրագործվում է համակարգչի կողմից։ Գրելով կոդ՝  մենք փոխանցում ենք հրահանգները և արտահայտում ենք մեր մտադրությունը թե՛ համակարգչին, թե՛ այն ծրագրավորողներին, որոնք հետագայում պետք է առնչվեն  գրված կոդի հետ։ 

 

💡 Կոդը որպես հաղորդակցման մտադրություն

Կարող ենք ասել, որ գրելով կոդը մարդկանց  համար՝ ենթադրում ենք, որ այն պետք է լինի պարզ, իսկ համակարգչի համար՝ ֆունկցիոնալ լավ։ Դիտարկենք հետևյալը ֆունկցիայի օրինակով՝

 

Երկու կոդերն էլ կատարում են միևնույն պահանջվող գործողությունը, սակայն վերջին տարբերակով հասկանում ենք ամբողջ ֆունկցիոնալ իմաստը, որպես ծրագրավորող, ոչ թե որպես համակարգիչ։
Կոդը, որը մենք գրում ենք մարդկանց ու համակարգիչների համար է, այն միշտ պետք է  լինի պարզ, հենց նույնը մեր օրինակով․ մեր սեփական կոդը կարող ենք չհասկանալ որոշակի ժամանակ հետո, եթե չունենանք մաքուր գրված կոդ։

 

💡 Ընթեռնելիություն

Ընթեռնելիությունը լավ կոդի առաջին նախադրյալն է։ Վատ գրված կոդը չի յուրացվի ծրագրավորողի կողմից ու կդառնա մեկ անգամյա գրված կոդ։ Գրելով կոդ, անհրաժեշտ է հաշվի առնել, թե ինչպես է այն ընկալելու հաջորդ մարդկային ուղեղը։ Որոշները սկանավորելու են ընդհանուր կոդը՝ ուշադրություն դարձնելով որոշակի մասերին՝ փորձելով ընկալել ֆունկցիոնալը։
 
💡 Ինչպե՞ս տալ լավ անվանումներ 

Անուններ որոշելը ամենաբարդն է։ Աննունները ամենուր են․ պարզապես անուն որոշելը  հեշտ է, լավ անուն որոշելը՝ դժվար։ Պատկերացնենք ունենք ֆունկցիա, որը պետք է CSS  ոճեր փոխանցի button-ին։ Ունենք հետևյալ 6 տարբերակը՝ ժամանակի տվյալ պահին այս բոլոր անունները ճիշտ են, սակայն որոշ ժամանակ անց առանց խնդրի պահանջը վերհիշելու դժվար կլինի ընկալել  համապատասխան տարբերակի ֆունկցիոնալը։ Ուղղակի կարդալով անվանումները կստեղծվեն տարբեր սպասումներ և ակնկալիքներ ֆունկցիայի գործառույթի վերաբերյալ։ Այս տարբերակներից ամենահամապատասխանը վերջին տարբերակն է։

styleButton
setStyleOfButton
setButtonCSS
stylizeButton
setButtonStyles
applyButtonCSS

 

💡 Լավ անուն ունենալու հիմնական պայմանները

Լավ անունը ցույց է տալիս նպատակ։ Անունից պետք է հնարավոր լինի հասկանալ, թե ինչ նպատակով է այն գրված։ Դիտարկենք հետևյալ օրինակը՝

class TenancyAgreement {

 // տարբերակ 1․
saveSignedDocument( id, timestamp ) {}

 // տարբերակ 2․
saveSignedDocument( documentId, documentTimestamp ) {}

// տարբերակ 3:
saveSignedDocument( tenancyAgreementSignedDocumentID, tenancyAgreementSignedDocumentTimestamp ) {} }

Ունենք class, որը բնութագրում է հիմնական միջավայրը և ֆունկցիաների տարբերակներ։

Տարբերակ 1-ը շատ սահմանափակ է, չափազանց քիչ ինֆորմացիա է տալիս։ Տարբերակ 2-ը տալիս է բավական ինֆորմացիա՝ ֆունկցիայի ամբողջ նպատակը հասկանալու համար։ (Այս տարբերակը տվյալ պարագայում ամենաճիշտն է)։ Տարբերակ 3-ն անիմաստ երկար  ինֆորմացիա է տալիս և ոչ նպատակահարմար է։

 

BeeWeb Idea

💡 Գաղափար

Լավ անունը ենթադրում է լավ գաղափար։ Լավ գաղափար պարունակող անունը ստիպում է մեզ մտածել, թե ինչ պետք է այն պարունակի։

Օրինակ հետևյալ ֆունկցիայի անվանումը տալիս է համապատասխան գաղափար ֆունկցիայի մասին՝
relocateDeviceAccurately։
Ստանում ենք ընդհանուր գործողության մասին գաղափար։ Այն չի ասում, թե ինչ է անելու, ինչ ֆայլերից է օգտվելու, ինչ մեթոդով է խնդրին լուծում տալու, բայց տալիս է հիմնական գաղափարը, ինչն էլ ամենակարևորն է։

 

💡 Պայմանագիր

Լավ անունը, ցույց է տալիս պայամանագիր՝ աբստրակցիոն տեսանկյունից։ Գրելով անուն՝ կապում ենք պայմանագիր անվանման և իր պարունակության միջև։

  •  isAdmin-բնականաբար պարզ է դառնում, որ պետք է լինի boolean տիպի փոփոխական։
  • isUser – ստանում ենք պայմանագիր, որ պետք է ունենանք Boolean արժեք
  • get, find կամ select պարունակող անունները կապում են պայմանգիր առ այն, որ պետք է ստանանք վերադարձնող արժեք, գործ ունենք ֆունկցիաների հետ :

« _»-ով սկսվող անունները զգուշացնում են, որ այդ փոփոխականները private տեսակի են։

 

💡 Անտեղի էկզոտիկ անուններ

Էկզոտիկ են այն անունները, որոնք շեղում են իրենց իմաստն այլ ուղղությամբ (ըմբռնելի չեն), օրինակ՝

function deStylizeParameters(params) { disEntangleParams(params, p => !!p.style).obliterate(); }

function removeStylingFromParams(params) { filterParams(params, param => !!param.style).remove(); }

💡 Անտեղի կարճ անուններ

Ստորև բերված ֆունկցիայի մեջ կտեսնեք անտեղի կարճ անունների օրինակներ՝

function incId(id, f) { 

   for (let x = 0; x < ids.length; ++x) 

  { 

        if (ids[x].id === id && f(ids[x])) {

          ids[x].n++;

       }

   }

 }

function incrementJobInstancesByIdIfFilter(id, filter) {

    for (let i = 0; i < jobs.length; i++) { 

      let job = jobs[i]; if (job.id === id && filter(job)) {

      job.nInstances++;

    }

  }

 }

Ուսումնասիրությունները ցույց են տվել, որ նման տեսակի կոդերը գրվում են ծուլության կամ շտապողականության արդյունքում՝ վնասելով մաքուր կոդին։ Նախընտրելի է կա՛մ քոմենթներով գրել առաջնահերթ փոփոխության մասին, կա՛մ ուղղակի չգրել։

 

💡 Անտեղի երկար անուններ 

Տվյալ անվանումը դժվար է հստակ հասկանալ՝ 

filesService.refreshAndSaveSignedAndNonPendingAgreements();

refreshAndSaveSignedAndNonPendingAgreements- այս անվանումը շատ երկար է, և ակնհայտորեն, շատ գործողություններ է պարունակում։ Իրականում, վերոնշյալ ֆունկցիան կատարում է հետևյալ գործառույթները՝

refresh()

save()

signedAgreements

nonPendingAgreements

Խնդիրն այն է, որ այդ ամենը պետք է կատարել առանձին-առանձին։

Անուններն ընդհանուր առմամբ պետք է ձանձրալի լինեն

Նախընտրելի է հոմանիշ բառեր չօգտագործել , օր․՝ delete գործողություն պահանջող ֆունկցիային չտալ նույնիմաստ հոմանիշ բառեր, որոնք ծրագրավորման մեջ չեն օգտագործվում  (kill, obliterate, efface, deface)։ Չհորինել բառեր , օր․՝ deletify, elementize, or dedupify։

💡 Վատ անուններ

Իսկ հիմա եկեք խաղանք 🙂

Ենթադրենք ունենք պահանջ՝ գրել ֆունկցիա, որը ստուգում է username–ը արդյոք key բառերից մեկն է (admin, root, user)

Ունենք ոչ կատարյալ անվանման 3 տարբերակ՝

matchUsernameAgainstForbiddenWords

checkForForbiddenWordConflicts

isUsernameReservedWord

Կարևոր է հասկանալ, որ 3 ոչ կատարյալ անուններ ստեղծելը ավելի լավ է, քան շատ րոպեներ ծախսելը։ Կարևոր չէ, թե ինչքան վատն են այդ 3 անունները, կարևորը՝ առաջարկել 3 տարբերակ։ Հաջորդ քայլում սկսում ենք համեմատել վատ տարբերակները և 3–ից ստանալ ամենահամապատասխան տարբերակը՝ isUsernameForbiddenWord։

thinking

 

 

 

💡 Որոշումների կայացում

Սովորաբար task-ը ծրագրավորողի կողմից բաժանվում է մասերի, և սկսվում է որոշումների կայացումը։ Ավելի լուրջ խնդիր է հին պրոյեկտի վրա աշխատելը։
Ամեն օր մենք կատարում ենք որոշումներ՝ փոքր ու վճռական, կարևոր ու անկարևոր։ Oրինակ՝ ու՞մ եմ ընտրելու ընտրություններին😏, ի՞նչ եմ ուտելու այսօր 😋 և այլն։ Նույնը կատարվում է ծրագրավորման մեջ։ Այստեղ անհնար է ամեն անգամ կատարյալ ճիշտ որոշում կայացնել։ Արդյունավետ տեխնիկաներից է վերլուծական մտածողությունը, որը հարցի մոտեցման ճանապարհ է։ Այն մեզ հնարավորություն է տալիս քննել իրավիճակը, վեր հանել թաքնված խնդիրները և կատարել ճիշտ ընտրություն։

 


💡 Վերլուծական մտածողություն

Վճռական մտածողությունը ենթադրում է հարցերի շղթա, որոնք թույլ են տալիս իրավիճակին  նայել տարբեր կողմերից։ Ստեղծարար, մտածող, հարմարվող․ սրանք վերլուծական մտածողի հատկանիշներն են։ Այսօր կներկայացնեմ 5 hնարքներ` բարելավելու վերլուծական մտածողությունը:

Հնարք 1․ խնդրի ձևակերպումը հարցի տեսքով
Խնդրի ձևակերպումը հարցի տեսքով կամ ի՞նչ ենք մենք փնտրում։ Համեմատում ենք տարբերակները։ Կարևոր է հասկանալ, որ տվյալ պահին լավ թվացող տարբերակը հետագայում հնարավոր է խնդիրներ առաջացնի և հակառակը։

Հնարք 2․ ինֆորմացիայի հավաքագրում
Խնդրին տիրապետելը կօգնի արդյունավետ որոշում կայացնել: Խնդրի մասին ինֆորմացիա կարող եք հավաքագրել նմանատիպ փորձ ունեցող մարդկանցից և ծանր ու թեթև անել հնարավոր ընտրությունները, որոնք մոտ են ձեր նպատակին։

Հնարք 3․ ինֆորմացիայի կիրառում
Որոշում կայացնելու ժամանակ հարցրեք ինքներդ ձեզ՝ ի՞նչ մեկնություններ կան տվյալ խնդրի վերաբերյալ, ինչպե՞ս եմ ես մեկնաբանում իրավիճակը, և որքանո՞վ է այն տրամաբանական։

Հնարք 4․ Հաշվի առեք հետևանքները
Ինչպես նշեցի վերևում, պետք է միշտ հիշել, որ տվյալ պահին լավագույն թվացող տարբերակը կարող է ունենալ ոչ ցանկալի հետևանքներ։ Հետևաբար հաշվի առեք նաև հնարավոր հետագա խնդիրները։ 

Հնարք 5․ Ուսումնասիրել այլ տեսակետներ
Հարցին անհրաժեշտ է նայել տարբեր տեսանկյուններից։ Էմոցիոնալ վիճակում շատ հաճախ այն դիտարկվում է միայն սեփական ես-ի կողմից, ինչը սխալ է։ Ծանոթացեք այլընտրանքներին, գնահատեք ձեր ընտրությունները և կայացրեք ինֆորմացված որոշումներ։

 

💡 Bus Factor
Պրոյեկտի bus factor – ը մի թիվ է, որը հավասար է թիմի անդամների քանակին, ովքեր «ավտոբուսի տակ ընկնելու» պարագայում, կվտանգեն պրոյկետը։ Ամենափոքր bus factor -ի ցուցանիշը  1 է։ Նախընտրելի են մեծ թվերը։ Այսինքն՝ որքան մեծ լինի bus factor-ի ցուցանիշը, այնքան պրոյեկտը կլինի ավելի քիչ խոցելի, հուսալի և կայուն։

Bus Factor-ի օրինակներ են  թիմի անդամների հիվանդությունները, արձակուրդները, ընկերությունից դուրս գալը, որոնք խոցելի են դարձնում պրոյեկտը։

Bus Factor-ի վրա ազդող հնարավոր պատճառներից են՝

  • Կան ծրագրավորողներ, որոնց կոդը  code review չի անցնում։ Ինչու՞, նա պարզապես «թույն» դեմք է 😎
  • Բացակայում  է documentation – ը, չկա կոդի հստակ կառուցվածք։
  • CI/CD կարգավորումները պրոյեկտում  կատարվում է մեկ մասնագետի կողմից․ բոլորը նրան են դիմում որևէ բան փոխելու, ավելացնելու համար, բայց ոչ ոք մանրամասներից տեղյակ չէ։
  • Կոդի մեջ կան երկար արված անհասկանալի մեկնաբանություններ։
  •  Documentation – ը և տվյալների բազան պահվում է անձնական տարածքներում  կամ ավելի վատ՝ լոկալ, որոնք հեշտությամբ կարող են ջնջվել։

Այսպիսով, հասկացանք թե որքան կարևոր է  լավ  գրված  կոդը թե ՛ պրոյեկտների հաջողության, թե ՛ ծրագրավորողների մասնագիտական աճի համար։ Մաքուր կոդը պայմանավորված է ընթեռնելիությամբ, փոփոխականների ճիշտ անվանումներով, կառուցվածքային բաժանումներով և մի շարք այլ գործոններով։ Խոսեցինք նաև որոշումներ կայացնելու գործընթացից և վերլուծական մտածողությունը զարգացնող  մի քանի պրակտիկ հնարքներից։

Դե ինչ, սիրելի ընթերցողներ,  հուսով ենք ՝ Սամվելի բլոգը շատերիդ համար ինֆորմատիվ էր և օգտակար։ 😊

 

Կարդացեք նաև՝

Website and Software development ideas

Svelte JS՝ նոր մոտեցում User Interface ստեղծելու համար

Share with love

28 Garegin Nzhdeh street,
Yerevan, Armenia.

info@beewebsystems.com

SUBSCRIBE

Subscribe to BeeWeb's blog and get our latest news right in your inbox.

FOLLOW US