Koodiriippuvuudet ovat paholainen.

”muutos on ainoa vakio…” – Herakleitos (filosofi)

työkalut, kirjastot ja puitteet, joita käytämme verkkosovellustemme rakentamiseen tänä päivänä, eroavat huomattavasti niistä, joita käytimme vain muutama vuosi sitten.

muutaman lyhyen vuoden kuluttua useimmat näistä tekniikoista ovat jälleen muuttuneet dramaattisesti. Silti monet meistä tekevät näistä keskeisen, erottamattoman osan sovelluksistamme.

tuomme, käytämme ja perimme kuukauden makuisia kehyksiä ikään kuin ne kaikki olisivat olemassa ja muuttumattomina ikuisesti. Eivät ole. Se on ongelma.

yli 20 vuoden web-sovellusten kehittämisen, suunnittelun ja suunnittelun jälkeen olen oppinut arvostamaan kahta tärkeää totuutta:

1. ulkoiset riippuvuudet ovat suuri uhka minkä tahansa sovelluksen pitkän aikavälin vakaudelle ja elinkelpoisuudelle.
2. on yhä vaikeampaa – ellei jopa mahdotonta-rakentaa mitään ei-triviaalia sovellusta hyödyntämättä ulkoisia riippuvuuksia.

tämä artikkeli käsittelee näiden kahden totuuden yhteensovittamista niin, että sovelluksillamme on suurin mahdollisuus pitkäaikaiseen selviytymiseen.

kaninkolo on todella syvä.

jos alamme ajatella kaikkia asioita meidän Web-sovellukset riippuvat se on helppo ajatella kymmenkunta tai enemmän ennen kuin edes saada koodi:

• teho
• liitettävyys
• palomuuri
• DNS
• palvelinlaitteisto (suoritin, levy, Ram, …)
• jäähdytys
• virtualisointialusta
• Konttialusta
• Konttialusta
• käyttöjärjestelmä
• web server platform
• app server platform
• verkkoselain

kehittäjinä on hyvä olla tietoinen näistä asioista, mutta niille ei usein voi paljon mitään. Unohdetaan ne ja puhutaan vain koodista.

koodissa riippuvuuksia on kolmenlaisia:

1. Riippuvuudet joita hallitsemme

tämä on meidän tai organisaatiomme kirjoittama ja omistama koodi.

2. Riippuvuudet, joita emme hallitse

tämä on kolmannen osapuolen toimittajan tai avoimen lähdekoodin ohjelmistoyhteisön kirjoittama koodi.

3. Riippuvuudet kun ne on poistettu

nämä ovat koodiriippuvuuksia, joista kolmannen osapuolen koodiriippuvuutemme riippuvat. (Sano, että kolme kertaa nopeasti!)

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

Kontrolloimamme riippuvuudet ja poistetut riippuvuudet voivat edelleen aiheuttaa päänsärkyä, mutta kontrolloimiemme riippuvuuksien tapauksessa meidän pitäisi pystyä suoraan puuttumaan ongelmiin ja lieventämään niitä.

kun riippuvuudet on kerran poistettu, voimme yleensä luottaa siihen, että kolmas osapuoli huolehtii niistä puolestamme, koska hekin ovat riippuvaisia näistä.

miksi kolmannen osapuolen koodiriippuvuudet ovat hyviä

suuri osa verkkosovelluksestasi on olemassa yhteisten ongelmien ratkaisemiseksi: todennus, valtuutus, tietojen käyttö, virheiden käsittely, navigointi, kirjaaminen, salaus, asialuettelon näyttäminen, lomakkeen syötteiden validointi ja niin edelleen…

riippumatta siitä, mitä teknologiapinoa käytät, on hyvin mahdollista, että näihin ongelmiin on olemassa yhteisiä ratkaisuja, ja ne ovat saatavilla kirjastoina, joita voit helposti hankkia ja liittää koodipöytääsi. Kaiken tämän kirjoittaminen täysin tyhjästä on yleensä ajanhukkaa.

haluat keskittyä koodiin, joka joko ratkaisee harvinaisen ongelman tai ratkaisee yleisen ongelman harvinaisella tavalla. Se tekee sovelluksestasi arvokkaan: koodi, joka toteuttaa liiketoimintasäännöt, jotka ovat ainutlaatuisia vain sovelluksessasi — ” secret sauce.”

Googlen haku— ja sivusijoitusalgoritmi, Facebook aikajanan suodatus, Netflixin ”recommended for you” – osio ja tiedon pakkausalgoritmit-kaikkien näiden ominaisuuksien taustalla oleva koodi on ”salainen kastike.”

kolmannen osapuolen koodi-muodossa kirjastot-voit nopeasti toteuttaa nämä commoditized ominaisuuksia sovelluksen, joten voit pysyä keskittynyt ” salainen kastike.”

Why third-party code dependencies are bad

Take a look at any non-trivial web-app built in the last of years and you ’ ll be absolutely tyrmistynyt the amount of code that actually comes from a third-party library. Mitä jos yksi tai useampi noista kolmannen osapuolen kirjastoista muuttuu rajusti tai katoaa tai katkeaa?

jos se on avoimen lähdekoodin, voit ehkä korjata sen itse. Mutta kuinka hyvin ymmärrät sen kirjaston koodin, jota et omista? Suuri syy, miksi käytät kirjastoa ylipäätään, on saada koodin edut tarvitsematta huolehtia kaikista yksityiskohdista. Mutta nyt olet jumissa. Olet sitonut omaisuutesi riippuvuuksiin, joita et omista etkä hallitse.

ehkä luulet, että liioittelen, tai puhun puhtaasti akateemisesta näkökulmasta. Vakuutan teille-Minulla on kymmeniä esimerkkejä asiakkaista, jotka täysin snookered itsensä upottamalla kolmannen osapuolen koodi liian tiukasti niiden sovellus. Tässä vain yksi tuore esimerkki …

entinen asiakkaani rakensi sovelluksensa facebook-omisteisen Backend-as-a-Service-palveluntarjoajan, Parse-nimisen, avulla. He käyttivät JavaScript-asiakaskirjaston tarjoamia Parse kuluttaa Parse palvelu. Samalla he liittivät kaikki koodinsa — mukaan lukien ”salaisen kastikkeen” koodin — tähän kirjastoon.

kolme kuukautta asiakkaani ensimmäisen Tuotelanseerauksen jälkeen — juuri kun he alkoivat saada hyvää vetoapua todellisilta, maksavilta asiakkailta-Parse ilmoitti lopettavansa toimintansa.

nyt sen sijaan, että keskityttäisiin iteroimaan tuotteitaan ja kasvattamaan asiakaskuntaansa, asiakkaani piti selvittää, miten joko siirtyä itse isännöityyn, avoimen lähdekoodin versioon Parsesta tai korvata Parse kokonaan.

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

hyvän ja pahan tasapainottaminen

useita vuosia sitten, minun go-to ratkaisu voittaa riskejä säilyttäen edut kolmannen osapuolen-kirjastot oli kääriä ne käyttäen sovitin kuvio.

pohjimmiltaan käärit kolmannen osapuolen koodin kirjoittamaasi adapteriluokkaan tai moduuliin. Tämä sitten toimii paljastaa toimintoja kolmannen osapuolen kirjastot tavalla, että voit hallita.

tämän kuvion avulla, jos kolmannen osapuolen kirjasto tai kehys muuttuu tai katoaa, sinun tarvitsee vain korjata hieman sovituskoodia. Muu sovellus pysyy ehjänä.

tämä kuulostaa paperilla hyvältä. Kun sinulla on itsenäisiä riippuvuuksia, jotka tarjoavat vain muutamia toimintoja, tämä tekee temppu. Mutta asiat voivat mennä rumiksi nopeasti.

voitko kuvitella, että sinun pitäisi paketoida koko React-kirjasto (mukaan lukien JSX) ennen kuin käytät mitään siitä? Miten olisi jQueryn, kulmikkaan tai Jaavan Jousikehyksen kääriminen? Tästä tulee nopeasti painajainen.

näinä päivinä suosittelen monivivahteisempaa lähestymistapaa …

jokaisen riippuvuuden osalta, jonka haluat lisätä koodebaaseeseesi, arvioi sen aiheuttama riskitaso kertomalla kaksi tekijää:

1. todennäköisyys, että riippuvuus muuttuu aineellisesti.
2. sen vahingon määrä, jonka riippuvuuden olennainen muutos aiheuttaisi hakemuksellesi.

kolmannen osapuolen kirjasto tai viitekehys muuttuu epätodennäköisemmin, kun jotkin tai kaikki seuraavat asiat ovat totta:

• se on ollut olemassa useita vuosia ja on ollut useita merkittäviä julkaisuja.
• sitä käytetään laajalti monissa kaupallisissa sovelluksissa.
• sillä on suuren organisaation aktiivinen tuki — mieluiten kotitalouden nimiyhtiön tai laitoksen.

kolmannen osapuolen kirjasto tai kehys tekee vähemmän vahinkoa sovelluksellesi, kun jotkin tai kaikki seuraavat asiat ovat totta:

• sitä käyttää vain pieni osa sovelluksesta, eikä sitä käytetä kaikkialla.
• siitä riippuva koodi ei kuulu siihen ”salaiseen kastikkeeseen”, josta aiemmin puhuin.
• sen poistaminen vaatii minimaalisia muutoksia koodikantaasi.
• koko hakemuksesi on hyvin pieni ja se voidaan kirjoittaa nopeasti uudelleen. (Ole varovainen tämän kanssa — se on harvoin totta hyvin pitkään.)

mitä riskialttiimpi asia on, sitä todennäköisemmin sitä kannattaa paketoida tai välttää kokonaan.

kun on kyse koodista, joka on todella keskeinen sovelluksesi arvolupauksessa —”salaisesta kastikkeestasi” — sinun täytyy olla erittäin suojeleva sen suhteen. Tee koodista mahdollisimman riippumaton. Jos sinun on ehdottomasti käytettävä riippuvuussuhdetta, harkitse lääkkeen pistämistä sen sijaan, että viitaisit siihen suoraan. Ole silloinkin varovainen.

joskus tämä tarkoittaa ” ei ” Sanomista kolmannen osapuolen kirjastolle, jota pidät todella siistinä, tai jota todella haluat syystä tai toisesta käyttää. Ole vahva. Usko pois, se kannattaa. Kysykää vaikka niiltä ihmisiltä, jotka panostivat suuresti Angularyn ensimmäiseen julkaisuun, tai entiseltä asiakkaaltani, joka käytti Parsea kaikkialla. Se ei ole hauskaa. Usko pois.

hauskanpidosta puheen ollen, katso tätä…

yllä oleva kuva on Riippuvuusdiagrammi TinyTag Explorer-nimiselle sovellukselle.

riippuvuusdiagrammin luominen olemassa oleville sovelluksillesi on hyvä tapa ymmärtää riippuvuuksien aiheuttaman riskin taso. Olen koonnut listan ilmaisia työkaluja tuottaa kaavioita samanlainen edellä eri kielillä kuten JavaScript, C#, Java, PHP, ja Python. Saat sen täältä.

auta minua auttamaan muita

haluan auttaa mahdollisimman monia kehittäjiä jakamalla heidän kanssaan tietoni ja kokemukseni. Auta minua klikkaamalla ❤ suosittele-painiketta (vihreä sydän) alla.

lopuksi, älä unohda napata listaasi vapaista riippuvuusdiagrammigeneraattoreista täältä.