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

Függőségeid minden alkalommal megégetnek.
„A változás az egyetlen állandó…” - Heraclitus (filozófus)

Azok az eszközök, könyvtárak és keretek, amelyeket ma a webes alkalmazásunk felépítéséhez használunk, drasztikusan különböznek azoktól, amelyeket csak néhány évvel ezelőtt használtunk.

Néhány rövid év múlva ezen technológiák többsége drasztikusan megváltozott. Ennek ellenére sokan teszik ezeket alkalmazásunk központi, elválaszthatatlan részévé.

Importáljuk, használjuk és örököljük a havi íz-keretrendszereket, mintha mindannyian körülbelül és örökké változatlanok lennének. Nos ... ők nem. És ez egy probléma.

20 év feletti webes alkalmazások fejlesztése, tervezése és felépítése után két fontos igazságot értékeltem:

  1. A külső függőségek komoly 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 felépíteni anélkül, hogy kihasználnák a külső függőségeket.

Ez a cikk arról szól, hogy összeegyeztetjük ezt a két igazságot, hogy alkalmazásunknak a legnagyobb esélye legyen a hosszú távú túlélésre.

A nyúllyuk valóban nagyon mély.

Ha elkezdünk gondolkodni azon dolgokon, amelyek a webes alkalmazásunkon múlik, akkor könnyedén gondolkodni egy tucatnál vagy annál többen, mielőtt még a kódhoz jutnánk:

  • Erő
  • Kapcsolódás
  • Tűzfal
  • DNS
  • Szerver hardver (CPU, lemez, RAM,…)
  • Lehűlés
  • Virtualizációs platform
  • Konténer platform
  • Operációs rendszer
  • Webszerver platform
  • App Server Platform
  • Böngésző

Fejlesztőként jó tudatában lenni ezeknek a dolgoknak, de gyakran nem sokat tehetünk velük. Tehát 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

Ezt a kódot írta és tulajdonosa vagy szervezetünk.

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

Ez egy kód, amelyet harmadik fél gyártója vagy nyílt forrású szoftver közösség írt.

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

Ezek a kódfüggőségek, amelyektől a harmadik féltől származó kódfüggőségek függnek. (Mondja ezt háromszor gyorsan!)

Elsősorban azon függőségekről fogunk beszélni, amelyeket nem ellenőrizünk.

Az általunk ellenőrzött függőségek és az 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 lennünk a közvetlen beavatkozásra és az esetleges problémák enyhítésére.

Az egyszer eltávolított függőségek esetén általában megbízhatunk egy harmadik féllel, hogy vigyázzon ránk, mivel ők is ezektől függnek.

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

Webes alkalmazásának nagy része létezik a gyakori problémák megoldására: hitelesítés, engedélyeztetés, adathozzáférés, hibakezelés, navigáció, naplózás, titkosítás, tételek listájának megjelenítése, űrlapbevitel validálása és így tovább ...

Függetlenül attól, hogy melyik technológiai köteget használja, nagy esély van arra, hogy ezekre a problémákra általános megoldások léteznek, és könyvtárakként érhetők el, amelyeket könnyen megszerezhet és beilleszthet a kódbázisába. Ezeknek a dolgoknak a teljesen a semmiből történő írása általában időpocsékolás.

Olyan kódra szeretne koncentrálni, amely vagy megoldja a ritka problémákat, vagy egy gyakori problémát egy ritka módon. Ez az, ami értékeli alkalmazását: a kód, amely végrehajtja az üzleti szabályokat, amelyek kizárólag az Ön alkalmazására vonatkoznak - a „titkos szósz”.

A Google keresési és oldal-rangsorolási algoritmusa, a Facebook idővonal-szűrése, a Netflix „neked ajánlott” szakasza és adattömörítési algoritmusok - ezen szolgáltatások mögött található kód „titkos szósz”.

Harmadik fél kódja - könyvtárak formájában - lehetővé teszi az alkalmazás ezen árucikkekkel ellátott funkcióinak gyors megvalósítását, így összpontosíthat a „titkos szószra”.

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

Vessen egy pillantást az elmúlt években beépített nem triviális web-alkalmazásokra, és teljesen megdöbbentő lesz a kód mennyisége, amely valójában egy harmadik fél könyvtárából származik. Mi lenne, ha egy vagy több ilyen harmadik fél könyvtára drasztikusan megváltozik, eltűnik, vagy eltörik?

Ha nyílt forráskódú, akkor talán meg is javíthatja. De mennyire érti meg az összes kódot abban a könyvtárban, amely nem birtokolja? Nagyon fontos ok, amiért egy könyvtárat használ, hogy a kód előnyeit élvezze anélkül, hogy minden részlettel aggódnia kellene. De most elakad. Teljes mértékben összekapcsolta vagyonát ezekkel a függőségekkel, amelyek nem birtokolnak és nem irányíthatók.

Ne aggódjon, e cikk végére új reményeket talál.

Talán azt gondolod, hogy eltúllok, vagy tisztán tudományos szempontból beszélek. Biztosíthatom Önöket - tucatnyi példa van olyan ügyfelekre, akik teljes mértékben szimatoltak maguknak, ha harmadik fél kódját túl szorosan beágyazták alkalmazásukba. Íme csak egy legutóbbi példa ...

A korábbi ügyfeleim a Facebook tulajdonában lévő Backend-as-a-szolgáltató segítségével építették fel alkalmazásukat, Parse néven. A Parse által biztosított JavaScript kliens könyvtárat használták a Parse szolgáltatás igénybevételéhez. A folyamat során szorosan összekapcsolták az összes kódot - beleértve a „titkos szósz” kódot is - ehhez a könyvtárhoz.

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

Ahelyett, hogy a termékek iterálására és az ügyfélkör bővítésére koncentrálnék, ügyfeleimnek kitalálniuk kellett, hogyan válasszuk át a Parse önálló üzemeltetett, nyílt forrású verzióját, vagy teljesen cseréljük le a Parse-t.

Az a zavar, amelyet ez egy fiatal, fiatal alkalmazás számára okozott, olyan hatalmas volt, hogy az ügyfelem végül teljesen leselejtette az alkalmazást.

A jó és a rossz kiegyensúlyozása

Néhány évvel ezelőtt a kockázatok leküzdésére, miközben megőriztem a harmadik féltől származó könyvtárak előnyeit, az volt, hogy becsomagolom azokat az Adapter Pattern segítségével.

Alapvetõen a harmadik fél kódját csomagolja egy adapter osztályba vagy modulba, amelyet írt. Ez ezután a harmadik fél könyvtárainak funkcióinak az Ön által irányított módon történő feltárására szolgál.

E minta használatával, ha egy harmadik féltől származó könyvtár vagy keret megváltozik vagy megszűnik, akkor csak kicsit javítania kell az adapterkódot. Az alkalmazás többi része érintetlen marad.

Adaptermintázat a Dofactory.com webhelyről

Ez jól hangzik papíron. Ha önálló függőségei vannak, amelyek csak néhány funkciót biztosítanak, ez meg fogja csinálni. De a dolgok gyorsan csúnya lehet.

El tudod képzelni, hogy le kell csomagolnia a teljes React könyvtárat (beleértve a JSX-t is), mielőtt bármelyikét felhasználná? Mi lenne a jQuery, a Angular vagy a Spring keret Java csomagolása? Ez gyorsan rémálommá válik.

Manapság egy árnyaltabb megközelítést javasolok ...

Az egyes függőségek esetében, amelyeket hozzá szeretne adni a kódbázisához, értékelje a kockázat szintjét két tényező szorzásával:

  1. Annak valószínűsége, hogy a függőség lényegesen megváltozik.
  2. A függőség lényeges megváltozása által az alkalmazásával okozott károk mértéke.

A harmadik fél könyvtára vagy kerete kevésbé valószínű, hogy megváltozik, ha a következők mindegyike vagy mindegyike igaz:

  • Több éve van, és több jelentős kiadása is volt.
  • Széles körben használják számos kereskedelmi alkalmazásban.
  • Aktívan támogatja egy nagy szervezet - lehetőleg háztartási névvel foglalkozó társaság vagy intézmény.

Egy harmadik féltől származó könyvtár vagy keretrendszer kevesebb kárt okoz az alkalmazásának, ha a következők egy része vagy egésze igaz:

  • Csak az alkalmazás egy kis részében használja, nem pedig az egészben.
  • A tőle függő kód nem része annak a „titkos szósznak”, amelyről korábban beszéltünk.
  • Ennek eltávolítása minimális változtatást igényel a kódban.
  • A teljes alkalmazás nagyon kicsi, és gyorsan átírható. (Legyen óvatos ezzel - nagyon ritkán igaz.)

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

Amikor az a kód vonatkozik, amely valóban központi jelentőségű alkalmazásának - a „titkos mártásod” értékmeghatározása szempontjából - rendkívül óvatosan kell védenie azt. Tegye ezt a kódot a lehető legkülönlegesebbé. 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á. Még akkor is légy óvatos.

Időnként ez azt jelenti, hogy „nem” kell mondani egy harmadik féltől származó könyvtárnak, amelyről úgy gondolja, hogy igazán jó, vagy amit valami okból használni akar. Légy erős. Bízz bennem, ez megtérül. Csak kérdezze meg mindazokat az embereket, akik komolyan fektettek be az Angular legelső kiadásához, vagy az egykori ügyfelemet, aki mindenhol használta a Parse-t. Ez nem szórakozás. Hidd el nekem.

A móka kedvéért nézzük meg ezt ...

A TinyTag explorer függőségi gráfja

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

A meglévő alkalmazások függőségi gráfjának elkészítése nagyszerű módja annak, hogy megértsük a függőségek által bevezetett kockázati szintet. Összeállítottam az ingyenes eszközök listáját a fentiekhez hasonló grafikonok előállításához különféle nyelveken, például JavaScript, C #, Java, PHP és Python. Itt lehet beszerezni.

Segíts másoknak segíteni

A lehető legtöbb fejlesztőt szeretnék segíteni abban, hogy megosztom velük tudásomat és tapasztalataimat. Segítsen nekem az alábbi ❤ Ajánlás gombra (zöld szív) kattintással.

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