Dependențele de cod sunt diavolul.

„schimbarea este singura constantă …” – Heraclit (filozof)

instrumentele, bibliotecile și cadrele pe care le folosim pentru a construi aplicațiile noastre web astăzi sunt drastic diferite de cele pe care le-am folosit cu doar câțiva ani în urmă.

în câțiva ani, majoritatea acestor tehnologii se vor schimba din nou dramatic. Cu toate acestea, mulți dintre noi fac din acestea o parte centrală, inextricabilă a aplicațiilor noastre.

importăm, folosim și moștenim din cadrele de aromă ale lunii ca și cum toate vor fi în jur și neschimbate pentru totdeauna. Ei bine … nu sunt. Și asta e o problemă.

după peste 20 de ani de dezvoltare, proiectare și arhitectură a aplicațiilor web, am ajuns să apreciez două adevăruri importante:

1. dependențele externe reprezintă o mare amenințare pentru stabilitatea și viabilitatea pe termen lung a oricărei aplicații.
2. este din ce în ce mai dificil — dacă nu chiar imposibil — să construiești orice fel de aplicație non-banală fără a utiliza dependențe externe.

acest articol este despre reconcilierea acestor două adevăruri, astfel încât aplicațiile noastre să aibă cea mai mare șansă de supraviețuire pe termen lung.

gaura de iepure este într-adevăr foarte adâncă.

dacă începem să ne gândim la toate lucrurile de care depind aplicațiile noastre web, este ușor să ne gândim la o duzină sau mai multe înainte de a ajunge chiar la cod:

• putere
• conectivitate
• Firewall
• DNS
• Hardware Server (CPU, disc, Ram, …)
• răcire
• platformă de virtualizare
• platformă Container
• sistem de operare
• web server platform
• App server platform
• web browser

ca Dezvoltatori, este bine să fie conștienți de aceste lucruri, dar nu e de multe ori nu de mult putem face despre ele. Deci, să le ignorăm deocamdată și să vorbim doar despre Cod.

în cod, există trei tipuri de dependențe:

1. Dependențele pe care le controlăm

acesta este codul scris și deținut de noi sau de organizația noastră.

2. Dependențe nu controlăm

acesta este codul scris de un furnizor terț sau de o comunitate de software open-source.

3. Dependențe odată eliminate

acestea sunt dependențele de cod de care depind dependențele de cod ale terților. (Spune că de trei ori mai repede!)

vom vorbi în principal despre dependențe pe care nu le controlăm.

dependențele pe care le controlăm și dependențele odată eliminate pot provoca dureri de cap, dar în cazul dependențelor pe care le controlăm, ar trebui să putem interveni direct și să atenuăm orice probleme.

în cazul dependențelor odată eliminate, ne putem baza, de obicei, pe o terță parte pentru a avea grijă de ea pentru noi, deoarece acestea sunt dependente de acestea, de asemenea.

de ce dependențele de coduri terțe sunt bune

o mare parte din aplicația dvs. web există pentru a rezolva probleme comune: autentificare, autorizare, acces la date, gestionarea erorilor, navigare, logare, criptare, afișarea unei liste de elemente, validarea intrărilor formularului și așa mai departe…

indiferent de stiva de tehnologie pe care o utilizați, există șanse mari să existe soluții comune la aceste probleme și să fie disponibile ca biblioteci pe care le puteți achiziționa și conecta cu ușurință la baza de cod. Scrierea oricăreia dintre aceste lucruri complet de la zero este, în general, o pierdere de timp.

doriți să vă concentrați asupra codului care fie rezolvă o problemă neobișnuită, fie rezolvă o problemă comună într-un mod neobișnuit. Asta face ca aplicația dvs. să fie valoroasă: codul care implementează regulile de afaceri unice numai pentru aplicația dvs. — „sosul secret.”

algoritmul Google de căutare și clasare a paginilor, filtrarea cronologiei Facebook, secțiunea Netflix „recomandat pentru dvs.” și algoritmii de compresie a datelor— codul din spatele tuturor acestor caracteristici este „sos secret.”

Cod terță parte — sub formă de biblioteci — vă permite să pună în aplicare rapid aceste caracteristici commoditized ale aplicației, astfel încât să puteți rămâne concentrat pe dvs. „sos secret.”

de ce dependențele de coduri terțe sunt proaste

aruncați o privire la orice aplicație web non-banală construită în ultimii ani și veți fi absolut uimiți de cantitatea de cod care provine de fapt dintr-o bibliotecă terță parte. Ce se întâmplă dacă una sau mai multe dintre aceste biblioteci terțe se schimbă drastic, dispare sau se rupe?

dacă este open-source, poate îl puteți repara singur. Dar cât de bine înțelegi tot codul din biblioteca pe care nu o ai? Un motiv important pentru care utilizați o bibliotecă în primul rând este să obțineți beneficiile codului fără a fi nevoie să vă faceți griji cu privire la toate detaliile. Dar acum ești blocat. V-ați legat complet averea de aceste dependențe pe care nu le dețineți și nu le controlați.

poate credeți că exagerez sau vorbesc dintr-un punct de vedere pur academic. Permiteți — mi să vă asigur-am zeci de exemple de clienți care s-au snookered complet prin încorporarea codului terță parte prea strâns în aplicația lor. Iată doar un exemplu recent…

un fost client al meu și-a construit aplicația folosind un furnizor de Backend-as-a-Service deținut de Facebook, numit Parse. Au folosit o bibliotecă client JavaScript furnizată de Parse pentru a consuma serviciul Parse. În acest proces, și — au cuplat strâns tot codul — inclusiv codul „sos secret” – la această bibliotecă.

la trei luni de la lansarea inițială a produsului clientului meu — la fel cum au început să obțină o tracțiune bună cu clienții reali, plătitori — Parse a anunțat că se închide.

acum, în loc să se concentreze pe iterarea produsului și creșterea bazei de clienți, Clientul meu a trebuit să-și dea seama cum să migreze la o versiune de analiză auto-găzduită, open-source, sau să înlocuiască analiza complet.

perturbarea acest cauzat pentru un tânăr, aplicație tinerei a fost atât de mare încât clientul meu în cele din urmă casate app în întregime.

echilibrarea binelui și a răului

cu câțiva ani în urmă, soluția mea pentru depășirea riscurilor, păstrând în același timp beneficiile bibliotecilor terțe, a fost să le împachetez folosind modelul adaptorului.

în esență, înfășurați codul terță parte într-o clasă de adaptor sau un modul pe care l-ați scris. Aceasta funcționează apoi pentru a expune funcțiile bibliotecilor terțe într-un mod pe care îl controlați.

folosind acest model, dacă o bibliotecă terță parte sau un cadru se schimbă sau dispare, trebuie doar să remediați un pic de cod de adaptor. Restul aplicației rămâne intact.

sună bine pe hârtie. Când aveți dependențe autonome care oferă doar câteva funcții, acest lucru va face trucul. Dar lucrurile pot deveni urâte repede.

vă puteți imagina că trebuie să înfășurați întreaga bibliotecă React (inclusiv JSX) înainte de a utiliza oricare dintre ele? Ce zici de împachetarea jQuery, sau Angular, sau Cadrul de primăvară în Java? Acest lucru devine rapid un coșmar.

în aceste zile vă recomand o abordare mai nuanțată…

pentru fiecare dependență pe care doriți să o adăugați la baza de cod, evaluați nivelul de risc pe care îl va introduce înmulțind doi factori:

1. probabilitatea ca dependența să se schimbe într-un mod material.
2. valoarea daunelor pe care o modificare semnificativă a dependenței le-ar face aplicației dvs.

o bibliotecă sau un cadru terță parte este mai puțin probabil să se schimbe atunci când unele sau toate lucrurile următoare sunt adevărate:

• a fost în jur de câțiva ani și a avut mai multe lansări majore.
• este utilizat pe scară largă de multe aplicații comerciale.
• are sprijinul activ al unei organizații mari — de preferință o companie sau o instituție cu nume de uz casnic.

o bibliotecă terță parte sau un cadru va face mai puține daune aplicației dvs. atunci când unele sau toate lucrurile următoare sunt adevărate:

• este folosit doar de o mică parte a aplicației dvs., mai degrabă decât să fie utilizat pe tot parcursul.
• codul care depinde de el nu face parte din acel „sos secret” despre care am vorbit mai devreme.
• eliminarea acestuia necesită modificări minime ale bazei de cod.
• întreaga aplicație este foarte mică și poate fi rescrisă rapid. (Fii atent cu aceasta — este rareori adevărat pentru foarte mult timp.)

cu cât este mai riscant ceva, cu atât este mai probabil să îl înfășurați sau să îl evitați cu totul.

când vine vorba de codul care este cu adevărat central pentru propunerea de valoare a aplicației dvs. —”sosul dvs. secret” — trebuie să fiți extrem de protector față de acesta. Faceți acest cod cât mai independent posibil. Dacă aveți absolut nevoie să utilizați o dependență, luați în considerare injectarea acesteia, mai degrabă decât referirea directă la aceasta. Chiar și atunci, fii atent.

uneori, aceasta înseamnă să spui „Nu” unei biblioteci terțe pe care o consideri foarte mișto sau pe care vrei să o folosești cu adevărat dintr-un motiv sau altul. Fii puternic. Crede-mă, va da roade. Întrebați-i pe toți acei oameni care au investit foarte mult în prima versiune a Angular sau pe fostul meu client care a folosit Parse peste tot. Nu e amuzant. Crede-mă.

vorbind de distracție, să ia o privire la acest…

imaginea de mai sus este graficul de dependență pentru o aplicație numită Tinytag Explorer.

generarea unui grafic de dependență pentru aplicațiile existente este o modalitate excelentă de a înțelege nivelul de risc introdus de dependențele dvs. Am creat o listă de instrumente gratuite pentru generarea de grafice similare celor de mai sus într-o varietate de limbi, inclusiv JavaScript, C#, Java, PHP și Python. Puteți să-l aici.

ajută-mă să-i ajut pe alții

vreau să ajut cât mai mulți dezvoltatori, împărtășind cunoștințele și experiența mea cu ei. Vă rog să mă ajutați făcând clic pe butonul de recomandare (inima verde) de mai jos.

în cele din urmă, nu uitați să luați lista de generatoare de grafice de dependență gratuite aici.