Koodisõltuvused on kurat.

Teie sõltuvused põlevad teid iga kord.
“Muutus on ainus konstant…” - Heraclitus (filosoof)

Tööriistad, raamatukogud ja raamistikud, mida täna oma veebirakenduste loomisel kasutame, erinevad drastiliselt nendest, mida kasutasime vaid mõni aasta tagasi.

Mõne lühikese aasta pärast on enamik neist tehnoloogiatest jälle dramaatiliselt muutunud. Kuid paljud meist muudavad need meie rakenduste keskseks, lahutamatuks osaks.

Me impordime, kasutame ja pärime kuu maitsesüsteemidest nii, nagu nad kõik püsiksid ja muutuksid igavesti. Noh ... nad pole. Ja see on probleem.

Pärast enam kui 20 aastat veebirakenduste väljatöötamist, kujundamist ja arhitektuuri olen hakanud hindama kaht olulist tõde:

  1. Välised sõltuvused kujutavad endast suurt ohtu iga rakenduse pikaajalisele stabiilsusele ja elujõulisusele.
  2. Üha raskem - kui mitte võimatu - on igasuguse mittetriviaalse rakenduse ehitamine ilma väliseid sõltuvusi võimendamata.

See artikkel räägib nende kahe tõe ühildamisest, nii et meie rakendustel on suurim võimalus pikaajaliseks püsimiseks.

Küüliku auk on tõesti väga sügav.

Kui hakkame mõtlema kõigile asjadele, millest meie veebirakendused sõltuvad, on lihtne mõelda veel kümmekonnale või enamale, enne kui koodini jõuame:

  • Jõudu
  • Ühenduvus
  • Tulemüür
  • DNS
  • Serveri riistvara (CPU, ketas, mälu,…)
  • Jahutamine
  • Virtualiseerimisplatvorm
  • Konteinerplatvorm
  • Operatsioonisüsteem
  • Veebiserveri platvorm
  • Rakenduse serveri platvorm
  • Veebibrauseris

Arendajatena on hea nendest asjadest teadlik olla, kuid sageli pole nende jaoks palju võimalik ära teha. Seetõttu ignoreerime neid praegu ja räägime ainult koodist.

Koodis on kolme tüüpi sõltuvusi:

1. Sõltuvused, mida me kontrollime

See kood on kirjutatud ja kuulub meile või meie organisatsioonile.

2. Sõltuvused, mida me ei kontrolli

Selle koodi on kirjutanud kolmas osapool või avatud lähtekoodiga tarkvara kogukond.

3. Sõltuvused eemaldatud

Need on koodisõltuvused, millest meie kolmanda osapoole koodisõltuvused sõltuvad. (Ütle seda kolm korda kiiresti!)

Me räägime peamiselt sõltuvustest, mida me ei kontrolli.

Meie kontrollitavad sõltuvused ja eemaldatud sõltuvused võivad ikkagi põhjustada peavalu, kuid kontrollitavate sõltuvuste korral peaksime saama vahetult sekkuda ja probleeme leevendada.

Kui sõltuvused on kord eemaldatud, saame meie eest hoolitseda tavaliselt kolmanda osapoole poolt, kuna nemad sõltuvad ka neist.

Miks on kolmandate osapoolte koodisõltuvused head

Suur osa teie veebirakendusest on levinud probleemide lahendamiseks: autentimine, autoriseerimine, andmetele juurdepääs, tõrkeotsing, navigeerimine, logimine, krüptimine, üksuste loendi kuvamine, vormi sisendite kinnitamine ja nii edasi ...

Sõltumata sellest, millist tehnoloogiakogumit te kasutate, on hea võimalus, et nendele probleemidele on olemas ühised lahendused. Need on saadaval teekidena, mida saate hõlpsalt hankida ja oma andmebaasi pistikprogrammi lisada. Mõne sellise asja täiesti nullist kirjutamine on üldiselt ajaraiskamine.

Soovite keskenduda koodile, mis kas lahendab haruldase probleemi või lahendab tavalise probleemi harva. Just see muudab teie rakenduse väärtuslikuks: kood, mis rakendab ainuüksi teie rakenduse jaoks ainulaadseid ärieeskirju - salajane kaste.

Google'i otsingu ja lehe järjestamise algoritm, Facebooki ajatelje filtreerimine, Netflixi sektsioon „teile soovitatav” ja andmete tihendamise algoritmid - kõigi nende funktsioonide taga olev kood on „salajane kaste”.

Kolmanda osapoole kood - raamatukogude kujul - võimaldab teil rakenduse neid kommertsiaalseid funktsioone kiiresti rakendada, nii et saate keskenduda oma „salajasele kastmele”.

Miks on kolmandate osapoolte koodisõltuvused halvad

Vaadake kõiki viimase paari aasta jooksul loodud mitte-triviaalset veebirakendust ja olete täiesti jahmunud, kui palju koodi on pärit kolmanda osapoole raamatukogust. Mis saab siis, kui üks või mitu neist kolmandast isikust raamatukogu muutub drastiliselt, kaob või puruneb?

Kui see on avatud lähtekoodiga, saate seda ehk ise parandada. Kuid kui hästi saate aru kogu koodist, mis asub selles raamatukogus, mis teile ei kuulu? Suur põhjus, miks te raamatukogu kasutate, on koodi eeliste kasutamine, ilma et peaksite kõigi detailide pärast muretsema. Aga nüüd olete ummikus. Olete oma varanduse täielikult sidunud nende sõltuvustega, mis te ei oma ja mida te ei kontrolli.

Ärge muretsege, selle artikli lõpuks leiate uue lootuse.

Võib-olla arvate, et ma liialdan või räägin puhtalt akadeemilisest vaatenurgast. Lubage mul kinnitada - mul on kümneid näiteid klientidest, kes täielikult nuhkisid, manustades kolmanda osapoole koodi liiga tihedalt oma rakendusse. Siin on vaid üks hiljutine näide ...

Minu endine klient ehitas nende rakenduse, kasutades Facebooki omanduses olevat teenusekendust Backend-as-a-Service, mille nimi on Parse. Parse teenuse tarbimiseks kasutasid nad Parse'i pakutavat JavaScripti kliendikogusid. Selle protsessi käigus ühendasid nad kogu oma koodi - sealhulgas “salajase kastme” koodi - selle raamatukoguga tihedalt.

Kolm kuud pärast minu kliendi esmast toote turuletulekut - just siis, kui nad hakkasid reaalsete, tasuliste klientidega head hoidu saama - teatas Parse, et seiskab töö.

Selle asemel, et keskenduda oma toote kordamisele ja kliendibaasi kasvatamisele, tuli mu kliendil välja mõelda, kuidas minna üle ise hostitavale avatud lähtekoodiga versioonile Parse või asendada see täielikult.

Selle põhjustatud häired noorele algavale rakendusele olid nii suured, et minu klient lammutas selle rakenduse lõpuks täielikult.

Hea ja halva tasakaalustamine

Mitu aastat tagasi oli minu lahendus lahenduseks riskide ületamiseks, säilitades samas kolmandate osapoolte raamatukogude eelised, mähkida need adapteri mustri abil.

Sisuliselt mähite kolmanda osapoole koodi teie kirjutatud adapteriklassi või moodulisse. See toimib siis teie poolt kontrollitaval viisil kolmanda osapoole raamatukogude funktsioonide paljastamiseks.

Selle mudeli kasutamisel peate kolmanda osapoole teegi või raamistiku muutumisel või kadumisel parandama ainult natuke adapteri koodi. Ülejäänud rakendus jääb puutumatuks.

Adapterimustri skeem saidilt Dofactory.com

See kõlab paberil hästi. Kui teil on iseseisvaid sõltuvusi, mis pakuvad ainult mõnda funktsiooni, teeb see trikk ära. Kuid asjad võivad kole kiiresti minna.

Kas te kujutate ette, et peate enne selle kasutamist kasutama kogu Reacti teeki (sealhulgas JSX-i)? Kuidas on lood Java-vormingus jQuery või Nurga või Kevadraamiga? See muutub kiiresti õudusunenäoks.

Nendel päevadel soovitan nüansirikkamat lähenemist ...

Hinnake iga sõltuvust, mille soovite oma andmebaasi lisada, korrutades kahe teguri:

  1. Tõenäosus, et sõltuvus muutub materiaalselt.
  2. Kahju suurus, mille sõltuvus oluliselt muudab, oleks teie taotlusele kahjulik.

Kolmanda osapoole raamatukogu või raamistik muutub vähem tõenäoliselt, kui mõned või kõik järgmised asjad on tõesed:

  • See on kestnud mitu aastat ja sellel on olnud mitu suurt väljaandmist.
  • Seda kasutatakse laialdaselt paljudes kaubanduslikes rakendustes.
  • Sellel on suure organisatsiooni - eelistatavalt leibkonna nimega ettevõtte või asutuse - aktiivne toetus.

Kolmanda osapoole raamatukogu või raamistik kahjustab teie rakendust vähem, kui mõned või kõik järgmised asjad on tõesed:

  • Seda kasutab ainult väike osa teie rakendusest, selle asemel, et seda kogu ulatuses kasutada.
  • Sellest sõltuv kood ei kuulu sellesse “salajasse kastmesse”, millest ma varem rääkisin.
  • Selle eemaldamine nõuab teie koodbaasis minimaalseid muudatusi.
  • Kogu teie rakendus on väga väike ja seda saab kiiresti ümber kirjutada. (Olge selle suhtes ettevaatlik - see on harva tõsi väga kaua.)

Mida riskantsem on asi, seda tõenäolisem peaks olema see mähkida või seda üldse vältida.

Kui tegemist on koodiga, mis on teie rakenduse väärtuspakkumise - teie „salajase kastme” jaoks - kesksel kohal, peate selle vastu eriti kaitsma. Tehke see kood võimalikult sõltumatuks. Kui peate tingimata kasutama sõltuvust, kaaluge selle süstimist, mitte otsest viitamist. Isegi siis olge ettevaatlik.

Mõnikord tähendab see "ei" ütlemist kolmanda osapoole raamatukogule, mis on teie arvates tõesti lahe või mida soovite ühel või teisel põhjusel tõesti kasutada. Ole tugev. Usu mind, see tasub end ära. Lihtsalt küsige nendelt inimestelt, kes on investeerinud suuri investeeringuid Nurga esimesse väljaandmisse, või minu endiselt kliendilt, kes kasutas Parse'i kõikjal. See pole lõbus. Usu mind.

Lõbusalt öeldes vaadake seda ...

TinyTag Exploreri sõltuvusgraafik

Ülalolev pilt on rakenduse TinyTag Explorer sõltuvusgraafik.

Olemasolevate rakenduste sõltuvusgraafiku genereerimine on suurepärane viis mõista teie sõltuvustega kaasnevat riskitaset. Olen kokku pannud loetelu tasuta tööriistadest graafikute genereerimiseks, nagu ülaltoodud, erinevates keeltes, sealhulgas JavaScript, C #, Java, PHP ja Python. Selle saate siit.

Aita mul teisi aidata

Tahan aidata võimalikult palju arendajaid, jagades nendega oma teadmisi ja kogemusi. Palun aidake mind, klõpsates allpool nuppu the soovita (roheline süda).

Lõpuks ärge unustage siin haarata oma tasuta sõltuvusgraafikute generaatorite loendit.