Kóðafíkn er djöfullinn.

Ósjálfstæði þitt brennur þig í hvert skipti.
„Breyting er eina stöðugan…“ - Heraclitus (heimspekingur)

Tólin, bókasöfnin og umgjörðin sem við notum til að byggja upp vefforrit okkar í dag eru verulega frábrugðin þeim sem við notuðum fyrir nokkrum stuttum árum.

Á nokkrum stuttum árum mun flest þessi tækni hafa breyst verulega aftur. Samt gera mörg okkar þetta að miðlægum, órjúfanlegum hluta forritanna okkar.

Við flytjum inn, notum og erfum frá ramma ramma mánaðarins eins og þau séu öll að verða til og vera óbreytt að eilífu. Jæja… þeir eru það ekki. Og það er vandamál.

Eftir 20+ ára þróun, hönnun og skjalavörslu á vefforritum hef ég kynnst tveimur mikilvægum sannindum:

  1. Ytri ósjálfstæði stafar mikil ógn við stöðugleika og hagkvæmni hvers konar umsóknar til langs tíma.
  2. Það er sífellt erfiðara - ef ekki ómögulegt - að smíða hvers konar app sem ekki er léttvæg án þess að nýta utanaðkomandi ósjálfstæði.

Þessi grein fjallar um að sættast við þessa tvo sannleika svo að forritin okkar hafi mesta möguleika á langvarandi lifun.

Kanínagatið er mjög djúpt.

Ef við byrjum að hugsa um allt það sem vefforritin okkar eru háð er auðvelt að hugsa um tugi eða meira áður en við komumst jafnvel í kóðann:

  • Kraftur
  • Tengingar
  • Eldveggur
  • DNS
  • Miðlaravélbúnaður (CPU, Disk, Ram, ...)
  • Kæling
  • Sýndarvettvangur
  • Gámapallur
  • Stýrikerfi
  • Vefþjónnspallur
  • App Server pallur
  • Vefskoðari

Sem hönnuðir er gott að vera meðvitaður um þessa hluti, en það er oft ekki mikið sem við getum gert við þá. Svo skulum líta framhjá þeim í bili og tala aðeins um kóðann.

Í kóða eru þrenns konar ósjálfstæði:

1. Ósjálfstæði sem við stjórnum

Þetta er kóða sem er skrifaður og í eigu okkar eða samtaka okkar.

2. Ósjálfstæði sem við stjórnum ekki

Þetta er kóða skrifaður af þriðja aðila söluaðila eða opnum hugbúnaðarsamfélagi.

3. Háð einu sinni fjarlægð

Þetta eru númerafíknar sem kóðaáhrif þriðja aðila okkar eru háð. (Segðu þetta þrisvar sinnum hratt!)

Við ætlum að tala aðallega um ósjálfstæði sem við stjórnum ekki.

Ósjálfstæði sem við stjórnum og ósjálfstæði þegar búið er að fjarlægja það getur samt valdið höfuðverk, en ef um ósjálfstæði er að ræða, ættum við að geta gripið beint inn í og ​​mildað öll vandamál.

Ef um ósjálfstæði er að ræða þegar búið er að fjarlægja það, getum við venjulega treyst því að þriðji aðili sjái um það fyrir okkur þar sem þeir eru líka háðir þessu.

Hvers vegna kóðaáhrif þriðja aðila eru góð

Stór hluti af vefforritinu þínu er til til að leysa sameiginleg vandamál: staðfesting, heimild, aðgang að gögnum, villuhöndlun, leiðsögn, skógarhögg, dulkóðun, birt lista yfir hluti, staðfesta inntak eyðublaða og svo framvegis ...

Óháð því hvaða tæknistöflu þú notar, það eru góðar líkur á að algengar lausnir á þessum vandamálum séu fyrir hendi og eru fáanlegar sem bókasöfn sem þú getur auðveldlega eignast og tengt við codebase þinn. Að skrifa eitthvað af þessu efni alveg frá grunni er venjulega tímasóun.

Þú vilt einbeita þér að kóða sem annað hvort leysa óalgengt vandamál eða leysa sameiginlegt vandamál á sjaldgæfan hátt. Það er það sem gerir umsókn þína dýrmæta: kóðann sem útfærir viðskiptareglur sem eru sértækar fyrir forritið þitt eingöngu - „leyndarmál sósu.“

Leitar- og blaðsíðuöðunaralgrími Google, tímalínusíun Facebook, „Mælt með fyrir Netflix fyrir þig“ og gagnaþjöppunaralgrím - kóðinn að baki öllum þessum aðgerðum er „leyndarsósa.“

Kóði þriðja aðila - í formi bókasafna - gerir þér kleift að hrinda í framkvæmd þessum hagnýtu eiginleikum forritsins þíns, svo þú getur haldið einbeitingu á „leyndarsósunni“.

Hvers vegna kóðaáhrif þriðja aðila eru slæm

Skoðaðu hvaða net-léttvægu vefforrit sem er smíðað á síðustu tveimur árum og þú verður alveg hissa á magn kóða sem raunverulega kemur frá þriðja bókasafni. Hvað ef eitt eða fleiri af þessum bókasöfnum þriðja aðila breytast harkalegur, eða hverfur eða brýtur?

Ef það er opinn aðgangur, gætirðu kannski lagað það sjálfur. En hversu vel skilurðu allan kóðann á því bókasafni sem þú átt ekki? Stór ástæða fyrir því að þú notar bókasafn í fyrsta lagi er að fá ávinninginn af kóðanum án þess að þurfa að hafa áhyggjur af öllum smáatriðum. En núna ertu fastur. Þú hefur bundið örlög þín alveg við þessar ósjálfstæði sem þú átt ekki og stjórnar ekki.

Ekki hafa áhyggjur, í lok þessarar greinar muntu finna nýja von.

Kannski heldurðu að ég sé að ýkja, eða tala frá hreinu fræðilegu sjónarmiði. Leyfðu mér að fullvissa þig - ég er með fjöldann allan af dæmum um viðskiptavini sem snóðu sig alveg með því að fella kóða þriðja aðila of þétt í appið sitt. Hér er aðeins eitt nýlegt dæmi…

Fyrrum viðskiptavinur minn smíðaði appið sitt með því að nota þjónustuaðila Backend-as-a-þjónustu í eigu Facebook, kallaður Parse. Þeir notuðu JavaScript viðskiptavinasafn frá Parse til að neyta Parse þjónustunnar. Í því ferli tengdu þeir alla kóðann sinn, þar með talinn „leyndarmál sósu“, við þetta bókasafn.

Þremur mánuðum eftir upphaf vöruframleiðslu viðskiptavinar míns - rétt eins og þeir fóru að fá góða grip með raunverulegum, greiðandi viðskiptavinum - tilkynnti Parse að það væri að leggja niður.

Nú í stað þess að einbeita sér að því að endurtaka vöru sína og efla viðskiptavina sína, varð viðskiptavinur minn að reikna út hvernig ég annað hvort ætti að flytja til sjálf-hýst, opinn útgáfa af Parse, eða skipta um Parse alveg.

Truflunin sem þetta olli fyrir ungt, nýjunga forrit var svo mikið að viðskiptavinur minn skrapp að lokum appið að öllu leyti.

Jafnvægi á því góða og slæma

Fyrir nokkrum árum var lausnin mín til að vinna bug á áhættunni og halda ávinningi bókasafna þriðja aðila við að vefja þeim með millistykki.

Í meginatriðum settirðu þriðja aðila kóða í millistykki eða eining sem þú hefur skrifað. Þetta virkar síðan til að afhjúpa aðgerðir bókasafna þriðja aðila á þann hátt sem þú stjórnar.

Ef þetta mynstur er notað, ef bókasafn eða umgjörð þriðja aðila breytist eða hverfur, þarftu aðeins að laga smá millistykki. Restin af forritinu þínu er óbreytt.

Millistykki fyrir millistykki frá Dofactory.com

Þetta hljómar vel á pappír. Þegar þú ert með ósjálfstætt ósjálfstæði sem aðeins býður upp á nokkrar aðgerðir, þá mun þetta gera það. En hlutirnir geta orðið ljótir hratt.

Geturðu ímyndað þér að þurfa að vefja öllu React bókasafninu (þar með talið JSX) áður en þú notar eitthvað af því? Hvernig væri að vefja jQuery, eða hyrndur, eða vorramma í Java? Þetta verður fljótt martröð.

Þessa dagana mæli ég með meira blæbrigðum nálgun ...

Fyrir hvert ósjálfstæði sem þú vilt bæta við codebase þinn skaltu meta áhættustigið sem það mun hafa í för með því að margfalda tvo þætti:

  1. Líkurnar á því að ósjálfstæði breytist á efnislegan hátt.
  2. Magn tjóns sem veruleg breyting á ósjálfstæði myndi gera fyrir umsókn þína.

Minni líkur eru á að bókasafn eða umgjörð þriðja aðila breytist þegar eitthvað af eða öllu eftirfarandi er satt:

  • Það hefur verið til í nokkur ár og hefur fengið nokkrar helstu útgáfur.
  • Það er mikið notað af mörgum viðskiptalegum forritum.
  • Það hefur virkan stuðning stórrar stofnunar - helst heimilisfyrirtækis eða stofnunar.

Þriðja aðila bókasafn eða ramma mun gera minna tjón á umsókn þinni þegar eitthvað af eða öllu eftirfarandi er satt:

  • Það er aðeins notað af litlum hluta umsóknarinnar, frekar en að vera notaður í öllu.
  • Kóðinn sem fer eftir því er ekki hluti af þeirri „leynilegu sósu“ sem ég talaði um áðan.
  • Að fjarlægja það krefst lágmarks breytinga á codebase þínum.
  • Allt forritið þitt er mjög lítið og hægt er að endurskrifa það fljótt. (Verið varkár með þennan - það er sjaldan satt mjög lengi.)

Því áhættusækni sem eitthvað er, því líklegra er að þú verðir að vefja því eða forðast það með öllu.

Þegar það kemur að kóðanum sem er mjög mikilvægur í gildi uppástungu umsóknar þinnar - „leyndarsósan“ þín - verður þú að vera mjög verndandi fyrir því. Gerðu þann kóða eins sjálfstæðan og mögulegt er. Ef þú þarft algerlega að nota ósjálfstæði skaltu íhuga að sprauta því frekar en vísa beint til þess. Jafnvel þá, vera varkár.

Stundum þýðir þetta að segja „nei“ við þriðja aðila bókasafn sem þér finnst virkilega flott, eða að þú viljir nota af einum eða öðrum ástæðum. Vertu sterkur. Treystu mér, það mun borga sig. Spurðu bara alla þá sem fjárfestu mikið í fyrstu útgáfu af Angular, eða fyrrum viðskiptavinur minn sem notaði Parse alls staðar. Það er ekkert gaman. Trúðu mér.

Talandi um gaman, kíktu á þetta ...

Óháð graf fyrir TinyTag landkönnuður

Myndin hér að ofan er háðar línurit fyrir forrit sem kallast TinyTag Explorer.

Að búa til ósjálfstæðarit fyrir núverandi forrit þín er frábær leið til að skilja áhættustigið sem háð er. Ég hef sett saman lista yfir ókeypis verkfæri til að búa til línurit svipað og hér að ofan á ýmsum tungumálum þar á meðal JavaScript, C #, Java, PHP og Python. Þú getur fengið það hér.

Hjálpaðu mér að hjálpa öðrum

Ég vil hjálpa eins mörgum verktökum og ég get með því að deila þekkingu minni og reynslu með þeim. Vinsamlegast hjálpaðu mér með því að smella á ❤ ráðhnappinn (grænt hjarta) hér að neðan.

Að lokum, ekki gleyma að grípa lista yfir ókeypis rafala rafhlaða fyrir ósjálfstæði hér.