Кодқа тәуелділік - бұл шайтан.

Сіздің тәуелділіктеріңіз сізді әрдайым күйдіреді.
«Өзгеріс - бұл жалғыз тұрақты ...» - Гераклит (Философ)

Бүгінгі таңда веб-қосымшаларды құру үшін біз қолданатын құралдар, кітапханалар мен жақтаулар бірнеше жыл бұрын қолданған құралдардан түбегейлі ерекшеленеді.

Енді бірнеше жылдан кейін бұл технологиялардың көпшілігі қайтадан күрт өзгереді. Дегенмен, біздің көпшілігіміз бұл бағдарламалардың орталық, ажырамас бөлігі болып табылады.

Біз ай сайынғы хош иісті жақтаулардан мәңгілікке өзгеріске ұшырайтындай етіп импорттаймыз, пайдаланамыз және мұра етеміз. Жақсы ... олар емес. Бұл проблема.

20-жылдық веб-қосымшаларды жасаудан, жобалаудан және мұрағаттағаннан кейін мен екі маңызды шындықты түсіндім:

  1. Сыртқы тәуелділіктер кез-келген қосымшаның ұзақ мерзімді тұрақтылығы мен өміршеңдігіне үлкен қауіп төндіреді.
  2. Сыртқы тәуелділікті пайдаланбай, кез-келген тривиалды емес қосымшаны құру қиынға соғады, мүмкін болмаса, мүмкін емес.

Бұл мақалада біздің екі қосымшамыздың ұзақ мерзімді өмір сүру үшін үлкен мүмкіндігі болуы үшін осы екі шындықты келісу туралы.

Қоян шұңқыры өте терең.

Егер біз веб-қосымшамыздың барлық нәрселері туралы ойлана бастасақ, онда кодқа жетпей тұрып он немесе одан да көп ойлана аламыз:

  • Қуат
  • Байланыс
  • Брандмауэр
  • DNS
  • Серверлік жабдық (CPU, Disk, Ram,…)
  • Салқындату
  • Виртуализация платформасы
  • Контейнер платформасы
  • Операциялық жүйе
  • Веб-сервер платформасы
  • App Server платформасы
  • Веб-шолғыш

Әзірлеушілер ретінде бұл нәрселер туралы білген жөн, бірақ олар туралы көп нәрсе жасай алмаймыз. Сонымен, оларды қазірге елемей, тек код туралы сөйлесейік.

Кодта тәуелділіктің үш түрі бар:

1. Біз басқаратын тәуелділіктер

Бұл бізге немесе біздің ұйымға тиесілі және меншікті код.

2. Біз басқармайтын тәуелділіктер

Бұл үшінші тарап жеткізушісі немесе ашық көздермен бағдарламалық жасақтама қауымдастығы жазған код.

3. Тәуелділіктер жойылды

Бұл біздің үшінші тараптардың коды тәуелділіктеріне тәуелді кодтық тәуелділіктер. (Осыны үш рет айт!)

Біз көбінесе басқарылмайтын тәуелділіктер туралы сөйлесетін боламыз.

Біз басқарып отырған тәуелділіктер мен жойылған тәуелділіктер бәрібір бас ауруын тудыруы мүмкін, бірақ біз басқаратын тәуелділік жағдайында біз кез-келген проблеманы тікелей шешіп, азайта аламыз.

Тәуелділіктер жойылған жағдайда, біз әдетте біз үшін қамқорлық жасау үшін үшінші тарапқа сенім арта аламыз, өйткені олар да осыған тәуелді.

Неліктен үшінші тараптың кодқа тәуелділігі жақсы

Веб-қосымшаның көп бөлігі жалпы мәселелерді шешуге арналған: аутентификация, авторизация, деректерге қол жеткізу, қателерді өңдеу, навигация, тіркеу, шифрлау, элементтер тізімін көрсету, пішін енгізулерін тексеру және т.б. ...

Қандай технологияны қолданбайтындығыңызға қарамастан, осы мәселелерді шешудің жалпы мүмкіндігі бар және сіз оңай сатып алып, өзіңіздің деректер базаңызға қосыла алатын кітапханалар бола аласыз. Бұл кез-келген нәрсені толығымен нөлден жазу - бұл әдетте уақытты ысырап ету.

Сіз сирек кездесетін мәселені шешетін немесе жиі кездесетін мәселені шешетін кодқа назар аударғыңыз келеді. Міне, сіздің қосымшаңызды құнды етеді: тек сіздің бағдарламаңызға ғана тән бизнес ережелерін орындайтын код - «құпия тұздық».

Google іздеу және парақ рейтингісінің алгоритмі, Facebook-тің уақыт шкаласы, Netflix-тің «сізге ұсынылған» бөлімі және деректерді сығу алгоритмдері - осы мүмкіндіктердің барлығының коды - «құпия тұздық».

Үшінші тарап коды - кітапханалар түрінде - сіз өзіңіздің «құпия тұздығыңызға» назар аударуыңызға мүмкіндік беретін бағдарламаның сол қасиеттерін тез арада орындауға мүмкіндік береді.

Неліктен үшінші тараптың кодқа тәуелділігі нашар

Соңғы екі жылда жасалған кез-келген тривиалды емес веб-қосымшаны қараңыз және сіз үшінші тарап кітапханасынан алынған кодтың мөлшеріне таңданасыз. Осы үшінші тарап кітапханаларының біреуі немесе бірнешеуі түбегейлі өзгерсе, жоғалып кетсе немесе бұзылса ше?

Егер бұл ашық көзі болса, мүмкін оны өзіңіз түзете аласыз. Сізде жоқ кітапханадағы кодтардың барлығын қаншалықты жақсы түсінесіз? Кітапхананы бірінші кезекте қолданудың үлкен себебі - кодтың барлық артықшылықтары туралы алаңдамай, артықшылықтарын алу. Бірақ қазір сіз кептеліп қалдыңыз. Сіз өзіңіздің иелігіңіздегі және басқарылмайтын тәуелділіктермен өз байлығыңызды толығымен байланыстырдыңыз.

Уайымдамаңыз, осы мақаланың соңында сіз жаңа үміт таба аласыз.

Мүмкін мені асыра сілтедім немесе академиялық тұрғыдан сөйлеймін деп ойлайтын шығарсыз. Сізге сендіруге рұқсат етіңіз - менің клиенттерімнің ондаған мысалдары бар, олар өздерінің қосымшаларына тым мықтап еніп, өздерін әшкерелеген. Мұнда жақында бір ғана мысал келтірілген ...

Менің бұрынғы клиентім Facebook-тің Parse деп аталатын Backend-as-a-Service провайдерінің көмегімен өз қосымшасын жасады. Олар Parse қызметі ұсынған JavaScript клиенттік кітапханасын пайдаланады. Осыған байланысты олар өздерінің барлық кодтарын, соның ішінде «құпия тұздық» кодын осы кітапханаға мықтап қосып алды.

Менің клиентімнің алғашқы өнімі шыққаннан кейін үш айдан кейін - олар нақты және төлем жасайтын клиенттермен жақсы қарым-қатынас жасай бастағанда - Parse оның жабылғаны туралы хабарлады.

Енді клиентім олардың өнімдеріне итерациялаудың және клиенттік базаны көбейтудің орнына, Parse-дің өзіндік қайнар көзіне көшуді немесе Parse-ді толығымен ауыстыруды қалай шешуге тура келді.

Бұл жаңа, жас қосымшаның жұмысына кедергі келтіргені соншалық, менің клиентім бағдарламаны толығымен алып тастады.

Жақсы мен жаманды теңестіру

Бірнеше жыл бұрын үшінші тараптардың кітапханаларының артықшылықтарын сақтай отырып, тәуекелдерді еңсерудің шешімі - оларды адаптер үлгісімен орап алу болды.

Сіз үшінші тарап кодын сіз жазған адаптер класына немесе модульге саласыз. Бұл үшінші тарап кітапханаларының функцияларын сіз басқаратындай етіп ашады.

Осы үлгіні пайдаланып, үшінші тарап кітапханасы немесе жақтауы өзгерсе немесе кетсе, сізге тек адаптердің кодын түзету керек. Бағдарламаның қалған бөлігі өзгеріссіз қалады.

Dofactory.com сайтындағы адаптер сызбасының диаграммасы

Бұл қағазда жақсы естіледі. Сізде бірнеше функцияларды ғана қамтамасыз ететін өзіндік тәуелділіктер болған кезде, бұл оңай емес. Бірақ заттар тез арада жаман болуы мүмкін.

Кез-келген кітапхананы пайдаланбас бұрын React кітапханасын (соның ішінде JSX) орап алуды елестете аласыз ба? JQuery, немесе Angular немесе Java-да көктемгі жақтауды қалай орауға болады? Бұл тез қорқынышқа айналады.

Осы күндері мен сізге әлдеқайда ыңғайлы тәсілді ұсынамын ...

Сіздің кодтық базаңызға қосқыңыз келген тәуелділік үшін екі факторды көбейту арқылы оның тәуекел деңгейін бағалаңыз:

  1. Тәуелділік материалдық тұрғыдан өзгеруі ықтималдығы.
  2. Тәуелділікке байланысты өзгерген материалдық шығын сіздің өтінішіңізге қандай зиян келтіреді.

Үшінші тараптың кітапханасы немесе жақтауы төменде көрсетілгендердің кейбіреулері немесе барлығы дұрыс болған кезде өзгермейді:

  • Ол бірнеше жыл бойы болды және бірнеше негізгі шығарылымдары болды.
  • Оны көптеген коммерциялық қосымшалар кеңінен қолданады.
  • Бұл үлкен ұйымның белсенді қолдауына ие - жақсырақ титулдық компания немесе мекеме.

Үшінші тараптың кітапханасы немесе жақтауы кейбір немесе барлық дұрыс болған кезде сіздің қосымшаңызға азырақ зиян келтіреді:

  • Оны тек қолданбағаннан гөрі қосымшаның кішкене бөлігі ғана қолданады.
  • Оған байланысты код, мен бұрын айтқан «құпия тұздықтың» бөлігі емес.
  • Оны жою сіздің деректер базаңызда ең аз өзгертулерді қажет етеді.
  • Сіздің бүкіл қосымшаңыз өте кішкентай және тез жазылуы мүмкін. (Мұны абайлаңыз - бұл өте сирек кездеседі).

Бір нәрсе қауіпті болса, оны орап алу немесе мүлдем болдырмау ықтималдығы жоғары.

Сіздің бағдарламаңыздың құндылық ұсыныстарында шын мәнінде маңызды болып табылатын код - «құпия тұздық» туралы айтатын болсақ, сіз оны ерекше қорғауға тиіссіз. Бұл кодты мүмкіндігінше тәуелсіз етіп жасаңыз. Егер сіз тәуелділікті қолдануды қажет етсеңіз, оны тікелей сілтеме жасамай, инъекциялау туралы ойланыңыз. Сонда да сақ болыңыз.

Кейде бұл үшінші тараптың кітапханасына «жоқ» деп айтуды шынымен керемет деп санайсыз немесе сіз оны қандай да бір себептермен немесе басқа себептермен пайдаланғыңыз келеді. Мықты бол. Маған сеніңіз, ол өтейді. Angular-тің алғашқы шығарылымына көп қаражат салған адамдардан немесе Parse-ді барлық жерде қолданған бұрынғы клиентімнен сұраңыз. Бұл қызық емес. Маған сеніңіз.

Көңілді әңгіме айтсаңыз, мынаны қараңыз ...

TinyTag зерттеушісінің тәуелділік графигі

Жоғарыдағы сурет TinyTag Explorer деп аталатын бағдарламаның тәуелділік графигі болып табылады.

Бұрынғы қолданбаларыңызға тәуелділік графигін құру тәуелділіктер енгізетін қауіп деңгейін түсінудің тамаша тәсілі. Мен жоғарыда аталғанға ұқсас графиканы құруға арналған ақысыз құралдардың тізімін бірнеше тілде, соның ішінде JavaScript, C #, Java, PHP және Python-да жасадым. Сіз мұнда ала аласыз.

Маған басқаларға көмектесуге көмектесіңіз

Мен өзімнің білімім мен тәжірибеммен бөлісе отырып, мүмкіндігінше көптеген жасаушыларға көмектескім келеді. Маған төмендегі ❤ ұсыну түймесін (жасыл жүрек) басу арқылы көмектесіңізші.

Ақырында, мұнда тәуелділік графикалық генераторларының тізімін алуды ұмытпаңыз.