“a változás az egyetlen állandó …” – Heraclitus (filozófus)
azok az eszközök, könyvtárak és keretrendszerek, amelyeket ma webes alkalmazásaink építéséhez használunk, drasztikusan különböznek azoktól, amelyeket néhány évvel ezelőtt használtunk.
néhány rövid év múlva ezeknek a technológiáknak a többsége ismét drámai módon megváltozik. Még, sokan teszik ezeket központi, elválaszthatatlan része a apps.
importáljuk, használjuk és örököljük a hónap ízét, mintha mind örökre változatlanok lennének. Hát … nem azok. És ez egy probléma.
több mint 20 évnyi webes alkalmazások fejlesztése, tervezése és architektúrája után két fontos igazságra jöttem rá:
- 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.
- egyre nehezebb — ha nem is lehetetlen — bármilyen nem triviális alkalmazást felépíteni külső függőségek kihasználása nélkül.
ez a cikk e két igazság összeegyeztetéséről szól, hogy alkalmazásainknak a legnagyobb esélyük legyen a hosszú távú túlélésre.
a nyúllyuk valóban nagyon mély.
ha elkezdünk gondolkodni mindazokon a dolgokon, amelyeken a webes alkalmazásaink függenek, akkor könnyű egy tucat vagy annál többet gondolni, mielőtt még a kódhoz is eljutnánk:
- teljesítmény
- kapcsolódás
- tűzfal
- DNS
- szerver hardver (CPU, lemez, Ram, …)
- hűtés
- virtualizációs Platform
- konténer Platform
- operációs rendszer
- webszerver platform
- App szerver platform
- webböngésző
fejlesztőként jó, ha tisztában vagyunk ezekkel a dolgokkal, de gyakran nem sokat tehetünk ellenük. 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
ezt a kódot mi vagy szervezetünk írta és birtokolja.
2.
ez egy harmadik fél vagy nyílt forráskódú szoftverközösség által írt kód.
3.
ezek azok a kódfüggőségek, amelyektől a harmadik féltől származó kódfüggőségek függenek. (Mondd, hogy háromszor gyorsan!)
főleg olyan függőségekről fogunk beszélni, amelyeket nem irányítunk.
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ében képesnek kell lennünk közvetlenül beavatkozni és enyhíteni a problémákat.
az eltávolított függőségek esetében általában egy harmadik félre támaszkodhatunk, hogy gondoskodjon róla nekünk, mivel ezek is függenek.
miért jók a harmadik fél kódfüggőségei
a webes alkalmazás nagy része létezik a gyakori problémák megoldására: hitelesítés, Engedélyezés, adathozzáférés, hibakezelés, navigáció, naplózás, titkosítás, elemek listájának megjelenítése, űrlapbemenetek érvényesítése stb…
függetlenül attól, hogy melyik technológiai veremet használja, jó esély van arra, hogy közös megoldások léteznek ezekre a problémákra, és könnyen beszerezhető könyvtárakként érhetők el, és beépülhetnek a kódbázisba. A dolgok bármelyikének teljesen a semmiből történő írása általában időpocsékolás.
olyan kódra szeretne koncentrálni, amely vagy egy nem gyakori problémát old meg, vagy egy gyakori problémát nem gyakori módon old meg. Ez teszi az alkalmazást értékessé: a kód, amely végrehajtja az üzleti szabályokat, amelyek egyedül az Ön alkalmazására jellemzőek — a ” titkos szósz.”
a Google keresési és oldal rangsorolási algoritmusa, a Facebook idővonal— szűrése, a Netflix “Önnek ajánlott” szakasza és az adattömörítési algoritmusok-ezeknek a funkcióknak a kódja a “titkos szósz”.”
harmadik féltől származó kód-könyvtárak formájában — lehetővé teszi, hogy gyorsan megvalósítsa az alkalmazás árucikkeit, így a “titkos szószra” koncentrálhat.”
miért rosszak a harmadik fél kódfüggőségei?
vessen egy pillantást az elmúlt néhány évben épített nem triviális webalkalmazásokra, és teljesen megdöbbent a kód mennyisége, amely valójában egy harmadik fél könyvtárából származik. Mi van, ha egy vagy több ilyen harmadik féltől származó könyvtár drasztikusan megváltozik, eltűnik, vagy megszakad?
ha nyílt forráskódú, akkor talán maga is megjavíthatja. De mennyire érti az összes kódot abban a könyvtárban, amely nem a sajátja? Nagy oka annak, hogy elsősorban könyvtárat használ, az, hogy kihasználja a kód előnyeit anélkül, hogy minden részlet miatt aggódnia kellene. De most itt ragadtál. Teljesen összekapcsoltad a vagyonodat ezekkel a függőségekkel, amelyeket nem birtokolsz és nem irányítasz.
talán azt gondolja, hogy túlzok, vagy tisztán tudományos szempontból beszélek. Hadd biztosítsam önöket-több tucat példa van olyan ügyfelekre, akik teljesen snookered magukat azáltal, hogy harmadik féltől származó kódot túl szorosan beágyaznak az alkalmazásukba. Itt csak egy újabb példa…
egy korábbi ügyfelem építette az alkalmazást egy Backend-as-a-szolgáltató tulajdonában Facebook, az úgynevezett Parse. A Parse által biztosított JavaScript kliens könyvtárat használták az elemzési szolgáltatás fogyasztására. A folyamat 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ékbemutatója után-éppen akkor, amikor elkezdtek jó tapadást elérni a valódi, fizető ügyfelekkel-a Parse bejelentette, hogy leáll.
most ahelyett, hogy a termékük iterációjára és az ügyfélkör bővítésére összpontosítana, az Ügyfelemnek ki kellett találnia, hogyan lehet áttérni az elemzés saját üzemeltetésű, nyílt forráskódú verziójára, vagy teljesen kicserélni az elemzést.
a zavar ez okozott egy fiatal, fiatal alkalmazás olyan hatalmas volt, hogy az ügyfelem végül selejtezett az alkalmazás teljesen.
a jó és a rossz egyensúlya
néhány évvel ezelőtt a harmadik féltől származó könyvtárak előnyeinek megőrzése mellett a kockázatok leküzdésére szolgáló megoldásom az volt, hogy az Adaptermintával becsomagoltam őket.
lényegében a harmadik fél kódját egy írt adapterosztályba vagy modulba csomagolja. Ez akkor működik, hogy ki a funkciók a harmadik fél könyvtárak oly módon, hogy te irányítod.
ezzel a mintával, ha egy harmadik féltől származó könyvtár vagy keretrendszer megváltozik, vagy eltűnik, akkor csak egy kis illesztő kódot kell javítania. Az alkalmazás többi része sértetlen marad.
ez papíron jól hangzik. Ha önálló függőségei vannak, amelyek csak néhány funkciót biztosítanak, ez megteszi a trükköt. De a dolgok gyorsan eldurvulhatnak.
el tudod képzelni, hogy a teljes React könyvtárat (beleértve a JSX-et is) be kell tekerni, mielőtt használnád? Mit szólnál a jQuery, az Angular vagy a Spring framework csomagolásához Java-ban? Ez gyorsan rémálommá válik.
ezekben a napokban egy árnyaltabb megközelítést ajánlok…
minden függőséghez, amelyet hozzá szeretne adni a kódbázisához, értékelje a kockázat szintjét, amelyet két tényező szorzásával vezet be:
- annak valószínűsége, hogy a függőség anyagi módon megváltozik.
- az a kár összege, amelyet a függőség lényeges változása okozna az alkalmazásban.
egy harmadik féltől származó könyvtár vagy keretrendszer kevésbé valószínű, hogy megváltozik, ha az alábbi dolgok egy része vagy mindegyike igaz:
- már több éve létezik, és több nagy kiadása is volt.
- számos kereskedelmi alkalmazás széles körben használja.
- egy nagy szervezet — lehetőleg egy háztartási cég vagy intézmény-aktív támogatásával rendelkezik.
egy harmadik féltől származó könyvtár vagy keretrendszer kevesebb kárt okoz az alkalmazásban, ha a következő dolgok egy része vagy mindegyike igaz:
- csak az alkalmazás egy kis része használja, nem pedig az egész.
- az attól 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ódbázisban.
- a teljes alkalmazás nagyon kicsi és gyorsan átírható. (Legyen óvatos ezzel — ez ritkán igaz nagyon sokáig.)
minél kockázatosabb valami, annál valószínűbb, hogy becsomagolja vagy teljesen elkerüli.
amikor a kódot, amely valóban központi értékajánlatot az alkalmazás —a “titkos szósz” — meg kell, hogy rendkívül védő azt. Tegye ezt a kódot a lehető függetlenebbé. Ha feltétlenül függőségre van szüksége, fontolja meg az injekció beadását, ahelyett, hogy közvetlenül utalna rá. Akkor is légy óvatos.
néha ez azt jelenti, hogy “nem”-et kell mondani egy harmadik féltől származó könyvtárnak, amelyet nagyon jónak tart, vagy amelyet valamilyen okból valóban használni szeretne. Légy erős. Hidd el, kifizetődik. Csak kérdezze meg mindazokat az embereket, akik jelentős összegeket fektettek be az Angular legelső kiadásába, vagy volt ügyfelemet, aki mindenhol Parse-t használt. Nem vicces. Higgy nekem.
Apropó szórakozás, nézd meg ezt…
a fenti kép a TinyTag Explorer nevű alkalmazás függőségi grafikonja.
Függőségi grafikon létrehozása a meglévő alkalmazások számára nagyszerű módja annak, hogy megértsük a függőségek által bevezetett kockázati szintet. Összeállítottam egy listát az ingyenes eszközök generáló grafikonok hasonló a fenti különböző nyelveken, beleértve a JavaScript, C#, Java, PHP és Python. Itt beszerezheted.
Segíts nekem segíteni másoknak
szeretnék minél több fejlesztőnek segíteni azzal, hogy megosztom velük tudásomat és tapasztalataimat. Kérem, segítsen nekem, ha az alábbi (zöld szív) gombra kattint.
végül, ne felejtsd el, hogy megragad a listát a szabad függőség grafikon generátorok itt.