Závislosti na kódu jsou ďábel.

Vaše závislosti vás pokaždé spálí.
„Změna je jediná konstanta…“ - Heraclitus (filozof)

Nástroje, knihovny a rámce, které dnes používáme při vytváření našich webových aplikací, se výrazně liší od těch, které jsme používali před několika krátkými lety.

Za pár krátkých let se většina těchto technologií dramaticky změní. Mnozí z nás přesto dělají z ústřední, neoddělitelné části našich aplikací.

Dovážíme, používáme a zdědíme z rámců příchutí měsíce, jako by se všechny navždy udržovaly a nezměnily. No ... nejsou. A to je problém.

Po více než 20 letech vývoje, navrhování a architektury webových aplikací jsem ocenil dvě důležité pravdy:

  1. Vnější závislosti představují velkou hrozbu pro dlouhodobou stabilitu a životaschopnost jakékoli aplikace.
  2. Je stále obtížnější - ne-li nemožné - vytvořit jakýkoli druh netriviální aplikace bez využití vnějších závislostí.

Tento článek pojednává o sladění těchto dvou pravd, aby naše aplikace měly největší šanci na dlouhodobé přežití.

Králičí díra je opravdu velmi hluboká.

Pokud začneme přemýšlet o všech věcech, na nichž naše webové aplikace závisí, je snadné si představit tucet nebo více, než se dostaneme ke kódu:

  • Napájení
  • Připojení
  • Firewall
  • DNS
  • Hardware serveru (CPU, Disk, Ram,…)
  • Chlazení
  • Virtualizační platforma
  • Kontejnerová platforma
  • Operační systém
  • Platforma webového serveru
  • Platforma aplikačních serverů
  • Webový prohlížeč

Jako vývojáři je dobré vědět o těchto věcech, ale často s nimi nemůžeme nic dělat. Takže je prozatím ignorujte a mluvte pouze o kódu.

V kódu existují tři druhy závislostí:

1. Závislosti, které ovládáme

Toto je kód napsaný a vlastněný námi nebo naší organizací.

2. Závislosti, které nekontrolujeme

Toto je kód napsaný prodejcem třetí strany nebo komunitou softwaru s otevřeným zdrojovým kódem.

3. Závislosti po odstranění

Toto jsou závislosti na kódu, na kterých závisí naše závislost na kódech třetích stran. (Řekněte, že třikrát rychle!)

Budeme mluvit hlavně o závislostech, které nemáme pod kontrolou.

Závislosti, které kontrolujeme, a závislosti, jakmile jsou odstraněny, 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ě odstraněných závislostí se obvykle můžeme spolehnout na to, že se o nás postará třetí strana, protože na nich také závisí.

Proč jsou závislé kódy třetích stran dobré

Velká část vaší webové aplikace existuje k řešení běžných problémů: autentizace, autorizace, přístup k datům, zpracování chyb, navigace, protokolování, šifrování, zobrazení seznamu položek, ověření vstupů do formulářů atd. ...

Bez ohledu na to, který technologický zásobník používáte, existuje velká šance, že společná řešení těchto problémů existují, a jsou k dispozici jako knihovny, které můžete snadno získat a připojit se ke své kódové základně. Psaní kterékoli z těchto věcí úplně od nuly je obvykle 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í Google a hodnocení stránek, filtrování časové osy Facebooku, sekce „doporučeno pro vás“ Netflixu 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 aplikace, takže se můžete soustředit na svou „tajnou omáčku“.

Proč jsou závislé kódy třetích stran špatné

Podívejte se na jakoukoli netriviální webovou aplikaci vytvořenou v posledních několika letech a budete absolutně 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í nebo zmizí nebo přestane fungovat?

Pokud je to open-source, možná to můžete opravit sami. Ale jak dobře chápete všechny kódy v knihovně, kterou nevlastníte? Velkým důvodem, proč používáte knihovnu v první řadě, je získat výhody kódu, aniž byste se museli starat o všechny podrobnosti. Ale teď jsi zaseknutý. Úplně jste svázali své štěstí s těmito závislostmi, které nevlastníte a neovládáte.

Nebojte se, do konce tohoto článku najdete novou naději.

Možná si myslíte, že přehání, nebo mluvím z ryze akademického hlediska. Ujišťuji vás - mám desítky příkladů klientů, kteří se zcela snookrovali tím, že do své aplikace vložili kód třetí strany příliš těsně. Zde je jen jeden nedávný příklad…

Bývalý můj klient postavil svou aplikaci pomocí poskytovatele služby Backend-as-a-Service ve vlastnictví Facebooku, který se jmenoval Parse. Ke spotřebě služby Parse použili klientskou knihovnu JavaScriptu poskytovanou společností Parse. V průběhu procesu pevně spojili všechny své kódy - včetně kódu „tajné omáčky“ - s touto knihovnou.

Tři měsíce po prvním uvedení produktu na trh mého klienta - právě když začali dostávat dobrou trakci se skutečnými platícími zákazníky - Parse oznámil, že se to zastavuje.

Nyní se místo toho, aby se soustředil na iteraci svých produktů a rozšiřování zákaznické základny, musel můj klient přijít na to, jak migrovat na samo hostovanou, open-source verzi Parse, nebo úplně Parse vyměnit.

Narušení, které to způsobilo pro mladou, rodící se aplikaci, bylo tak obrovské, že můj klient nakonec aplikaci úplně vyřadil.

Vyvažování dobrého a špatného

Před několika lety bylo mým řešením zaměřeným na překonání rizik při zachování výhod knihoven třetích stran jejich zabalení pomocí 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, že odhalíte funkce knihoven třetích stran způsobem, který ovládáte.

Pokud použijete tento vzor, ​​změníte-li nebo odejde knihovna nebo rámec třetích stran, stačí opravit jen kousek kódu adaptéru. Zbytek aplikace zůstane nedotčen.

Schéma adaptéru z Dofactory.com

To zní dobře na papíře. Pokud máte samostatné závislosti, které poskytují pouze několik funkcí, bude to trik. 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 Spring framework do Java? To se rychle stává noční můrou.

V těchto dnech doporučuji více odstupňovaný přístup ...

Pro každou závislost, kterou chcete přidat do své kódové základny, vyhodnoťte míru rizika, kterou přinese, vynásobením dvou faktorů:

  1. Pravděpodobnost, že se tato závislost významně změní.
  2. Velikost škody, kterou by materiální 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é:

  • Bylo to již několik let a mělo několik hlavních vydání.
  • Je široce používán mnoha komerčními aplikacemi.
  • Má aktivní podporu velké organizace - nejlépe společnosti nebo instituce pro domácnost.

Knihovna nebo rámec třetích stran způsobí menší poškození vaší aplikace, pokud jsou splněny některé nebo všechny následující věci:

  • Používá ji pouze malá část aplikace, než aby se používala v celém textu.
  • Kód, který závisí na tom, není součástí té „tajné omáčky“, o které jsem mluvil dříve.
  • Jeho odstranění vyžaduje minimální změny vaší kódové základny.
  • Celá vaše aplikace je velmi malá a lze ji rychle přepsat. (Buďte opatrní s tímto - je to zřídka pravda po velmi dlouhou dobu.)

Čím je něco rizikovější, tím je pravděpodobnější, že ho zabalíte nebo se mu úplně vyhnete.

Pokud jde o kód, který je skutečně ústředním prvkem hodnotné nabídky vaší aplikace - vaší „tajné omáčky“ - musíte ji velmi chránit. Aby byl tento kód co nejnezávislejší. Pokud absolutně potřebujete použít závislost, zvažte její aplikaci, nikoli přímý odkaz. I přesto buďte opatrní.

Někdy to znamená říci „ne“ knihovně třetí strany, o které si myslíte, že je opravdu super, nebo že ji opravdu chcete použít z nějakého důvodu. Být silný. Věř mi, vyplatí se to. Zeptejte se všech lidí, kteří investovali velké prostředky do prvního vydání Angular, nebo mého bývalého klienta, který Parse používal všude. Není to žádná sranda. Věř mi.

Když už mluvíme o zábavě, podívej se na to ...

Graf závislosti pro průzkumníka TinyTag

Obrázek nahoře je graf závislosti aplikace nazvané Průzkumník TinyTag.

Vytvoření grafu závislostí pro vaše stávající aplikace je skvělý způsob, jak porozumět úrovni rizika, které 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 Python. Můžete to získat zde.

Pomozte mi pomoci ostatním

Chci pomáhat co nejvíce vývojářům, jak mohu, 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.

Nakonec nezapomeňte vzít svůj seznam generátorů grafů závislosti zdarma zde.