Alati, knjižnice i okviri koje danas koristimo za izgradnju naših web aplikacija drastično se razlikuju od onih koje smo koristili prije samo nekoliko kratkih godina.
Za nekoliko kratkih godina, većina tih tehnologija opet će se dramatično promijeniti. Ipak, mnogi od nas čine ovaj središnji, neraskidivi dio svojih aplikacija.
Uvozimo, koristimo i nasljeđujemo iz okvira okusa mjeseca kao da će svi oni biti zauvijek i nepromijenjeni. Pa ... nisu. I to je problem.
Nakon više od 20 godina razvoja, dizajniranja i dizajniranja web aplikacija, shvatio sam dvije važne istine:
- Vanjske ovisnosti predstavljaju veliku prijetnju dugoročnoj stabilnosti i održivosti bilo koje aplikacije.
- Sve je teže - ako ne i nemoguće - izraditi bilo kakvu netrivijalnu aplikaciju bez iskorištavanja vanjskih ovisnosti.
Ovaj je članak o pomirenju ove dvije istine tako da naše aplikacije imaju najveće šanse za dugoročno preživljavanje.
Zečja rupa je zaista jako duboka.
Ako počnemo razmišljati o svim stvarima o kojima ovise naše web aplikacije, lako ćemo se sjetiti desetak ili više prije nego što uopće dođemo do koda:
- Vlast
- Povezivost
- Vatrozid
- DNS
- Poslužiteljski hardver (CPU, disk, ram, ...)
- Hlađenje
- Platforma za virtualizaciju
- Kontejnerska platforma
- Operacijski sustav
- Platforma web poslužitelja
- Platforma poslužitelja aplikacija
- Web-preglednik
Kao programeri, dobro je biti svjestan tih stvari, ali često s njima ne možemo puno učiniti. Dakle, zanemarimo ih za sada i razgovarajmo samo o kodu.
U kodu postoje tri vrste ovisnosti:
1. Ovisnosti koje kontroliramo
Ovo je kod koji smo napisali i u vlasništvu nas ili naše organizacije.
2. Ovisnosti koje ne kontroliramo
Ovo je kod koji je napisao dobavljač treće strane ili softverska zajednica otvorenog koda.
3. Jednom uklonjene ovisnosti
To su ovisnosti koda o kojima ovise naše ovisnosti koda. (Recite to tri puta brzo!)
Govorit ćemo uglavnom o ovisnostima koje ne kontroliramo .
Ovisnosti koje kontroliramo i ovisnosti koje se jednom uklone i dalje mogu uzrokovati glavobolje, ali u slučaju ovisnosti koje kontroliramo trebali bismo biti u mogućnosti izravno intervenirati i ublažiti sve probleme.
U slučaju uklanjanja ovisnosti, obično se možemo osloniti na treću stranu koja će se za nas pobrinuti, jer i one ovise o njima.
Zašto su ovisnosti koda treće strane dobre
Veliki dio vaše web aplikacije postoji za rješavanje uobičajenih problema: provjera autentičnosti, autorizacija, pristup podacima, rukovanje pogreškama, navigacija, evidentiranje, šifriranje, prikazivanje popisa stavki, provjera valjanosti unosa u obrazac i tako dalje ...
Bez obzira na to koji stek tehnologije upotrebljavate, velika je vjerojatnost da postoje uobičajena rješenja za te probleme i dostupni su kao knjižnice koje možete lako nabaviti i priključiti na svoju bazu koda. Potpuno pisanje bilo čega od ovih stvari u pravilu je gubljenje vremena.
Želite se koncentrirati na kod koji rješava neuobičajeni problem ili rješava uobičajeni problem na neuobičajen način. To je ono što vašu aplikaciju čini vrijednom: kôd koji implementira poslovna pravila koja su jedinstvena samo za vašu aplikaciju - "tajni umak".
Googleov algoritam pretraživanja i rangiranja stranica, Facebook filtriranje vremenske trake, Netflixov odjeljak "preporučljivo za vas" i algoritmi kompresije podataka - kod svih ovih značajki stoji "tajni umak".
Kôd treće strane - u obliku knjižnica - omogućuje vam brzu implementaciju tih komodiziranih značajki vaše aplikacije, tako da možete ostati usredotočeni na svoj „tajni umak“.
Zašto su ovisnosti koda treće strane loše
Pogledajte bilo koju netrivijalnu web-aplikaciju izrađenu u posljednjih nekoliko godina i bit ćete apsolutno zaprepašteni količinom koda koji zapravo dolazi iz biblioteke treće strane. Što ako se jedna ili više tih biblioteka trećih strana drastično promijene ili nestanu ili se pokvare?
Ako je open source, možda ga možete sami popraviti. Ali koliko dobro razumijete sav kod u toj knjižnici koju ne posjedujete? Veliki razlog zašto uopće upotrebljavate knjižnicu je da biste iskoristili blagodati koda bez brige o svim detaljima. Ali sad si zapeo. Potpuno ste vezali svoje bogatstvo za ove ovisnosti koje ne posjedujete i ne kontrolirate.
Možda mislite da pretjerujem ili govorim s čisto akademskog gledišta. Uvjeravam vas - imam na desetke primjera klijenata koji su se potpuno prikrali ugrađivanjem koda treće strane u svoju aplikaciju. Evo samo jednog nedavnog primjera ...
Bivši moj klijent izradio je svoju aplikaciju koristeći pružatelja usluga Backend-as-a-a-Service u vlasništvu Facebooka, nazvanog Parse. Koristili su knjižnicu JavaScript klijenta koju je pružio Parse za konzumiranje usluge Parse. U tom su procesu čvrsto povezali sav svoj kôd - uključujući i kod "tajnog umaka" - s ovom knjižnicom.
Tri mjeseca nakon početnog lansiranja proizvoda mog klijenta - baš kad su počeli dobivati dobru vuču kod stvarnih kupaca - Parse je najavio da se gasi.
Sada, umjesto da se usredotoči na ponavljanje njihovog proizvoda i rast baze kupaca, moj je klijent morao smisliti kako ili preći na samostalnu verziju Parsea s otvorenim kodom ili potpuno zamijeniti Parse.
Prekid koji je to prouzročio za mladu, novonastalu aplikaciju bio je tako velik da je moj klijent na kraju u potpunosti ukinuo aplikaciju.
Balansiranje dobrog i lošeg
Prije nekoliko godina, moje rješenje za prevladavanje rizika uz zadržavanje blagodati neovisnih knjižnica bilo je umotavanje pomoću uzoraka adaptera.
U osnovi, omot treće strane omotate u klasu ili modul adaptora koji ste napisali. To onda djeluje na izlaganje funkcija knjižnica nezavisnih proizvođača na način koji vi kontrolirate.
Koristeći ovaj obrazac, ako se biblioteka ili okvir treće strane promijeni ili nestane, trebate popraviti samo malo prilagodničkog koda. Ostatak aplikacije ostaje netaknut.
Ovo dobro zvuči na papiru. Kada imate samostalne ovisnosti koje pružaju samo nekoliko funkcija, to će učiniti trik. Ali stvari mogu brzo postati ružne.
Možete li zamisliti da morate omotati cijelu knjižnicu React (uključujući JSX) prije nego što je koristite? Što kažete na umotavanje jQueryja, Angular-a ili Spring Springa u Javu? Ovo brzo postane noćna mora.
Ovih dana preporučujem nijansiraniji pristup ...
Za svaku ovisnost koju želite dodati u svoju bazu kodova, procijenite razinu rizika koju će uvesti množenjem dva faktora:
- Vjerojatnost da će se ovisnost promijeniti na materijalni način.
- Iznos štete koja bi materijalnoj promjeni ovisnosti nanijela vašoj prijavi.
Biblioteka ili okvir treće strane manje je vjerojatan da će se promijeniti kada su neke ili sve sljedeće stvari istinite:
- Postoji već nekoliko godina i imao je nekoliko glavnih izdanja.
- Široko se koristi u mnogim komercijalnim aplikacijama.
- Ima aktivnu podršku velike organizacije - po mogućnosti tvrtke s imenom ili institucijom s imenom kućanstva.
Biblioteka ili okvir treće strane nanijet će manju štetu vašoj aplikaciji kada su istinite neke ili sve sljedeće stvari:
- Koristi ga samo mali dio vaše aplikacije, umjesto da se koristi u cijelosti.
- Kôd koji o njemu ovisi nije dio tog "tajnog umaka" o kojem sam ranije govorio.
- Uklanjanje zahtijeva minimalne promjene na vašoj bazi koda.
- Čitava vaša aplikacija vrlo je mala i može se brzo prepisati. (Budite oprezni s ovom - to rijetko vrijedi jako dugo.)
Što je nešto rizičnije, to je veća vjerojatnost da biste to zamotali ili uopće izbjegli.
Kada je riječ o kodu koji je doista presudan za vrijednosni prijedlog vaše aplikacije - vaš „tajni umak“ - morate ga izuzetno zaštititi. Neka taj kod bude što neovisniji. Ako apsolutno trebate koristiti ovisnost, razmislite o ubrizgavanju umjesto da je izravno referencirate. Čak i tada, budite oprezni.
Ponekad to znači reći "ne" biblioteci treće strane za koju mislite da je stvarno cool ili koju stvarno želite koristiti iz jednog ili drugog razloga. Biti jak. Vjerujte mi, isplatit će se. Samo pitajte sve one ljude koji su jako uložili u prvo izdanje Angulala ili mog bivšeg klijenta koji je svugdje koristio Parse. Nije zabavno. Vjeruj mi.
Kad smo već kod zabave, pogledajte ovo ...
Gornja slika je graf ovisnosti za aplikaciju nazvanu TinyTag Explorer.
Stvaranje grafikona ovisnosti za vaše postojeće aplikacije izvrstan je način da shvatite razinu rizika koju vaše ovisnosti unose. Sastavio sam popis besplatnih alata za generiranje grafikona sličnih gore navedenim na raznim jezicima, uključujući JavaScript, C #, Java, PHP i Python. Možete ga dobiti ovdje.
Pomozi mi da pomognem drugima
Želim pomoći što većem broju programera dijeleći svoje znanje i iskustvo s njima. Molimo vas da mi pomognete klikom na gumb ❤ preporuči (zeleno srce) ispod.
Napokon, ne zaboravite ovdje uzeti svoj popis besplatnih generatora grafova ovisnosti.