Кодавыя залежнасці - д'ябал.

Вашы залежнасці будуць спальваць вас кожны раз.
"Змена адзіная пастаянная ..." - Геракліт (Філосаф)

Інструменты, бібліятэкі і рамкі, якія мы выкарыстоўваем для стварэння нашых вэб-прыкладанняў, значна адрозніваюцца ад тых, якія мы выкарыстоўвалі ўсяго некалькі гадоў таму.

Праз некалькі кароткіх гадоў большасць гэтых тэхналогій зноў кардынальна змяніцца. Тым не менш, многія з нас робяць гэта цэнтральнай і непарыўнай часткай нашых прыкладанняў.

Мы імпартуем, выкарыстоўваем і ўспадкоўваем рамкі водару месяца, як калі б яны назаўжды былі вакол і змяніліся назаўсёды. Ну ... яны не. І гэта праблема.

Пасля 20-ці гадоў распрацоўкі, дызайну і архітэктуры вэб-прыкладанняў я ацаніў дзве важныя ісціны:

  1. Знешнія залежнасці ствараюць вялікую пагрозу стабільнасці і жыццяздольнасці любога прыкладання.
  2. Усё цяжэй - калі не немагчыма - ствараць любыя нетрывіяльныя дадаткі без выкарыстання знешніх залежнасцей.

У гэтым артыкуле гаворыцца пра сумяшчанне гэтых дзвюх ісцін, каб нашы прыкладанні мелі найбольшыя шанцы на доўгачасовае выжыванне.

У трусінай дзірцы сапраўды вельмі глыбока.

Калі мы пачнем думаць пра ўсё, ад чаго залежаць нашы вэб-прыкладанні, лёгка прыдумаць дзясятак і больш, перш чым мы нават прыйдзем да кода:

  • Харчаванне
  • Падключэнне
  • Брандмаўэр
  • DNS
  • Абсталяванне сервера (працэсар, дыск, рам,…)
  • Астуджэнне
  • Платформа віртуалізацыі
  • Платформа для кантэйнераў
  • Аперацыйная сістэма
  • Платформа вэб-сервера
  • Платформа сервера прыкладанняў
  • Вэб-браўзэр

Як распрацоўшчыкам, добра ведаць пра гэтыя рэчы, але часта мы можам з імі зрабіць. Такім чынам, давайце праігнаруем іх пакуль і пагаворым толькі пра код.

У кодзе ёсць тры віды залежнасцей:

1. Залежнасці, якія мы кантралюем

Гэты код напісаны і належыць нам альбо нашай арганізацыі.

2. Залежнасці, якія мы не кантралюем

Гэта код, напісаны трэцім вытворцам альбо супольнасцю праграмнага забеспячэння з адкрытым зыходным кодам.

3. Залежнасць пасля зняцця

Гэта залежнасці ад кода, ад якіх залежаць іншыя кодавыя коды. (Скажыце, што тры разы хутка!)

Мы будзем гаварыць у асноўным пра залежнасці, якія мы не кантралюем.

Залежнасці, якія мы кантралюем, і залежнасці, як толькі іх выдаляць, усё яшчэ могуць выклікаць галаўныя болі, але ў выпадку залежнасці, якімі мы кіруем, мы павінны мець магчымасць непасрэдна ўмяшацца і змякчаць любыя праблемы.

У выпадку зняцця залежнасцей звычайна мы можам разлічваць на тое, каб клапаціцца пра нас, бо яны таксама залежаць ад іх.

Чаму залежнасці ад кода іншых вытворцаў добрыя

Значная частка вашага вэб-прыкладання існуе для вырашэння агульных праблем: аўтэнтыфікацыя, аўтарызацыя, доступ да дадзеных, апрацоўка памылак, навігацыя, вядзенне часопісаў, шыфраванне, адлюстраванне спісу элементаў, праверка ўводу формаў і гэтак далей ...

Незалежна ад таго, які стэк тэхналогій вы выкарыстоўваеце, ёсць вялікая верагоднасць, што агульныя рашэнні для гэтых праблем існуюць і даступныя ў выглядзе бібліятэк, якія вы зможаце лёгка набыць і падключыць да вашай кодавай базе. Пісаць усе рэчы з нуля, як правіла, марнаваць час.

Вы хочаце сканцэнтравацца на кодзе, які альбо вырашае незвычайную праблему, альбо вырашае агульную праблему незвычайна. Вось што робіць вашу заяўку каштоўнай: код, які рэалізуе правілы бізнесу, унікальныя толькі для вашага прыкладання - "сакрэтны соус".

Алгарытм пошуку і ранжыравання Google ад Google, фільтраванне часовай шкалы Facebook, раздзел "Рэкамендуемы для вас" у Netflix і алгарытмы сціску дадзеных - код, які стаіць за ўсімі гэтымі функцыямі, - "сакрэтны соус".

Іншы код - у выглядзе бібліятэк - дазваляе хутка рэалізаваць тыя камерцыйныя функцыі вашага прыкладання, каб вы маглі заставацца сканцэнтраванымі на сваім "сакрэтным соусе".

Чаму ад трэціх бакоў залежнасці ад кода дрэнна

Зірніце на любое нетрывіяльнае вэб-прыкладанне, пабудаванае за апошнія пару гадоў, і вы будзеце здзіўлены колькасцю кода, які фактычна паходзіць з бібліятэкі іншых вытворцаў. Што рабіць, калі адна ці некалькі такіх іншых бібліятэк рэзка змяняецца, альбо знікае, альбо ламаецца?

Калі гэта з адкрытым зыходным кодам, магчыма, вы можаце выправіць гэта самастойна. Але наколькі добра вы разумееце ўвесь код гэтай бібліятэкі, якой вы не валодаеце? Вялікая прычына, па якой вы карыстаецеся бібліятэкай, перш за ўсё, гэта атрымаць перавагі кода, не турбуючыся пра ўсе падрабязнасці. Але цяпер ты затрымаўся. Вы цалкам звязалі свой лёс з гэтымі залежнасцямі, якімі вы не валодаеце і не кіруеце.

Не хвалюйцеся, у канцы гэтага артыкула вы знойдзеце новую надзею.

Магчыма, вы лічыце, што я перабольшваю, альбо кажу з чыста акадэмічнага пункту гледжання. Дазвольце вас запэўніць - у мяне ёсць дзясяткі прыкладаў кліентаў, якія цалкам падкраліся да сябе, убудоўваючы ў свой дадатак код занадта моцна. Вось толькі адзін нядаўні прыклад ...

Былы мой кліент стварыў сваё прыкладанне з дапамогай Backend-as-a-Service Service, які належыць Facebook, пад назвай Parse. Для карыстання паслугай Parse яны выкарыстоўвалі бібліятэку кліентаў JavaScript, прадастаўленую Parse. У працэсе працы яны шчыльна спалучалі ўвесь свой код - уключаючы код сакрэтнага соусу - у гэтую бібліятэку.

Праз тры месяцы пасля запуску першага прадукту майго кліента - гэтак жа, як яны пачалі атрымліваць добрую цягу з рэальнымі кліентамі, якія плацяць - Парс абвясціў, што яго закрываюць.

Цяпер, замест таго, каб засяродзіцца на ітэрацыі на сваім прадукце і пашырэнні сваёй кліенцкай базы, мой кліент павінен быў высветліць, як альбо перайсці на самастойную версію Parse з адкрытым зыходным кодам, альбо цалкам замяніць Parse.

Збоі, якія выклікалі маладыя, маладыя прыкладанні, былі настолькі велізарныя, што мой кліент у рэшце рэшт цалкам адключыў прыкладанне.

Балансаванне добрага і дрэннага

Некалькі гадоў таму маім рашэннем для пераадолення рызык пры захаванні пераваг старонніх бібліятэк было іх абкручванне з дапамогай адаптарнага шаблона.

Па сутнасці, вы абгортваеце код трэцяй асобы ў клас адаптара або модуль, які вы напісалі. Затым гэта працуе, каб выкрыць функцыі бібліятэк іншых вытворцаў такім чынам, якім вы кіруеце.

Выкарыстоўваючы гэты ўзор, калі другая бібліятэка або рамкі змяняюцца альбо сыходзяць, вам трэба толькі выправіць код адаптара. Астатняя частка вашага прыкладання застаецца некранутай.

Схема адаптара ад Dofactory.com

Гэта добра гучыць на паперы. Калі ў вас ёсць аўтаномныя залежнасці, якія забяспечваюць толькі некалькі функцый, гэта зробіць трук. Але ўсё можа стаць непрыгожым хутка.

Вы можаце ўявіць, што вам трэба абгарнуць усю бібліятэку React (уключаючы JSX), перш чым выкарыстоўваць яе? Як наконт абкручвання jQuery альбо Angular, альбо Spring Framework ў Java? Гэта хутка становіцца кашмарам.

У гэтыя дні я рэкамендую больш нюансаваны падыход ...

Для кожнай залежнасці, якую вы хочаце дадаць да вашай кодавай базе, ацаніце ўзровень рызыкі, які ён увядзе, памножыўшы два фактары:

  1. Верагоднасць таго, што залежнасць зменіцца матэрыяльна.
  2. Колькасць шкоды, якую істотнае змяненне залежыць ад вашай заявы.

Бібліятэка ці аснова іншых вытворцаў менш мяняюцца, калі некаторыя ці ўсе наступныя рэчы з'яўляюцца сапраўднымі:

  • Яно існуе ўжо некалькі гадоў і мела некалькі асноўных выпускаў.
  • Ён шырока выкарыстоўваецца ў многіх камерцыйных дадатках.
  • Ён актыўна падтрымлівае вялікую арганізацыю - пажадана кампанію, якая называе хатнюю гаспадарку, альбо ўстанову.

Бібліятэка ці рамка іншых вытворцаў нанясуць менш шкоды вашаму дадатку, калі некаторыя ці ўсе наступныя рэчы адпавядаюць рэчаіснасці:

  • Ён выкарыстоўваецца толькі невялікай часткай вашага прыкладання, а не выкарыстоўваецца ва ўсім.
  • Код, які залежыць ад яго, не ўваходзіць у той «сакрэтны соус», пра які я казаў раней.
  • Выдаленне гэтага патрабуе мінімальных змяненняў у вашай базах дадзеных.
  • Уся ваша заяўка вельмі малая і можа быць хутка перапісана. (Будзьце ўважлівыя з гэтым - гэта рэдка бывае вельмі доўга.)

Чым больш рызыкоўна, тым больш верагоднасць вам абгарнуць яго альбо пазбегнуць зусім.

Калі гаворка ідзе пра код, які сапраўды важны для значэння вашай заяўкі - вашага "сакрэтнага соусу" - вам трэба быць надзвычай ахоўным. Зрабіце гэты код максімальна незалежным. Калі вам абсалютна трэба выкарыстоўваць залежнасць, падумайце пра ін'екцыі, а не пра непасрэдную спасылку на яе. Ужо тады будзьце ўважлівыя.

Часам гэта азначае сказаць "не" бібліятэцы іншых вытворцаў, якую вы лічыце сапраўды класнай, альбо якую вы сапраўды хочаце выкарыстоўваць па той ці іншай прычыне. Быць моцным. Паверце, гэта акупіцца. Проста спытаеце ўсіх тых людзей, якія ўклалі вялікія сродкі ў першы выпуск Angular, альбо майго былога кліента, які паўсюдна карыстаўся Парсе. Гэта не забава. Паверце мне.

Калі казаць пра забаву, паглядзіце гэта ...

Графік залежнасці для даследчыка TinyTag

Выява вышэй - графік залежнасці для прыкладання пад назвай TinyTag Explorer.

Стварэнне графіка залежнасці для існуючых прыкладанняў - выдатны спосаб зразумець узровень рызыкі, які ўводзяць вашы залежнасці. Я сабраў спіс бясплатных інструментаў для стварэння графікаў, падобных да вышэй, на розных мовах, уключаючы JavaScript, C #, Java, PHP і Python. Вы можаце атрымаць яго тут.

Дапамажыце мне дапамагчы іншым

Я хачу дапамагчы як мага больш распрацоўшчыкаў, падзяліўшыся сваімі ведамі і вопытам з імі. Дапамажыце мне, націснуўшы кнопку button рэкамендаваць (зялёнае сэрца) ніжэй.

Нарэшце, не забудзьцеся захапіць спіс бясплатных генератараў графікаў залежнасці тут.