Pericolele dependenței codului terților

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”, asistați la acest efect de colaborare în acțiune.

Și, bineînțeles, principalul motiv pentru care oamenilor le place această partajare și colaborare terță parte este că vă poate economisi multe ore în timp de dezvoltare, deoarece nu reinventați ceva care există deja. Dar chiar și cu aceste mari avantaje 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. Riscuri potențiale de securitate

Deoarece aproape tot codul care conduce orice pe Web este open source, este un pariu corect că, dacă există o sarcină utilă rău intenționată într-o anumită aplicație, acesta va fi descoperit rapid de comunitatea de dezvoltatori ș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țineți

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, nimeni nu se deranjează să citească aceste liste obositoare de termeni și condiții, dar asta poate fi o greșeală. În special, ar fi o greșeală dacă o condiție din acordul de licență ar fi determinat să încălcați unele legi din țara dvs. de origine sau din țara în care este situat serverul dvs.

Cealaltă problemă este că, dacă nu dețineți cod, nu aveți control asupra acestuia și este posibil să nu înțelegeți în mod necesar tot ceea ce face sau cum funcționează. Asta înseamnă că dacă cineva modifică codul, s-ar putea să rămâneți blocat de această modificare, mai ales dacă instalați cu fidelitate actualizări, patch-uri, upgrade-uri și versiuni noi de îndată ce sunt lansate ca stabile sau dacă vă bazați în totalitate pe livrarea conținutului rețele pentru soluțiile dvs. terță parte.

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

Codul terților funcționează de obicei pentru a face treaba pe care o doriți, dar uneori conține tot felul de funcții suplimentare de care nu aveți nevoie și probabil că nu le veți folosi niciodată. În unele cazuri, nu puteți elimina aceste caracteristici suplimentare cu ușurință sau chiar deloc. Poate că va trebui să faceți și compromisuri. Funcția poate face ceva foarte apropiat de ceea ce intenționați, dar nu exact ceea ce intenționați. Tranzacționezi grozav de dragul de a avea mai puțină treabă, iar asta nu este întotdeauna un lucru bun.

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

Multe proiecte open source folosesc aceleași fragmente de cod terță parte în moduri diferite de 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 rulării din rețelele de livrare a conținutului la cerere. Pericolul acestui lucru a fost ilustrat spectaculos de Incidentul din partea stângă din 2016.

Fiecare lanț este la fel de puternic ca și veriga sa cea mai slabă. Acest î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 care ar putea fi destul de costisitoare. Nimeni nu ar fi bănuit puterea conținută în cele 11 linii de cod conținute în acea funcție benignă, numită Left-Pad, dar atunci când acea verigă de lanț nu a reușit, a adus întreruperea multor site-uri web urlând. Cea mai mare parte a acestuia a fost că majoritatea oamenilor care foloseau Left-Pad nu aveau idee că îl folosesc, ce a făcut sau cum să rezolve problema. După cum sa menționat la articolul 2, dacă nu îl dețineți, este posibil să nu îl înțelegeți în mod necesar.

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 reproduce cu ușurință această funcționalitate. Nu este absolut necesar ca nicio 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.

imaginea antetului prin amabilitatea Stephanie Tucker

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.