Koodiriippuvuudet ovat piru.

Riippuvuutesi polttavat sinut joka kerta.
”Muutos on ainoa vakio…” - Heraclitus (filosofi)

Työkalut, kirjastot ja kehykset, joita käytämme tänään verkkosovellusten luomiseen, eroavat huomattavasti niistä, joita käytimme vain muutama vuosi sitten.

Muutaman lyhyen vuoden kuluttua suurin osa näistä tekniikoista on muuttunut dramaattisesti uudelleen. Silti monet meistä tekevät niistä keskeisen, erottamattoman osan sovelluksistamme.

Tuomme, käytämme ja perimme kuukauden makukehyksiä ikään kuin ne kaikki olisivat ympärilläsi ja muuttumattomina ikuisesti. No ... he eivät ole. Ja se on ongelma.

Yli 20 vuoden ajan web-sovellusten kehittämisen, suunnittelun ja arkkitehtuurin jälkeen olen tullut arvostamaan kahta tärkeää totuutta:

  1. Ulkoiset riippuvuussuhteet ovat suuri uhka minkä tahansa sovelluksen vakaudelle ja elinkelpoisuudelle.
  2. On yhä vaikeampaa - ellei mahdotonta - rakentaa minkäänlaista ei-triviaalia sovellusta hyödyntämättä ulkoisia riippuvuuksia.

Tämä artikkeli koskee näiden kahden totuuden täsmäyttämistä siten, että sovelluksillamme on parhaat mahdollisuudet pysyä hengissä.

Kani reikä on todellakin hyvin syvä.

Jos alamme ajatella kaikkia asioita, joita verkkosovelluksemme riippuvat, on helppo ajatella kymmenen tai enemmän, ennen kuin edes pääset koodiin:

  • teho
  • liitettävyys
  • palomuuri
  • DNS
  • Palvelinlaitteistot (CPU, levy, RAM,…)
  • Jäähdytys
  • Virtualisointiympäristö
  • Konttilava
  • Käyttöjärjestelmä
  • Web-palvelinalusta
  • Sovelluspalvelin-alusta
  • Nettiselain

Kehittäjinä on hyvä olla tietoinen näistä asioista, mutta emme yleensä voi tehdä niissä paljon. Joten jätetään huomioimatta ne nyt ja puhutaan vain koodista.

Koodissa on kolmen tyyppisiä riippuvuuksia:

1. Hallitsemme riippuvuudet

Tämä on kirjoittama koodi, jonka omistamme me tai organisaatiomme.

2. Riippuvuudet, joita emme hallitse

Tämän koodin on kirjoittanut ulkopuolinen toimittaja tai avoimen lähdekoodin ohjelmistoyhteisö.

3. Riippuvuudet poistettuaan

Nämä ovat koodiriippuvuudet, joista kolmannen osapuolen koodiriippuvuudet riippuvat. (Sano se kolme kertaa nopeasti!)

Aiomme puhua lähinnä riippuvuuksista, joita emme hallitse.

Hallitsemme riippuvuudet ja poistetut riippuvuudet voivat silti aiheuttaa päänsärkyä, mutta hallitsemissamme riippuvuuksissa meidän on kyettävä puuttumaan suoraan ja vähentämään mahdollisia ongelmia.

Korvattujen riippuvuuksien tapauksessa voimme yleensä luottaa siihen, että kolmas osapuoli huolehtii siitä meidän puolestamme, koska he ovat myös riippuvaisia ​​näistä.

Miksi kolmansien osapuolien koodiriippuvuudet ovat hyviä

Suuri osa verkkosovelluksestasi on olemassa yleisten ongelmien ratkaisemiseksi: todentaminen, valtuuttaminen, tietojen käyttö, virheiden käsittely, navigointi, kirjaaminen, salaus, kohteiden luettelon näyttäminen, lomakkeiden vahvistaminen ja niin edelleen ...

Riippumatta siitä, mitä tekniikkapinoa käytät, on olemassa suuri mahdollisuus, että näihin ongelmiin on olemassa yhteisiä ratkaisuja, ja ne ovat saatavana kirjastoina, joita voit helposti hankkia ja liittää kooditietokantaan. Kaikkien näiden kirjoittaminen kokonaan tyhjästä on yleensä ajanhukkaa.

Haluat keskittyä koodiin, joka joko ratkaisee epätavallisen ongelman tai ratkaisee yleisen ongelman epätavallisella tavalla. Siksi sovelluksesi on arvokas: koodi, joka toteuttaa pelkästään sovelluksellesi ominaiset yrityssäännöt - ”salainen kastike”.

Googlen haku- ja sivujärjestysalgoritmi, Facebookin aikajanan suodatus, Netflixin ”suositellaan sinulle” -osa ja tietojen pakkausalgoritmit - kaikkien näiden ominaisuuksien takana oleva koodi on “salainen kastike”.

Kolmannen osapuolen koodi - kirjastojen muodossa - antaa sinun ottaa nopeasti käyttöön sovelluksesi nämä hyödynnetyt ominaisuudet, joten voit keskittyä "salaisuuteen".

Miksi kolmansien osapuolien koodiriippuvuudet ovat huonoja

Tutustu kaikkiin viimeisten muutaman vuoden aikana rakennettuihin ei-triviaaleihin verkkosovelluksiin, ja olet todella hämmästynyt siitä, kuinka paljon koodia kolmannen osapuolen kirjastosta tulee. Entä jos yksi tai useampi näistä kolmannen osapuolen kirjastoista muuttuu rajusti, häviää tai hajoaa?

Jos se on avoimen lähdekoodin versio, voit ehkä korjata sen itse. Mutta kuinka hyvin ymmärrät kaikki koodit siinä kirjastossa, jota et omista? Suuri syy siihen, miksi käytät kirjastoa, on ensin saada koodin edut tarvitsematta huolehtia kaikista yksityiskohdista. Mutta nyt olet jumissa. Olet sidonut omaisuutesi täysin näihin riippuvuuksiin, joita et omista tai joita et hallitse.

Älä huoli, tämän artikkelin loppuun mennessä löydät uuden toivon.

Ehkä luulet liioittelevani tai puhun puhtaasti akateemisesta näkökulmasta. Vakuutan teille - minulla on kymmeniä esimerkkejä asiakkaista, jotka snookeriavat itsensä täysin upottamalla kolmannen osapuolen koodin liian tiukasti sovellukseensa. Tässä on vain yksi viimeaikainen esimerkki ...

Entinen asiakkaani rakensi sovelluksensa käyttämällä Facebookin omistamaa Backend-as-a-Service-palveluntarjoajaa, nimeltään Parse. He käyttivät Parse-palvelun tarjoamista JavaScript-asiakaskirjastoa kuluttamaan Parse-palvelua. Prosessissa he kytkeivät tiukasti kaikki koodinsa - mukaan lukien “salainen kastike” -koodin - tähän kirjastoon.

Kolme kuukautta asiakkaani alkuperäisen tuotelanseerauksen jälkeen - aivan kuin he alkoivat saada hyvää pitoa todellisten, maksavien asiakkaiden kanssa - Parse ilmoitti sulkevansa.

Nyt sen sijaan, että keskittyisin tuotteisiinsa iterointiin ja asiakaskunnan kasvattamiseen, asiakkaani piti miettiä, miten siirtyä itse isännöimään avoimen lähdekoodin Parse-versioon tai korvata Parse kokonaan.

Tämä häiriö nuorelle, aloittelevalle sovellukselle oli niin valtava, että asiakkaani lopulta romutti sovelluksen kokonaan.

Hyvän ja pahan tasapainottaminen

Useita vuosia sitten ratkaisuni riskeistä poistamiseen säilyttäen kolmansien osapuolien kirjastojen edut oli kääri ne Adapter Pattern -sovelluksella.

Käärität kolmannen osapuolen koodin kirjoittamasi adapteriluokkaan tai moduuliin. Tämä paljastaa sitten kolmannen osapuolen kirjastojen toiminnot hallitsemallasi tavalla.

Tätä mallia käyttämällä, jos kolmannen osapuolen kirjasto tai kehys muuttuu tai häviää, sinun on korjattava vain vähän sovitinkoodia. Loppuosa sovelluksestasi pysyy ehjänä.

Sovitinkuviokaavio Dofactory.com-sivustolta

Tämä kuulostaa hyvältä paperilla. Kun sinulla on itsenäisiä riippuvuuksia, jotka tarjoavat vain muutaman toiminnon, tämä tekee tempun. Mutta asiat voivat muuttua rumaksi nopeasti.

Voitteko kuvitella, että sinun tulee kääriä koko React-kirjasto (mukaan lukien JSX) ennen minkään käyttämistä? Entä JavaScriptin jQuery, Angular tai Spring -kehyksen kääriminen? Tästä tulee nopeasti painajainen.

Nykyään suosittelen vivaikkaampaa lähestymistapaa ...

Arvioi jokaiselle riippuvuudelle, jonka haluat lisätä tietokantaan, arvioimalla sen aiheuttamaa riskitasoa kertomalla kaksi tekijää:

  1. Todennäköisyys, että riippuvuus muuttuu olennaisella tavalla.
  2. Vahingon määrä, jonka riippuvuussuhteen merkittävä muutos aiheuttaisi hakemuksellesi.

Kolmannen osapuolen kirjasto tai kehys muuttuu vähemmän todennäköisesti, kun jotkut tai kaikki seuraavat asiat ovat totta:

  • Se on ollut olemassa useita vuosia, ja sillä on ollut useita merkittäviä julkaisuja.
  • Sitä käytetään laajasti monissa kaupallisissa sovelluksissa.
  • Sillä on aktiivisen tuen suuri organisaatio - mieluiten kotitalousyritys tai -laitos.

Kolmannen osapuolen kirjasto tai kehys vahingoittaa sovellustasi vähemmän, kun jotkut tai kaikki seuraavat asiat ovat totta:

  • Sitä käyttää vain pieni osa sovelluksesta, sen sijaan, että sitä käytetään kaikkialla.
  • Siitä riippuvainen koodi ei ole osa sitä "salaa kastike", josta puhuin aiemmin.
  • Sen poistaminen vaatii vähäiset muutokset kooditietokantaan.
  • Koko sovelluksesi on hyvin pieni ja se voidaan kirjoittaa nopeasti uudelleen. (Ole varovainen tämän suhteen - se on totta hyvin kauan.)

Mitä vaarallisempi jotain on, sitä todennäköisemmin sinun pitäisi kääriä se tai välttää sitä kokonaan.

Kun kyseessä on koodi, joka on todella keskeinen sovelluksesi arvoesityksessä - ”salaisessa kastikkeessasi”, sinun on oltava siitä erittäin suojattu. Tee koodista mahdollisimman riippumaton. Jos tarvitset ehdottomasti riippuvuutta, harkitse sen injektiota sen sijaan, että viittaat suoraan siihen. Silloinkin, ole varovainen.

Joskus tämä tarkoittaa "ei" sanomista kolmannen osapuolen kirjastolle, joka on mielestäsi todella hienoa tai jota todella haluat käyttää jostakin syystä. Ole vahva. Luota minuun, se kannattaa. Kysy vain kaikilta ihmisiltä, ​​jotka ovat investoineet voimakkaasti Angularin ensimmäiseen julkaisuun, tai entiseltä asiakkaaltani, joka käytti Parsea kaikkialla. Se ei ole hauskaa. Usko minua.

Hauskaa puhuen, katso tätä ...

TinyTag-tutkijan riippuvuuskaavio

Yllä oleva kuva on TinyTag Explorer -nimisen sovelluksen riippuvuusgraafi.

Riippuvuuskaavion luominen nykyisille sovelluksillesi on hieno tapa ymmärtää riippuvuutesi aiheuttama riskitaso. Olen koonnut luettelon ilmaisista työkaluista yllä olevien kaltaisten kuvaajien luomiseksi useilla kielillä, kuten JavaScript, C #, Java, PHP ja Python. Voit hankkia sen täältä.

Auta minua auttamaan muita

Haluan auttaa mahdollisimman monta kehittäjää jakamalla tietoni ja kokemukseni heidän kanssaan. Auta minua napsauttamalla alla olevaa ❤ suositus-painiketta (vihreä sydän).

Viimeiseksi, älä unohda napata luettelo ilmaisista riippuvuusgraafien generaattoreista täältä.