Pericolele dependenței codului terților

Dacă vă abonați la un serviciu dintr-un link de pe această pagină, Reeves and Sons Limited poate câștiga un comision. Vezi noastre declarație de etică.

Există câteva lucruri foarte bune despre modul în care funcționează software-ul pe Internet. Pentru început, există o imensă rețea neoficială de milioane de oameni care contribuie la un depozit imens de fragmente de cod care ajută la alimentarea multor milioane de aplicații.

De fiecare dată când vedeți un mic link în partea de jos a unei pagini web pe care scrie „Powered by So-And-So”, sunteți martorul acestui efect de colaborare în acțiune.

Și, desigur, principalul motiv pentru care oamenilor le place această partajare și colaborare terță parte este că vă poate economisi multe ore în timpul de dezvoltare, pentru că nu reinventați ceva care există deja.

Dar chiar și cu aceste mari beneficii ale sistemului de partajare a codului terță parte, există o mulțime de motive pentru care ați putea dori să evitați utilizarea acestor fragmente de cod, așa cum urmează să vedem...

1. Potențiale riscuri de securitate

Deoarece aproape tot codul care conduce orice pe Web este open source, este un pariu corect că, dacă există vreo sarcină utilă rău intenționată într-o anumită aplicație, aceasta va fi descoperită rapid de comunitatea dezvoltatorilor și corectată rapid.

Dar multe dintre aceste fragmente de cod sunt descărcate de sute sau chiar de mii de ori pe zi și nu fiecare echipă administrativă face o treabă bună de a menține un sistem sigur de partajare a codului.

Cu cât este mai mare și mai complexă o aplicație, cu atât este mai ușor să o infectați adăugând câteva linii de cod într-un loc obscur. Aproape nimeni nu își dă timpul să examineze fiecare linie de cod dintr-o aplicație, deoarece, în general, presupune că codul poate fi de încredere.

Un programator înalt calificat poate face de obicei o treabă bună de a ascunde natura rău intenționată a codului și doar un alt programator înalt calificat își va da seama care este scopul său ... dacă este detectat fragmentul de cod rău intenționat.

2. Nu-l deții

Aceasta este de fapt o combinație de probleme. Primul este că este posibil să fiți supuși diferiților termeni de licențiere. Când aveți mai multe fragmente de cod utilizate într-o singură pagină web sau aplicație, este posibil să fiți supuși mai multor termeni și condiții de licențiere diferite, iar unele dintre acestea pot fi de fapt în conflict unul cu celălalt.

Desigur, aproape nimeni nu se deranjează să citească aceste liste plictisitoare de termeni și condiții, dar asta poate fi o greșeală.

În special, ar fi o greșeală dacă o anumită condiție din acordul de licență v-ar determina să încălcați o lege în țara dvs. de origine sau în țara în care se află serverul dvs.

Cealaltă problemă este că, dacă nu dețineți cod, nu aveți control asupra lui și este posibil să nu înțelegeți neapărat tot ce face sau cum funcționează.

Asta înseamnă că dacă cineva face o modificare a codului, s-ar putea să fii blocat cu această modificare, mai ales dacă instalezi cu fidelitate actualizări, patch-uri, upgrade-uri și versiuni noi de îndată ce sunt lansate ca stabile sau dacă te bazezi în întregime pe livrarea de conținut. rețele pentru soluțiile dvs. terțe.

3. Adesea primești mult mai mult decât ai nevoie

Codul terță parte funcționează de obicei pentru a face treaba dorită, dar uneori conține tot felul de caracteristici suplimentare de care nu aveți nevoie și probabil că nu le veți folosi niciodată.

În unele cazuri, nu puteți elimina aceste funcții suplimentare cu ușurință sau chiar deloc. S-ar putea de asemenea să fii nevoit să faci compromisuri. Funcția poate face ceva foarte aproape de ceea ce intenționați, dar nu exact ceea ce intenționați. Faceți schimb de lucruri extraordinare de dragul de a avea mai puțină muncă de făcut, iar asta nu este întotdeauna o tranzacție bună.

4. Nivelurile multiple de dependență de terți pot duce la probleme reale

Multe proiecte open source folosesc aceleași fragmente de cod de la terți în moduri diferite pentru a-și produce software-ul. De cele mai multe ori nu este un lucru rău, dar poate duce la probleme.

În zilele noastre, mulți dezvoltatori nici măcar nu instalează fragmentele pe care le folosesc, ci le extrag în timpul execuției din rețelele de livrare de conținut la cerere. Pericolul acestui lucru a fost ilustrat spectaculos de Incidentul Left-Pad din 2016.

Fiecare lanț este atât de puternic cât veriga lui cea mai slabă. Această înlănțuire a dependențelor înseamnă că, dacă orice verigă de-a lungul lanțului este ruptă sau compromisă, întregul lanț este expus riscului de defecțiune. În unele situații, asta ar putea fi destul de costisitor.

Nimeni nu ar fi bănuit puterea conținută în cele 11 linii de cod conținute în acea mică funcție benignă numită Left-Pad, dar când acea legătură de lanț anume a eșuat, a oprit multe site-uri mari.

Cea mai mare parte a fost că majoritatea oamenilor care foloseau Left-Pad habar n-aveau că îl folosesc, ce face sau cum să rezolve problema. După cum sa menționat la punctul 2, dacă nu îl dețineți, este posibil să nu îl înțelegeți neapărat.

Left-Pad a fost o funcție foarte simplă care adaugă doar câteva spații în partea stângă a unei linii pentru a se asigura că linia are lungimea corectă. Acum problema aici este că orice programator competent ar putea replica cu ușurință acea funcționalitate.

Nu este absolut necesar ca vreo aplicație să depindă de această funcție terță parte și totuși mii de site-uri web foloseau software care o includea, inclusiv Netflix, Facebook și Reddit. A fost doar o lovitură de noroc că în acest caz a fost o funcție foarte simplă care a rupt lanțul, și nu o funcție cu adevărat complicată care avea propriul lanț de dependențe.

Concluzia este că, dacă o poți construi singur, probabil ar trebui!

În cele din urmă, decizia cu privire la utilizarea blocurilor de cod ale terților în proiectul dvs. se reduce la o serie de decizii complicate care nu ar trebui niciodată luate cu ușurință. Factorii pe care trebuie să îi luați în considerare sunt securitatea, legalitatea, costul, timpul și stabilitatea.

Pentru a simplifica procesul de decizie, probabil că va ajuta următoarea condiție de testare.

DACĂ oricare dintre acești factori este adevărat:

  • funcția dorită este simplă
  • tu (sau echipa ta) ai capacitatea de a crea funcția
  • există suficient timp pentru a crea funcția
  • aplicația dvs. are nevoie de o bună securitate
  • aveți îngrijorări cu privire la potențiale probleme juridice asociate cu licențierea terților
  • este important ca aplicația dvs. să nu dea greș niciodată

ATUNCI ar trebui să-l construiești singur,

În caz contrar, ar putea fi mai eficient să utilizați funcțiile terților, cu condiția să fiți conștienți de potențialele probleme și să aveți o strategie pentru ceea ce veți face dacă apar aceste probleme.

Bogdan Rancea

Bogdan este membru fondator al Inspired Mag, acumulând aproape 6 ani de experiență în această perioadă. În timpul liber îi place să studieze muzică clasică și să exploreze artele vizuale. Este destul de obsedat și de fixe. El deține deja 5.

Comentarii Răspunsuri 0

Lasă un comentariu

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate *

Evaluare *

Acest site folosește Akismet pentru a reduce spamul. Aflați cum sunt procesate datele despre comentarii.