Vartësia e kodit është djalli.

Vartësia juaj do t'ju djeg çdo herë.
"Ndryshimi është i vetmi konstante ..." - Heraclitus (Filozof)

Mjetet, bibliotekat dhe kornizat që përdorim për të ndërtuar aplikacionet tona të internetit sot janë në mënyrë drastike të ndryshme nga ato që kemi përdorur vetëm disa vjet të shkurtra.

Në pak vite të shkurtër nga tani, shumica e këtyre teknologjive do të ndryshojnë përsëri në mënyrë dramatike. Megjithatë, shumë prej nesh i bëjnë këto një pjesë qendrore, të pandashme të aplikacioneve tona.

Ne importojmë, përdorim dhe trashëgojmë nga kornizat e aromës së muajve sikur të gjitha do të jenë përreth dhe të pandryshuara përgjithmonë. Epo… nuk janë. Dhe ky është një problem.

Pas 20+ viteve të zhvillimit, hartimit dhe arkitekturës së aplikacioneve në internet, kam arritur të vlerësoj dy të vërteta të rëndësishme:

  1. Vartësia e jashtme paraqet një kërcënim të madh për stabilitetin afatgjatë dhe qëndrueshmërinë e çdo aplikacioni.
  2. Increasinglyshtë gjithnjë e më e vështirë - nëse jo e pamundur - të ndërtosh çfarëdo lloj aplikacioni jo të parëndësishëm pa nxitur varësi të jashtme.

Ky artikull ka të bëjë me pajtimin e këtyre dy të vërtetave në mënyrë që aplikacionet tona të kenë mundësinë më të madhe për mbijetesë afatgjatë.

Vrima e lepurit është me të vërtetë shumë e thellë.

Nëse fillojmë të mendojmë për të gjitha gjërat që aplikacionet tona në internet varen nga është e lehtë të mendojmë për një duzinë ose më shumë para se të arrijmë në kod:

  • pushtet
  • Lidhshmëria
  • firewall
  • DNS
  • Hardware Hardware (CPU, Disk, Ram,…)
  • ftohjes
  • Platforma e Virtualizimit
  • Platforma e kontejnerëve
  • Sistemi Operativ
  • Platforma e serverëve në internet
  • Platforma e serverëve të aplikacioneve
  • Shfletues uebi

Si zhvillues, është mirë të jesh i vetëdijshëm për këto gjëra, por shpesh nuk ka shumë gjëra që mund të bëjmë rreth tyre. Pra, le t'i injorojmë ato tani dhe flasim vetëm për kodin.

Në kod, ekzistojnë tre lloje të varësisë:

1. Vartësitë që kontrollojmë

Ky është kod i shkruar dhe në pronësi të nesh ose organizatës sonë.

2. Vartësitë ne nuk i kontrollojmë

Ky është kodi i shkruar nga një shitës i palëve të treta ose nga bashkësia e softuerëve me burim të hapur.

3. Vartësitë pasi hiqen një herë

Këto varen nga varësia e kodit të palëve të treta. (Thuaj që tre herë shpejt!)

Do të flasim kryesisht për varësitë që nuk i kontrollojmë.

Vartësitë që ne kontrollojmë dhe varësitë pasi të hiqen, ende mund të shkaktojnë dhimbje koke, por në rastin e varësisë që kontrollojmë, duhet të jemi në gjendje të ndërhyjmë drejtpërdrejt dhe të zbusim çdo problem.

Në rastin e varësisë pasi të hiqet, ne zakonisht mund të mbështetemi te një palë e tretë që të kujdeset për të për ne, pasi edhe ata varen nga këto.

Pse varësia e kodit të palëve të treta janë të mira

Një pjesë e madhe e aplikacionit tuaj të internetit ekziston për të zgjidhur problemet e zakonshme: vërtetimin, autorizimin, hyrjen e të dhënave, trajtimin e gabimeve, navigimin, prerjet, encryption, shfaqjen e një liste të artikujve, vërtetimin e inputeve të formës, etj.

Pavarësisht nga cila pirg teknologjie përdorni, ekziston një shans i mirë që ekzistojnë zgjidhje të përbashkëta për këto probleme, dhe janë në dispozicion si biblioteka që lehtë mund t’i blini dhe futni në bazën e kodeve tuaja. Të shkruash ndonjë nga këto gjëra plotësisht nga e para është përgjithësisht një humbje kohe.

Ju dëshironi të përqendroheni në kodin që zgjidh një problem jo të zakonshëm ose zgjidh një problem të zakonshëm në një mënyrë jo të zakonshme. Kjo është ajo që e bën të vlefshëm aplikacionin tuaj: kodi që zbaton rregullat e biznesit që janë unike vetëm për aplikacionin tuaj - "salca e fshehtë".

Algoritmi i kërkimit dhe renditjes së faqeve të Google, filtrimi i kohëzgjatjes së Facebook, seksioni "rekomanduar për ju" i Netflix dhe algoritmet e kompresimit të të dhënave - kodi që qëndron pas të gjitha këtyre karakteristikave është "salcë sekrete".

Kodi i palëve të treta - në formën e bibliotekave - ju lejon të zbatoni shpejt ato tipare të komodizuara të aplikacionit tuaj, në mënyrë që të qëndroni të përqendruar në "salcën tuaj të fshehtë".

Pse varësitë e kodit të palëve të treta janë të këqija

Shikoni çdo aplikacion jo-të parëndësishëm të krijuar në dy vitet e fundit dhe do të mahniteni absolutisht nga sasia e kodit që në të vërtetë vjen nga një bibliotekë e palëve të treta. Po sikur një ose më shumë nga ato biblioteka të palëve të treta ndryshojnë në mënyrë drastike, ose zhduken, ose prishen?

Nëse është me burim të hapur, ndoshta mund ta rregulloni vetë. Por sa mirë i kupton të gjitha kodet në atë bibliotekë që nuk zotëron? Një arsye e madhe pse përdorni bibliotekën në radhë të parë është të merrni përfitimet e kodit pa pasur nevojë të shqetësoheni për të gjitha detajet. Por tani ju keni ngecur. Ju e keni lidhur plotësisht pasurinë tuaj me këto varësi që nuk i zotëroni dhe nuk i kontrolloni.

Mos u shqetëso, deri në fund të këtij artikulli, do të gjesh një shpresë të re.

Ndoshta ju mendoni se jam duke e ekzagjeruar, ose duke folur nga një këndvështrim thjesht akademik. Më lejoni t'ju siguroj - kam dhjetëra shembuj të klientëve që tërhoqën plotësisht veten duke futur kodin e palëve të treta shumë fort në aplikacionin e tyre. Këtu është vetëm një shembull i fundit ...

Një ish klient i imi ndërtoi aplikacionin e tyre duke përdorur një ofrues të Shërbimit Backend-as-a në pronësi të Facebook, i quajtur Parse. Ata përdorën një bibliotekë të klientëve JavaScript të siguruar nga Parse për të konsumuar shërbimin Parse. Në këtë proces, ata bashkuan fort të gjithë kodin e tyre - përfshirë kodin "salcë sekrete" në këtë bibliotekë.

Tre muaj pas fillimit të produktit fillestar të klientit tim - ashtu si ata filluan të marrin tërheqje të mirë me klientët e vërtetë, duke paguar - Parse njoftoi se ishte duke u mbyllur.

Tani në vend që të përqëndrohesha te iterating në produktin e tyre dhe rritjen e bazës së tyre të klientit, klienti im duhej të kuptoj se si ose të migrojë në një version të vetë-pritur, me burim të hapur të Parse, ose të zëvendësojë plotësisht Parse.

Përçarja që shkaktoi kjo për një aplikacion të ri, të ri ishte aq i madh sa klienti im përfundimisht hoqi aplikacionin plotësisht.

Balancimi i të mirës dhe të keqes

Disa vjet më parë, zgjidhja ime për të kapërcyer rreziqet ndërsa ruaj përfitimet e bibliotekave të palëve të treta ishte t'i mbështesja ato duke përdorur modelin e përshtatësit.

Në thelb, ju përfundoni kodin e palëve të treta në një klasë përshtatës ose modul që keni shkruar. Kjo pastaj funksionon për të ekspozuar funksionet e bibliotekave të palëve të treta në një mënyrë që ju kontrolloni.

Duke përdorur këtë model, nëse një bibliotekë ose kornizë e palëve të treta ndryshon, ose shkon larg, ju duhet vetëm të rregulloni pak kodin e përshtatësit. Pjesa tjetër e aplikacionit tuaj mbetet i paprekur.

Diagrami i modelit të përshtatësit nga Dofective.com

Kjo tingëllon mirë në letër. Kur ju keni varësi të vetme që ofrojnë vetëm disa funksione, kjo do të bëjë hile. Por gjërat mund të bëhen të shëmtuara shpejt.

Mund ta imagjinoni se duhet të mbështillni të gjithë bibliotekën React (përfshirë JSX) përpara se të përdorni ndonjë prej tyre? Po në lidhje me mbështjelljen e jQuery, ose Angular, ose kornizën e pranverës në Java? Kjo shpejt bëhet një makth.

Këto ditë unë rekomandoj një qasje më të nuancuar…

Për secilën varësi që doni të shtoni në bazën e kodit tuaj, vlerësoni nivelin e rrezikut që do të prezantojë duke shumëzuar dy faktorë:

  1. Mundësia që varësia të ndryshojë në një mënyrë materiale.
  2. Sasia e dëmit që një ndryshim material në varësi do të bënte me kërkesën tuaj.

Një bibliotekë ose kornizë e palëve të treta ka më pak të ngjarë të ndryshojë kur disa ose të gjitha gjërat e mëposhtme janë të vërteta:

  • Ka rreth disa vite dhe ka pasur disa lëshime të mëdha.
  • Përdoret gjerësisht nga shumë aplikacione tregtare.
  • Ajo ka mbështetjen aktive të një organizate të madhe - mundësisht një kompani apo një institucion familjar.

Një bibliotekë ose kornizë e palëve të treta do të dëmtojë më shumë aplikacionin tuaj kur disa ose të gjitha gjërat e mëposhtme janë të vërteta:

  • Përdoret vetëm nga një pjesë e vogël e aplikacionit tuaj, në vend që të përdoret në të gjithë.
  • Kodi që varet nga ai nuk është pjesë e asaj "salcë sekrete" për të cilën kam folur më herët.
  • Heqja e tij kërkon ndryshime minimale në bazën e kodit tuaj.
  • E gjithë aplikacioni juaj është shumë i vogël dhe mund të rishkruhet shpejt. (Kini kujdes me këtë - rrallë është e vërtetë për shumë kohë.)

Diqka është më e rrezikshme, ka më shumë të ngjarë të jeni për ta mbështjellur ose shmangur atë plotësisht.

Kur bëhet fjalë për kodin që është me të vërtetë thelbësore për propozimin e vlerës së aplikacionit tuaj - "salca juaj sekrete" - ju duhet të jeni jashtëzakonisht mbrojtës ndaj tij. Bëni atë kod sa më të pavarur të jetë e mundur. Nëse absolutisht duhet të përdorni një varësi, mendoni ta injektoni atë në vend që ta referoni direkt atë. Edhe atëherë, ki kujdes.

Ndonjëherë kjo do të thotë të thuash "jo" në një bibliotekë të palëve të treta që mendon se është vërtet interesante, ose që me të vërtetë dëshiron ta përdorësh për një arsye ose një tjetër. Bëhu i fortë. Më beso, do të paguajë. Thjesht pyesni të gjithë ata njerëz që investuan shumë në daljen e parë të Angular, ose klientin tim të dikurshëm që e përdorte Parse kudo. Nuk është kënaqësi. Më beso.

Duke folur për argëtim, hidhini një sy kësaj ...

Grafiku i varësisë për eksploruesin TinyTag

Imazhi më sipër është grafiku i varësisë për një aplikacion të quajtur TinyTag Explorer.

Gjenerimi i një grafiku të varësisë për aplikacionet tuaja ekzistuese është një mënyrë e shkëlqyeshme për të kuptuar nivelin e rrezikut të paraqitur nga varësitë tuaja. Unë kam bashkuar një listë të mjeteve falas për krijimin e grafikëve të ngjashëm me sa më sipër në një larmi gjuhësh përfshirë JavaScript, C #, Java, PHP dhe Python. Mund ta merrni këtu.

Më ndihmo të ndihmoj të tjerët

Unë dua të ndihmoj sa më shumë zhvillues që mundem duke ndarë njohuritë dhe përvojën time me ta. Ju lutemi më ndihmoni duke klikuar butonin ❤ rekomandoj (zemrën jeshile) më poshtë.

Më në fund, mos harroni të rrëmbeni listën tuaj të gjeneruesve të grafikëve me varësi falas këtu.