„změna je jediná konstanta …“ – Heraclitus (filozof)
nástroje, knihovny a rámce, které dnes používáme k vytváření našich webových aplikací, se drasticky liší od těch, které jsme použili před několika krátkými lety.
za několik krátkých let se většina těchto technologií opět dramaticky změní. Dosud, mnozí z nás z nich dělají Ústřední, neoddělitelná součást našich aplikací.
importujeme, používáme a zdědíme z rámců flavor-of-the-month, jako by všichni byli navždy a nezměněni. No … nejsou. A to je problém.
po více než 20 letech vývoje, navrhování a architektury webových aplikací jsem si uvědomil dvě důležité pravdy:
- externí závislosti představují velkou hrozbu pro dlouhodobou stabilitu a životaschopnost jakékoli aplikace.
- je stále obtížnější — ne — li nemožné-vytvořit jakýkoli druh netriviální aplikace bez využití externích závislostí.
tento článek je o sladění těchto dvou pravd tak, aby naše aplikace měly největší šanci na dlouhodobé přežití.
králičí nora je opravdu velmi hluboká.
pokud začneme přemýšlet o všech věcech, na kterých závisí naše webové aplikace, je snadné myslet na tucet nebo více, než se vůbec dostaneme ke kódu:
- napájení
- Konektivita
- Firewall
- DNS
- serverový Hardware (CPU, Disk, Ram, …)
- chlazení
- virtualizační platforma
- kontejnerová platforma
- operační systém
- platforma webového serveru
- app server platform
- webový prohlížeč
jako vývojáři je dobré si být těchto věcí vědom, ale často s nimi nemůžeme dělat mnoho. Takže je prozatím ignorujme a mluvme pouze o kódu.
v kódu existují tři druhy závislostí:
1. Závislosti kontrolujeme
Toto je kód napsaný a vlastněný námi nebo naší organizací.
2. Závislosti nekontrolujeme
Jedná se o kód napsaný dodavatelem třetí strany nebo komunitou softwaru s otevřeným zdrojovým kódem.
3. Závislosti po odstranění
Jedná se o závislosti kódu, na kterých závisí naše závislosti kódu třetích stran. (Řekni to třikrát rychle!)
budeme mluvit hlavně o závislostech, které neovládáme.
závislosti, které kontrolujeme, a závislosti po odstranění mohou stále způsobovat bolesti hlavy, ale v případě závislostí, které kontrolujeme, bychom měli být schopni přímo zasáhnout a zmírnit jakékoli problémy.
v případě závislostí po odstranění se obvykle můžeme spolehnout na třetí stranu, která se o ni postará, protože jsou na nich také závislí.
proč jsou závislosti na kódu třetích stran dobré
velká část vaší webové aplikace existuje k řešení běžných problémů: ověřování, autorizace, přístup k datům, zpracování chyb, navigace, protokolování, šifrování, zobrazení seznamu položek, ověřování vstupů formuláře atd…
bez ohledu na to, jakou technologii používáte, existuje velká šance, že existují společná řešení těchto problémů a jsou k dispozici jako knihovny, které můžete snadno získat a připojit k Vaší kódové základně. Psaní některé z těchto věcí úplně od nuly je obecně ztráta času.
chcete se soustředit na kód, který buď řeší neobvyklý problém, nebo řeší běžný problém neobvyklým způsobem. Díky tomu je vaše aplikace cenná: kód, který implementuje obchodní pravidla, která jsou jedinečná pouze pro vaši aplikaci — „tajná omáčka“.“
algoritmus vyhledávání a hodnocení stránek Google, filtrování časové osy Facebook, sekce Netflix“ doporučeno pro vás „a algoritmy komprese dat-kód za všemi těmito funkcemi je“ tajná omáčka.“
kód třetích stran – ve formě knihoven-umožňuje rychle implementovat tyto komoditizované funkce vaší aplikace, takže se můžete soustředit na svou „tajnou omáčku“.“
proč jsou závislosti třetích stran špatné
podívejte se na jakoukoli netriviální webovou aplikaci postavenou v posledních několika letech a budete naprosto ohromeni množstvím kódu, který skutečně pochází z knihovny třetích stran. Co když se jedna nebo více z těchto knihoven třetích stran drasticky změní, zmizí nebo se zlomí?
pokud je to open-source, možná to můžete opravit sami. Ale jak dobře rozumíte všem kódům v té knihovně, kterou nevlastníte? Velkým důvodem, proč používáte knihovnu na prvním místě, je získat výhody kódu, aniž byste se museli starat o všechny podrobnosti. Ale teď jsi uvízl. Zcela jste svázali své jmění s těmito závislostmi, které nevlastníte a neovládáte.
možná si myslíte, že přeháním, nebo mluvím z čistě akademického hlediska. Dovolte mi, abych vás ujistil-mám desítky příkladů klientů, kteří se úplně snookovali tím, že do své aplikace vložili kód třetích stran příliš těsně. Zde je jen jeden nedávný příklad…
bývalý můj klient postavil svou aplikaci pomocí poskytovatele Backend-as – a-Service vlastněného Facebook, s názvem Parse. Použili knihovnu klientů JavaScriptu poskytovanou společností Parse ke konzumaci služby Parse. V průběhu, pevně spojili veškerý svůj kód-včetně kódu“ tajné omáčky “ — s touto knihovnou.
tři měsíce po počátečním uvedení produktu mého klienta-stejně jako začali mít dobrou trakci se skutečnými platícími zákazníky-Parse oznámila, že se vypíná.
nyní místo toho, abych se soustředil na iteraci svého produktu a rozšiřování své zákaznické základny, musel můj klient přijít na to, jak buď migrovat na vlastní hostovanou, open-source verzi Parse, nebo úplně nahradit Parse.
narušení, které to způsobilo pro mladou, začínající aplikaci, bylo tak obrovské, že můj klient nakonec aplikaci úplně zrušil.
vyvažování dobrého a špatného
před několika lety bylo mým řešením pro překonání rizik při zachování výhod knihoven třetích stran zabalit je pomocí vzoru adaptéru.
v podstatě zabalíte kód třetí strany do třídy adaptéru nebo modulu, který jste napsali. To pak funguje tak, aby odhalilo funkce knihoven třetích stran způsobem, který ovládáte.
pomocí tohoto vzoru, pokud se Knihovna nebo rámec třetích stran změní nebo zmizí, stačí opravit trochu kódu adaptéru. Zbytek aplikace zůstane nedotčen.
to zní dobře na papíře. Pokud máte samostatné závislosti, které poskytují pouze několik funkcí,bude to stačit. Ale věci mohou být ošklivé rychle.
Dokážete si představit, že budete muset zabalit celou knihovnu React (včetně JSX), než ji použijete? Co takhle zabalit jQuery, nebo Angular, nebo jarní rámec v Javě? To se rychle stává noční můrou.
v těchto dnech doporučuji jemnější přístup …
pro každou závislost, kterou chcete přidat do své kódové základny, vyhodnoťte úroveň rizika, kterou zavede vynásobením dvou faktorů:
- pravděpodobnost, že se závislost změní materiálním způsobem.
- výše škody, kterou by podstatná změna závislosti způsobila vaší aplikaci.
knihovna nebo rámec třetích stran se méně pravděpodobně změní, pokud jsou některé nebo všechny následující věci pravdivé:
- existuje již několik let a má několik významných vydání.
- je široce používán mnoha komerčními aplikacemi.
- má aktivní podporu velké organizace-nejlépe společnosti nebo instituce s názvem domácnosti.
knihovna nebo rámec třetích stran způsobí menší poškození vaší aplikace, pokud jsou některé nebo všechny následující věci pravdivé:
- používá ji pouze malá část vaší aplikace, spíše než aby byla používána po celou dobu.
- kód, který na něm závisí, není součástí té „tajné omáčky“, o které jsem mluvil dříve.
- odstranění vyžaduje minimální změny v kódové základně.
- celá vaše aplikace je velmi malá a lze ji rychle přepsat. (Buďte opatrní s tímto – je to zřídka pravda velmi dlouho.)
čím je něco riskantnější, tím je pravděpodobnější, že byste to měli zabalit nebo se tomu úplně vyhnout.
pokud jde o kód, který je skutečně ústředním bodem hodnotového návrhu vaší aplikace – vaší „tajné omáčky“ — musíte ji velmi chránit. Udělejte ten kód co nejvíce nezávislý. Pokud nezbytně potřebujete použít závislost, zvažte její injekci, než ji přímo odkazovat. I tak buďte opatrní.
někdy to znamená říct“ ne “ knihovně třetích stran, o které si myslíte, že je opravdu skvělá, nebo kterou opravdu chcete použít z nějakého důvodu. Buďte silní. Věř mi, vyplatí se to. Stačí se zeptat všech těch lidí, kteří investovali do prvního vydání Angular, nebo mého bývalého klienta, který všude používal analýzu. Není to sranda. Věř mi.
když už mluvíme o zábavě, podívejte se na to…
obrázek výše je závislost graf pro aplikaci s názvem TinyTag Explorer.
generování grafu závislostí pro vaše stávající aplikace je skvělý způsob, jak pochopit úroveň rizika, kterou vaše závislosti představují. Sestavil jsem seznam bezplatných nástrojů pro generování grafů podobných výše uvedeným v různých jazycích, včetně JavaScriptu, C#, Java, PHP a Pythonu. Můžete to získat zde.
pomozte mi pomáhat ostatním
chci pomoci co největšímu počtu vývojářů sdílením svých znalostí a zkušeností s nimi. Prosím, pomozte mi kliknutím na tlačítko ❤ doporučit (zelené srdce) níže.
a konečně, nezapomeňte chytit svůj seznam volných závislostí graf generátory zde.