«Change is the only constant…» – Heraclitus (Filosof)
verktøyene, bibliotekene og rammene vi bruker til å bygge våre webapplikasjoner i dag, er drastisk forskjellige fra de vi brukte bare noen få korte år siden.
om noen få år fra nå vil de fleste av disse teknologiene ha endret seg dramatisk igjen. Ennå, mange av oss gjør disse en sentral, uløselig del av våre apps.
vi importerer, bruker Og arver fra smaken av måneden som om de alle kommer til å være rundt og uendret for alltid. Vel … det er de ikke. Og det er et problem.
etter 20 + år med utvikling, design og arkitektur webapplikasjoner, har jeg kommet til å sette pris på to viktige sannheter:
- Eksterne avhengigheter utgjør en stor trussel mot langsiktig stabilitet og levedyktighet av enhver applikasjon.
- det er stadig vanskeligere – om ikke umulig – å bygge noen form for ikke-triviell app uten å utnytte eksterne avhengigheter.
denne artikkelen handler om å forene disse to sannhetene slik at våre apper har størst sjanse for langsiktig overlevelse.
kaninhullet er veldig dypt faktisk.
hvis vi begynner å tenke på alle de tingene våre web apps avhenge det er lett å tenke på et dusin eller mer før vi selv komme til koden:
- Strøm
- Tilkobling
- Brannmur
- DNS
- Servermaskinvare (CPU, Disk, Ram, …)
- Kjøling
- Virtualiseringsplattform
- Beholderplattform
- operativsystem
- Webserverplattform
- App Serverplattform
- nettleser
Som Utviklere Er Det Godt Å Være Klar Over Disse Tingene, Men Det Er Ofte Ikke Mye Vi Kan Gjøre Med Dem. Så, la oss ignorere dem for nå og snakk bare om koden.
i kode er det tre typer avhengigheter:
1. Avhengigheter vi kontrollerer
dette er kode skrevet og eid av oss eller vår organisasjon.
2. Avhengigheter vi ikke kontrollerer
dette er kode skrevet av en tredjepartsleverandør eller programvaresamfunn med åpen kildekode.
3. Avhengigheter en gang fjernet
dette er kodeavhengighetene våre tredjeparts kodeavhengigheter avhenger av. (Si det tre ganger fort!)
vi skal snakke hovedsakelig om avhengigheter vi ikke kontrollerer.
Avhengigheter vi kontrollerer og avhengigheter når de er fjernet, kan fortsatt forårsake hodepine, men i tilfelle avhengigheter vi kontrollerer, bør vi kunne gripe inn og redusere eventuelle problemer direkte.
i tilfelle avhengigheter en gang fjernet, kan vi vanligvis stole på en tredjepart for å ta vare på det for oss, siden de er avhengige av disse også.
hvorfor tredjeparts kodeavhengigheter er gode
En stor del av webapplikasjonen din eksisterer for å løse vanlige problemer: godkjenning, autorisasjon, datatilgang, feilhåndtering, navigasjon, logging, kryptering, vise en liste over elementer, validere skjema innganger, og så videre…
Uansett hvilken teknologistabel du bruker, er det en god sjanse for at vanlige løsninger på disse problemene eksisterer, og er tilgjengelige som biblioteker som du enkelt kan skaffe og plugge inn i kodebasen. Å skrive noe av dette helt fra bunnen av er vanligvis sløsing med tid.
du vil konsentrere deg om kode som enten løser et uvanlig problem eller løser et vanlig problem på en uvanlig måte. Det er det som gjør din søknad verdifull: koden som implementerer forretningsregler som er unike for din app alene – » secret saus.»
Googles søke-og siderangeringsalgoritme, Facebook ‘s tidslinjefiltrering, Netflix ‘s» anbefalt for deg «- seksjon og datakomprimeringsalgoritmer-koden bak alle disse funksjonene er » secret sauce.»
tredjepartskode — i form av biblioteker-lar deg raskt implementere de commoditized funksjonene i appen din, slik at du kan holde fokus på din «hemmelige saus».»
hvorfor tredjeparts kodeavhengigheter er dårlige
Ta en titt på noen ikke-trivielle web-app bygget de siste par årene, og Du vil bli helt forbløffet over mengden kode som faktisk kommer fra et tredjepartsbibliotek. Hva om ett eller flere av disse tredjepartsbibliotekene endres drastisk, forsvinner eller går i stykker?
hvis det er åpen kildekode, kan du kanskje fikse det selv. Men hvor godt forstår du all koden i det biblioteket du ikke eier? En stor grunn til at du bruker et bibliotek i utgangspunktet er å få fordelene med koden uten å måtte bekymre deg for alle detaljene. Men nå sitter du fast. Du har helt bundet din formue til disse avhengighetene som du ikke eier og ikke kontrollerer.
kanskje du tror jeg overdriver, eller snakker fra et rent akademisk synspunkt. La meg forsikre deg-jeg har dusinvis av eksempler på klienter som helt snookered seg ved å legge inn tredjepartskode for tett inn i appen deres. Her er bare ett nylig eksempel…
en tidligere klient av meg bygget sin app ved hjelp Av En Backend-as-A-Service-leverandør eid Av Facebook, kalt Parse. De brukte Et JavaScript-klientbibliotek levert Av Parse for å konsumere Parse-tjenesten. I prosessen koblet de tett all sin kode-inkludert» secret sauce » – koden – til dette biblioteket.
Tre måneder Etter kundens første produktlansering — akkurat som de begynte å få litt god trekkraft med ekte, betalende kunder-Annonserte Parse at det ble stengt.
nå i stedet for å fokusere på å iterere på sitt produkt og vokse sin kundebase, måtte klienten min finne ut hvordan man enten kan migrere til en egenvert, åpen kildekode-versjon av Parse, eller erstatte Parse helt.
forstyrrelsen dette forårsaket for en ung, fledgling søknad var så stor at klienten min til slutt slettet appen helt.
Balansering av det gode og det dårlige
For Flere år siden var min løsning for å overvinne risikoen samtidig som fordelene med tredjepartsbiblioteker var å pakke dem inn ved Hjelp Av Adaptermønsteret.
I Hovedsak pakker du tredjepartskoden i en adapterklasse eller modul som du har skrevet. Dette fungerer da for å avsløre funksjonene til tredjepartsbiblioteker på en måte som du kontrollerer.
Ved hjelp av dette mønsteret, hvis et tredjepartsbibliotek eller rammeverk endres, eller går bort, trenger du bare å fikse litt adapterkode. Resten av appen forblir intakt.
dette høres bra ut på papir. Nar du har selvstendige avhengigheter som bare gir noen fa funksjoner, vil dette gjore trikset. Men ting kan bli stygge fort.
kan du forestille deg å måtte pakke hele React-biblioteket (inkludert JSX) før du bruker noe av det? Hva med å pakke jQuery, Eller Angular, Eller Vårrammen I Java? Dette blir raskt et mareritt.
I Disse dager anbefaler Jeg en mer nyansert tilnærming…
for hver avhengighet du vil legge til i kodebasen din, vurder risikonivået det vil introdusere ved å multiplisere to faktorer:
- sannsynligheten for at avhengigheten vil endres på en materiell måte.
- mengden skade en materiell endring i avhengigheten ville gjøre for søknaden din.
det er mindre sannsynlig at et tredjepartsbibliotek eller-rammeverk endres når noen eller alle av følgende ting er sanne:
- Det har eksistert i flere år og har hatt flere store utgivelser.
- Det er mye brukt av mange kommersielle applikasjoner.
- Den har aktiv støtte fra en stor organisasjon-helst et husstandsnavn eller en institusjon.
et tredjepartsbibliotek eller rammeverk vil gjøre mindre skade på søknaden din når noen eller alle av følgende ting er sanne:
- Den brukes bare av en liten del av søknaden din, i stedet for å bli brukt i hele.
- koden som avhenger av den, er ikke en del av den «hemmelige sausen» jeg snakket om tidligere.
- Fjerning av det krever minimale endringer i kodebasen.
- hele programmet er svært liten og kan omskrives raskt. (Vær forsiktig med denne – det er sjelden sant for veldig lenge.)
jo mer risikofylt noe er, jo mer sannsynlig bør du være å pakke det eller unngå det helt.
når det gjelder koden som er veldig sentral i verdiforslaget til søknaden din —din «hemmelige saus» — må du være ekstremt beskyttende for den. Gjør denne koden så uavhengig som mulig. Hvis du absolutt trenger å bruke en avhengighet, bør du vurdere å injisere det i stedet for å referere det direkte. Selv da, vær forsiktig.
noen ganger betyr dette å si» nei » til et tredjepartsbibliotek du synes er veldig kult, eller at du virkelig vil bruke av en eller annen grunn. Vær sterk. Stol på meg, det vil lønne seg. Bare spør alle de menneskene som investerte tungt i Den aller første utgivelsen Av Angular, eller min tidligere klient som brukte Parse overalt. Det er ikke gøy. Tro meg.
Når du snakker om moro, ta en titt på dette…
bildet ovenfor er avhengighetsgrafen for et program kalt TinyTag Explorer.
Å Generere en avhengighetsgraf for dine eksisterende apper er en fin måte å forstå risikonivået som blir introdusert av avhengighetene dine. Jeg har satt sammen en liste over gratis verktøy for å generere grafer som ligner på ovennevnte på En rekke språk, inkludert JavaScript, C#, Java, PHP og Python. Du kan få det her.
Hjelp meg å hjelpe andre
jeg vil hjelpe så mange utviklere som mulig ved å dele min kunnskap og erfaring med dem. Vennligst hjelp meg ved å klikke på anbefal-knappen (grønt hjerte) nedenfor.
Til Slutt, ikke glem å ta tak i listen over gratis avhengighetsgrafgeneratorer her.