A kódfüggőség az ördög.

„A változás az egyetlen állandó…” - Heraclitus (filozófus)

A webes alkalmazások építéséhez használt eszközök, könyvtárak és keretrendszerek ma drasztikusan különböznek azoktól, amelyeket alig néhány évvel ezelőtt használtunk.

Néhány év múlva e technológiák többsége drámai módon megváltozik. Mégis, sokan közülünk ezeket az alkalmazások központi, elválaszthatatlan részévé teszik.

Úgy importálunk, használunk és öröklünk a hónap ízének keretrendszereiből, mintha mindannyian örökre körülvennék és változatlanok lennének. Nos ... nem azok. És ez egy probléma.

Több mint 20 éves fejlesztés, tervezés és építkezés után két fontos igazságot értettem meg:

  1. A külső függőségek nagy veszélyt jelentenek bármely alkalmazás hosszú távú stabilitására és életképességére.
  2. Egyre nehezebb - ha nem is lehetetlen - bármilyen nem triviális alkalmazást létrehozni a külső függőségek kihasználása nélkül.

Ez a cikk arról szól, hogy össze kell egyeztetni ezt a két igazságot, hogy alkalmazásainknak legyenek a legnagyobb esélyei a hosszú távú túlélésre.

A nyúl lyuk valóban nagyon mély.

Ha elkezdenénk gondolkodni mindazon dolgokon, amelyeken a webalkalmazásaink függenek, könnyű egy tucatnyi vagy annál több dologra gondolni, még mielőtt a kódhoz jutnánk:

  • Erő
  • Kapcsolódás
  • Tűzfal
  • DNS
  • Szerver hardver (CPU, Disk, Ram,…)
  • Hűtés
  • Virtualizációs platform
  • Konténer platform
  • Operációs rendszer
  • Webkiszolgáló platform
  • App Server Platform
  • Böngésző

Fejlesztőként jó tisztában lenni ezekkel a dolgokkal, de gyakran nem sokat tehetünk ezekkel. Tehát most hagyjuk figyelmen kívül őket, és csak a kódról beszéljünk.

A kódban háromféle függőség létezik:

1. Az általunk ellenőrzött függőségek

Ez egy kód, amelyet mi vagy szervezetünk írt és birtokol.

2. Függőségek, amelyeket nem ellenőrizünk

Ezt a kódot egy harmadik fél gyártója vagy egy nyílt forráskódú szoftver közösség írta.

3. A függőségek eltávolítása után

Ezektől a kódfüggőségektől függenek a harmadik féltől származó kódfüggőségek. (Mondd, hogy háromszor gyorsan!)

Főleg azokról a függőségekről fogunk beszélni , amelyeket nem ellenőrizünk .

Az általunk ellenőrzött függőségek és az egyszer eltávolított függőségek továbbra is fejfájást okozhatnak, de az általunk ellenőrzött függőségek esetén képesnek kell lenniünk a közvetlen beavatkozásra és a problémák enyhítésére.

Az egyszer eltávolított függőségek esetén általában egy harmadik félre támaszkodhatunk, aki gondoskodik rólunk, mivel ezek is függenek tőlük.

Miért jók a harmadik féltől származó kódfüggőségek?

A webalkalmazás nagy része létezik a gyakori problémák megoldására: hitelesítés, hitelesítés, adatelérés, hibakezelés, navigáció, naplózás, titkosítás, elemlista megjelenítése, űrlapbemenetek ellenőrzése stb.

Függetlenül attól, hogy melyik technológiai halmot használja, jó esély van arra, hogy ezekre a problémákra közös megoldások létezzenek, és könyvtárakként állnak rendelkezésre, amelyeket könnyedén megszerezhet és beépítheti a kódalapjába. Ha ezeket a dolgokat teljesen a semmiből írja, általában időpazarlás.

Olyan kódra akar koncentrálni, amely vagy nem mindennapi problémát old meg, vagy egy általános problémát nem mindennapi módon old meg. Ez teszi értékessé alkalmazását: az a kód, amely végrehajtja azokat az üzleti szabályokat, amelyek csak az alkalmazásra vonatkoznak - a „titkos szósz”.

A Google keresési és oldalrangsorolási algoritmusa, a Facebook idővonal-szűrése, a Netflix „Önnek ajánlott” szakasza és adattömörítési algoritmusok - ezeknek a funkcióknak a kódja „titkos szósz”.

A külső gyártók kódjai - könyvtárak formájában - lehetővé teszik az alkalmazás ezen árukészleti funkcióinak gyors megvalósítását, így továbbra is a „titkos szószra” koncentrálhat.

Miért rosszak a harmadik féltől származó kódfüggőségek?

Vessen egy pillantást az elmúlt pár évben készült nem triviális webalkalmazásokra, és teljesen meg fog lepődni azon kódok mennyiségén, amelyek valójában egy harmadik fél könyvtárából származnak. Mi van, ha a harmadik fél könyvtárai közül egy vagy több drasztikusan megváltozik, vagy eltűnik, vagy megszakad?

Ha nyílt forráskódú, akkor talán maga is kijavíthatja. De mennyire érti jól a könyvtár saját kódját? Nagy oka annak, hogy miért használ egy könyvtárat, elsődlegesen a kód előnyeinek kihasználása anélkül, hogy aggódnia kellene minden részlet miatt. De most elakadtál. Teljesen ezekhez a függőségekhez kötötte a vagyonát, amelyek nem Ön tulajdonában vannak és nem kontrollálhatók.

Talán úgy gondolja, hogy túlzok, vagy pusztán tudományos szempontból beszélek. Hadd biztosíthassalak Önöknek - több tucat példám van azokról az ügyfelekről, akik teljesen snookeltek azzal, hogy harmadik fél kódját túl szorosan beágyazták az alkalmazásukba. Itt csak egy friss példa ...

Egy korábbi ügyfelem a Facebook tulajdonában lévő, a Parse nevű Backend-as-a-Service szolgáltató segítségével építette fel alkalmazását. A Parse szolgáltatás használatához a Parse által biztosított JavaScript kliens könyvtárat használták. Ennek során szorosan összekapcsolták az összes kódjukat - beleértve a „titkos szósz” kódot is - ehhez a könyvtárhoz.

Három hónappal az ügyfelem első termékbevezetése után - éppen akkor, amikor a valódi, fizető ügyfelekkel kezdtek jó tapadást elérni -, a Parse bejelentette, hogy leáll.

Most ahelyett, hogy a termékük ismétlésére és az ügyfélkör bővítésére összpontosítottam volna, az ügyfelemnek ki kellett derítenie, hogyan lehet vagy áttérni a Parse önállóan üzemeltetett, nyílt forráskódú verziójára, vagy teljesen le kell cserélni a Parse-t.

Az a zavar, amelyet ez egy fiatal, új alkalmazásban okozott, olyan hatalmas volt, hogy ügyfelem végül teljesen selejtezte az alkalmazást.

A jó és a rossz egyensúlya

Néhány évvel ezelőtt a kockázatok leküzdésére és a harmadik féltől származó könyvtárak előnyeinek megőrzésére irányuló megoldásom az volt, hogy ezeket az Adapter Pattern segítségével becsomagoltam.

Lényegében a harmadik fél kódját csomagolja egy általad írt adapterosztályba vagy modulba. Ez akkor működik, hogy a harmadik fél könyvtárainak funkcióit az Ön által irányított módon tárja fel.

Ha ezt a mintát használja, ha egy harmadik féltől származó könyvtár vagy keretrendszer megváltozik vagy eltűnik, akkor csak egy kis adapterkódot kell javítania. Az alkalmazás többi része érintetlen marad.

Ez jól hangzik papíron. Ha önálló függőségei vannak, amelyek csak néhány funkciót látnak el, ez megcsinálja. De a dolgok gyorsan csúnyává válhatnak.

El tudod képzelni, hogy a teljes React könyvtárat (beleértve a JSX-et is) be kell csomagolni, mielőtt bármelyiket használnád? Mit szólnál a jQuery, vagy az Angular, vagy a Spring keretrendszer Java-ba csomagolásához? Ez gyorsan rémálommá válik.

Manapság árnyaltabb megközelítést ajánlok ...

Minden egyes függőséghez, amelyet hozzá kíván adni a kódbázisához, két tényező szorzásával értékelje az általa okozott kockázat szintjét:

  1. Annak a valószínűsége, hogy a függőség lényegesen megváltozik.
  2. A függőség függvényében bekövetkező lényeges változás által okozott kár mértéke az alkalmazásához.

Egy harmadik fél könyvtárának vagy keretrendszere kevésbé valószínű, hogy megváltozik, ha a következő dolgok némelyike ​​vagy mindegyike igaz:

  • Több éve létezik, és több jelentős kiadása is volt.
  • Számos kereskedelmi alkalmazás széles körben alkalmazza.
  • Aktívan támogatja egy nagy szervezetet - lehetőleg háztartási nevű céget vagy intézményt.

Egy harmadik féltől származó könyvtár vagy keretrendszer kevesebb kárt okoz az alkalmazásában, ha az alábbi dolgok némelyike ​​vagy mindegyike igaz:

  • Csak az alkalmazás egy kis része használja, ahelyett, hogy az egészet felhasználná.
  • A függő kód nem része annak a „titkos szósznak”, amiről korábban beszéltem.
  • Eltávolítása minimális változtatásokat igényel a kódalapon.
  • A teljes alkalmazás nagyon kicsi, és gyorsan átírható. (Vigyázzon ezzel - ez ritkán igaz nagyon sokáig.)

Minél kockázatosabb, annál valószínűbb, hogy becsomagolja vagy teljesen elkerüli.

Ami a kódot illeti, amely valóban központi jelentőségű az alkalmazás értékajánlásában - a „titkos szószban” - rendkívül óvatosnak kell lennie iránta. Tegye a kódot a lehető legfüggetlenebbé. Ha feltétlenül függőséget kell használnia, fontolja meg az injekció beadását, ahelyett, hogy közvetlenül hivatkozna rá. Akkor is légy óvatos.

Néha ez azt jelenti, hogy „nem” mondasz egy harmadik fél könyvtárának, amelyről azt gondolod, hogy ez nagyon klassz, vagy amit egy vagy másik okból nagyon szeretnél használni. Légy erős. Hidd el, megtérül. Kérdezze meg mindazokat, akik nagy összegeket fektettek az Angular legelső kiadásába, vagy egykori ügyfelemet, aki mindenhol használta a Parse-t. Nem szórakoztató. Hidd el nekem.

Ha már a szórakozásról van szó, akkor nézze meg ezt ...

A fenti kép a TinyTag Explorer nevű alkalmazás függőségi grafikonja.

A meglévő alkalmazások függőségi grafikonjának létrehozása nagyszerű módja annak, hogy megértsük a függőségek által kiváltott kockázat szintjét. Összeállítottam egy listát az ingyenes eszközökről a fentiekhez hasonló grafikonok előállításához különféle nyelveken, beleértve a JavaScriptet, a C #, a Java, a PHP és a Python nyelveket. Itt kaphatja meg.

Segítsen másoknak segíteni

Minél több fejlesztőnek szeretnék segíteni azzal, hogy megosztom velük ismereteimet és tapasztalataimat. Kérjük, segítsen nekem az alábbi ❤ ajánlás gombra kattintva (zöld szív).

Végül ne felejtse el itt megragadni az ingyenes függőségi gráf-generátorok listáját.