Կոդի կախվածությունը սատանան է:

Ձեր կախվածությունները ամեն անգամ ձեզ կվառեն:
«Փոփոխությունը միակ հաստատունն է ...» - Հերակլիտուս (Փիլիսոփա)

Գործիքները, գրադարանները և շրջանակները, որոնք մենք այսօր օգտագործում ենք մեր վեբ ծրագրերը ստեղծելու համար, կտրուկ տարբերվում են այն տարբերակներից, որոնք մենք օգտագործել ենք ընդամենը մի քանի կարճ տարի առաջ:

Այսուհետ մի քանի կարճ տարիների ընթացքում այդ տեխնոլոգիաների մեծ մասը նորից կտրուկ փոխվելու է: Այնուամենայնիվ, մեզանից շատերը դրանք դարձնում են մեր ծրագրերի կենտրոնական և անբաժանելի մասը:

Մենք ներմուծում ենք, օգտագործում և ժառանգում ենք նախորդ ամսվա համեմունքներից, ասես, որ նրանք բոլորն էլ հավերժ կլինեն շուրջ ու անփոփոխ: Դե ... նրանք այդպես չեն: Եվ դա խնդիր է:

20+ տարի վեբ ծրագրեր մշակելիս, ձևավորվելուց և ճարտարապետացնելուց հետո եկել եմ գնահատելու երկու կարևոր ճշմարտություն.

  1. Արտաքին կախվածությունը մեծ վտանգ է ներկայացնում ցանկացած կիրառման երկարաժամկետ կայունության և կենսունակության համար:
  2. Ավելի ու ավելի դժվար է, եթե ոչ անհնարին, կառուցել ցանկացած տիպի ոչ տրիվիալ ծրագիր ՝ առանց արտաքին կախվածության մեծացման:

Այս հոդվածը այս երկու ճշմարտությունների հաշտեցման մասին է, որպեսզի մեր ծրագրերը ունենան երկարաժամկետ գոյատևման առավելագույն հնարավորություններ:

Նապաստակի անցքը իրոք շատ խորն է:

Եթե ​​մենք սկսենք մտածել այն բոլոր բաների մասին, որոնք մեր վեբ ծրագրերը կախված են նրանից, հեշտ է մտածել տասնյակի կամ ավելիի մասին, նախքան նույնիսկ ծածկագրին հասնելը.

  • Ուժ
  • Կապակցություն
  • Firewall- ը
  • DNS
  • Սերվերի ապարատային սարք (CPU, Disk, Ram,…)
  • Սառչում
  • Վիրտուալացման պլատֆորմ
  • Բեռնարկղերի պլատֆորմ
  • Օպերացիոն համակարգ
  • Վեբ սերվերի պլատֆորմ
  • Ծրագրի սերվերի պլատֆորմ
  • Վեբ զննարկիչը

Որպես ծրագրավորողներ, լավ է տեղյակ լինել այս բաների մասին, բայց դրանց մասին հաճախ մենք շատ բան չենք կարող անել: Այնպես որ, եկեք անտեսենք դրանք այժմ և խոսենք միայն ծածկագրի մասին:

Կոդում կա երեք տեսակի կախվածություն.

1. Կախվածությունը, որը մենք վերահսկում ենք

Սա մեր կամ մեր կազմակերպության կողմից գրված և պատկանող ծածկագիր է:

2. Կախվածություններ, որոնք մենք չենք վերահսկում

Սա ծածկագիր է, որը գրված է երրորդ կողմի վաճառողի կամ բաց կոդով ծրագրային ապահովման համայնքի կողմից:

3. Կախվածությունները մեկ անգամ հանվել են

Սրանք կախված են ծածկագրերից, որոնցից կախված են երրորդ կողմի ծածկագրերը: (Ասեք, որ երեք անգամ արագ!)

Մենք կխոսենք հիմնականում կախվածության մասին, որը չենք վերահսկում:

Կախվածությունները, որոնք մենք վերահսկում ենք և կախվածությունը մեկ անգամ հեռացնելուց, դեռ կարող են առաջացնել գլխացավեր, բայց այն կախվածության դեպքում, որը մենք վերահսկում ենք, մենք պետք է կարողանանք ուղղակիորեն միջամտել և մեղմել ցանկացած խնդիր:

Մեկ անգամ հեռացված կախվածության դեպքում մենք սովորաբար կարող ենք ապավինել երրորդ կողմին ՝ հոգ տանել մեզ համար, քանի որ դրանք նույնպես կախված են դրանցից:

Ինչու են երրորդ կողմի կոդային կախվածությունները լավ

Ձեր վեբ հավելվածի մեծ մասը գոյություն ունի ընդհանուր խնդիրների լուծման համար ՝ վավերացում, թույլտվություն, տվյալների հասանելիություն, սխալի գործածում, նավիգացիա, անտառահատում, գաղտնագրում, իրերի ցուցակի ցուցադրում, ձևի մուտքերի վավերացում և այլն…

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

Դուք ցանկանում եք կենտրոնանալ կոդի վրա, որը կա՛մ հազվադեպ է լուծում խնդիրը, կա՛մ սովորական խնդիր է լուծում ոչ հազվադեպ: Դա է ձեր ծրագիրը դարձնում արժեքավոր. Այն կոդը, որն իրականացնում է բիզնեսի կանոնները, որոնք եզակի են միայն ձեր հավելվածը `« գաղտնի սոուս »:

Google- ի որոնման և էջերի դասակարգման ալգորիթմը, Facebook- ի ժամանակային զտումը, Netflix- ի «ձեզ համար առաջարկված» բաժինը և տվյալների սեղմման ալգորիթմները. Այս բոլոր հատկանիշների ետևում նշված ծածկագիրը «գաղտնի սոուս» է:

Երրորդ կողմի ծածկագիրը `գրադարանների տեսքով, թույլ է տալիս արագորեն իրականացնել ձեր հավելվածի ապրանքի գանձվող հատկությունները, այնպես որ կարողանաք կենտրոնանալ ձեր« գաղտնի սոուսով »:

Ինչու՞ են երրորդ կողմի կոդային կախվածությունները վատ

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

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

Մի անհանգստացեք, մինչև այս հոդվածի ավարտը նոր հույս կգտնեք:

Գուցե դուք կարծում եք, որ չափազանցնում եմ, կամ խոսում եմ զուտ ակադեմիական տեսանկյունից: Թույլ տվեք հավաստիացնել ձեզ. Ես ունեմ մի քանի տասնյակ հաճախորդների օրինակներ, որոնք ամբողջովին խորտակվել են ՝ ներդնելով երրորդ կողմի ծածկագիրը շատ խստորեն իրենց ծրագրի մեջ: Ահա միայն վերջին օրինակը…

Իմ նախկին հաճախորդը կառուցել է իր ծրագիրը ՝ օգտագործելով «Ֆեյսբուք» -ին պատկանող «Backend-as-a-Service» մատակարարը, որը կոչվում էր Parse: Նրանք օգտվել են Պարսից տրամադրված JavaScript հաճախորդի գրադարան ՝ պարսից ծառայությունը սպառելու համար: Գործընթացում նրանք սերտորեն միացրին իրենց բոլոր ծածկագրերը `ներառյալ« գաղտնի սոուս »ծածկագիրը այս գրադարանին:

Իմ հաճախորդի նախնական արտադրանքի թողարկումից երեք ամիս անց. Հենց այն ժամանակ, երբ նրանք սկսեցին որոշակի լավ քաշքշել իրական, վճարող հաճախորդների հետ, Պարսեն հայտարարեց, որ այն դադարեցված է:

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

Երիտասարդ, նոր գործի համար պատճառված խանգարումը այնքան հսկայական էր, որ իմ հաճախորդը, ի վերջո, ամբողջովին ջնջեց ծրագիրը:

Հավասարակշռելով լավը և վատը

Մի քանի տարի առաջ, երրորդ կողմի գրադարանների առավելությունները պահպանելու ընթացքում ռիսկերը հաղթահարելու իմ լուծման լուծումը `դրանք հարմարեցնելով ադապտերների ձևաչափով:

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

Օգտագործելով այս օրինակը, եթե երրորդ կողմի գրադարանը կամ շրջանակը փոխվում է կամ հեռանում է, ապա միայն պետք է մի փոքր հարմարեցնեք ադապտերային ծածկագիրը: Ձեր ծրագրի մնացած մասը մնում է անձեռնմխելի:

Ադապտորի օրինակելի դիագրամ Dofective.com- ից

Սա լավ է հնչում թղթի վրա: Երբ դուք ունեք ինքնուրույն կախվածություններ, որոնք ապահովում են միայն մի քանի գործառույթ, դա կկատարի հնարքը: Բայց ամեն ինչ կարող է արագ տգեղ լինել:

Պատկերացնում եք, որ պետք է փաթեթավորեք React- ի ամբողջ գրադարանը (ներառյալ JSX) `նախքան դրա ցանկացած օգտագործումը: Ինչ վերաբերում է jQuery- ի կամ Angular- ի կամ Java- ի գարնանային շրջանակին փաթաթելուն: Սա արագորեն դառնում է մղձավանջ:

Այս օրերին ես առաջարկում եմ ավելի նրբերանգ մոտեցում…

Յուրաքանչյուր կախվածության համար, որը ցանկանում եք ավելացնել ձեր ծածկագրային բազային, գնահատեք այն ներմուծման ռիսկի մակարդակը ՝ բազմապատկելով երկու գործոն.

  1. Հավանականությունը, որ կախվածությունը նյութական ձևով կփոխվի:
  2. Վնասի չափը, որը նյութականորեն փոխվում է կախվածության մեջ, կկատարի ձեր դիմումին:

Երրորդ կողմի գրադարանը կամ շրջանակն ավելի քիչ հավանական է փոխվում, երբ հետևյալ բաներից մի քանիսը կամ բոլորը ճշմարիտ են.

  • Այն շուրջ մի քանի տարի է, ինչ ունեցել է մի քանի հիմնական թողարկում:
  • Այն լայնորեն օգտագործվում է բազմաթիվ առևտրային ծրագրերի կողմից:
  • Այն ունի մեծ կազմակերպության ակտիվ աջակցություն `ցանկալի է տնային տնտեսությունների անունով ընկերություն կամ հաստատություն:

Երրորդ կողմի գրադարանը կամ շրջանակը ավելի քիչ վնաս կպատճառեն ձեր դիմումին, երբ հետևյալ բաներից կամ բոլորը ճշմարիտ են.

  • Այն օգտագործվում է միայն ձեր դիմումի փոքր մասի կողմից, այլ ոչ թե այն ամբողջությամբ օգտագործելու համար:
  • Դա կախված է այն «գաղտնի սոուսից», որի մասին ես նախկինում խոսեցի:
  • Այն հանելը պահանջում է նվազագույն փոփոխություններ ձեր կոդային բազայում:
  • Ձեր ամբողջ դիմումը շատ փոքր է և կարող է արագ վերաշարադրվել: (Զգույշ եղեք այս մեկի հետ. Դա շատ հազվադեպ է ճիշտ):

Ավելի վտանգավոր ինչ-որ բան այն է, այնքան ավելի հավանական է, որ դուք պետք է փաթեթավորեք այն կամ ընդհանրապես խուսափեք դրանից:

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

Երբեմն սա նշանակում է «ոչ» ասել երրորդ կողմի գրադարանին, որը դու կարծում ես, իրոք, զով է, կամ, որ իսկապես ուզում ես օգտագործել այս կամ այն ​​պատճառով: Ուժեղ եղիր. Վստահեք ինձ, այն կվճարի: Պարզապես հարցրեք բոլոր այն մարդկանց, ովքեր մեծ ներդրումներ են կատարել Angular- ի առաջին իսկ թողարկման մեջ, կամ իմ նախկին հաճախորդը, ով Պարսեն օգտագործում էր ամենուր: Զվարճալի չէ: Հավատա ինձ.

Խոսելով զվարճալի մասին, դիտեք այս…

Կախվածության գծապատկեր TinyTag Explorer- ի համար

Վերը նկարը կախվածության գրաֆիկ է TinyTag Explorer կոչվող ծրագրի համար:

Ձեր առկա ծրագրերի համար կախվածության գծապատկեր ստեղծելը հիանալի միջոց է ձեր կախվածության կողմից ներմուծվող ռիսկի մակարդակը հասկանալու հիանալի միջոց: Ես համախմբել եմ վերը նշված գծապատկերների գրաֆիկների ստեղծման անվճար գործիքների ցանկը մի շարք լեզուներով `JavaScript, C #, Java, PHP և Python: Դուք կարող եք ձեռք բերել այստեղ:

Օգնիր ինձ օգնել ուրիշներին

Անկանում եմ օգնել հնարավորինս շատ մշակողների ՝ իրենց գիտելիքներն ու փորձը կիսելով նրանց հետ: Խնդրում եմ օգնեք ինձ `կտտացնելով ներքևում ❤ առաջարկող կոճակը (կանաչ սիրտ):

Ի վերջո, այստեղ մի մոռացեք գրավել ձեր ազատ կախվածության գրաֆիկի գեներատորների ցանկը: