Farerne ved tredjeparts kodeafhængighed

Der er et par rigtig gode ting ved den måde, software fungerer på Internettet. Til at begynde med er der et enormt uofficielt netværk af millioner af mennesker, der bidrager til et enormt arkiv med kodefragmenter, der hjælper med at drive mange flere millioner applikationer.

Hver gang du ser et lille link nederst på en webside, der siger "Powered by So-And-So", er du vidne til denne samarbejdseffekt i aktion.

Og selvfølgelig er hovedårsagen til, at folk kan lide denne tredjepartsdeling og samarbejde, at det kan spare dig for mange timer i udviklingstid, fordi du ikke genopfinder noget, der allerede eksisterer. Men selv med disse store fordele ved tredjeparts kodedelingssystemet er der mange grunde til, at du måske vil undgå at bruge disse kodefragmenter, som vi er ved at se ...

1. Potentielle sikkerhedsrisici

Da næsten al kode, der driver noget på Internettet, er open source, er det en rimelig indsats, at hvis der er nogen ondsindet nyttelast i en given applikation, vil den hurtigt blive opdaget af udviklerfællesskabet og hurtigt rettet.

Men mange af disse kodefragmenter downloades hundreder eller endda tusinder af gange om dagen, og ikke hvert administrativt team gør et godt stykke arbejde med at opretholde et sikkert kodedelingssystem.

Jo større og mere kompleks en applikation er, jo lettere er det at inficere det ved at tilføje et par kodelinjer et eller andet uklart sted. Næsten ingen tager sig tid til at undersøge hver kodelinje i en applikation, fordi de generelt antager, at koden kan stole på.

En højtuddannet programmør kan normalt gøre et godt stykke arbejde med at tilsløre kodens ondsindede natur, og kun en anden højtuddannet programmør kan finde ud af, hvad dens formål er ... hvis det ondsindede kodefragment opdages.

2. Du ejer ikke det

Dette er faktisk en kombination af problemer. Den første er, at du muligvis er underlagt forskellige licensvilkår. Når du har flere kodefragmenter, der bruges på en enkelt webside eller et program, kan du faktisk være underlagt flere forskellige licensbetingelser og vilkår, og nogle af disse kan faktisk være i konflikt med hinanden.

Selvfølgelig generer næppe nogen at læse disse kedelige lister over vilkår og betingelser, men det kan potentielt være en fejltagelse. Især ville det være en fejl, hvis en eller anden betingelse i licensaftalen får dig til at være i strid med nogle love i dit hjemland eller i det land, hvor din server er placeret.

Det andet problem er, at hvis du ikke ejer kode, har du ingen kontrol over den, og du kan ikke nødvendigvis forstå alt, hvad den gør, eller hvordan den fungerer. Det betyder, at hvis nogen foretager en vis ændring af koden, kan du hænge fast med den ændring, især hvis du trofast installerer opdateringer, programrettelser, opgraderinger og nye versioner, så snart de er frigivet som stabile, eller hvis du helt er afhængig af indholdslevering netværk til dine tredjepartsløsninger.

3. Man får ofte meget mere, end man har brug for

Tredjepartskode fungerer normalt for at udføre det job, du ønsker, men sommetider indeholder det alle slags ekstra funktioner, som du ikke har brug for og sandsynligvis aldrig vil bruge. I nogle tilfælde kan du ikke fjerne disse ekstra funktioner let eller endda overhovedet. Du skal muligvis også gå på kompromis. Funktionen kan gøre noget meget tæt på det, du har til hensigt, men ikke nøjagtigt hvad du har til hensigt. Du handler ubehagelighed for at have mindre arbejde at gøre, og det er ikke altid en god handel.

4. Flere niveauer af tredjepartsafhængighed kan føre til reelle problemer

Mange open source-projekter bruger de samme tredjeparts-kodefragmenter på forskellige måder til at fremstille deres software. Det meste af tiden er ikke en dårlig ting, men det kan føre til problemer. I disse dage installerer mange udviklere ikke engang de fragmenter, de bruger, men trækker dem på kørsel fra indholdsleveringsnetværk efter behov. Faren for dette blev illustreret spektakulært af Left-Pad-hændelsen i 2016.

Hver kæde er kun så stærk som dens svageste led. Denne kæde af afhængigheder betyder, at hvis et led overalt i kæden er ødelagt eller kompromitteret, er hele kæden i fare for funktionssvigt. I nogle situationer kan det være ganske dyrt. Ingen ville have mistænkt for kraften i de 11 kodelinjer, der var indeholdt i den godartede lille funktion kaldet Left-Pad, men da netop dette kædelinje mislykkedes bragte det mange store websteder til at stoppe. Størstedelen af ​​det var, at de fleste mennesker, der brugte Left-Pad, havde ingen idé om, at de brugte det, hvad det gjorde, eller hvordan man løser problemet. Som nævnt i punkt 2, hvis du ikke ejer det, kan du muligvis ikke nødvendigvis forstå det.

Left-Pad var en meget enkel funktion, der blot tilføjer et par mellemrum til venstre side af en linje for at sikre, at linjen har den rigtige længde. Nu er spørgsmålet her, at enhver kompetent programmerer let kunne gentage denne funktionalitet. Der er absolut ikke behov for, at noget program afhænger af denne tredjepartsfunktion, og alligevel brugte tusinder af websteder software, der inkluderede den, inklusive Netflix, Facebook og Reddit. Det var bare et held og lykke, at det i dette tilfælde var en meget enkel funktion, der brød kæden, og ikke en rigtig kompliceret funktion, der havde sin egen afhængighedskæde.

Den nederste linje er, hvis du kan bygge det selv, burde du sandsynligvis!

I sidste ende afgør beslutningen om, hvorvidt man skal bruge tredjeparts kodeblokke i dit projekt, ned til en række komplicerede beslutninger, som aldrig bør tages let. De faktorer, du skal overveje, er sikkerhed, lovlighed, omkostninger, tid og stabilitet.

For at gøre beslutningsprocessen enklere vil følgende testtilstand sandsynligvis hjælpe.

HVIS nogen af ​​disse faktorer er sandt:

  • den ønskede funktion er enkel
  • du (eller dit team) har evnen til at oprette funktionen
  • der er masser af tid til at oprette funktionen
  • din ansøgning har brug for god sikkerhed
  • du er bekymret for potentielle juridiske problemer forbundet med tredjepartslicenser
  • det er vigtigt, at din ansøgning aldrig mislykkes

Derefter skulle du bygge det selv,

ELSE kan det være mere effektivt at bruge tredjepartsfunktioner, forudsat at du er opmærksom på de potentielle problemer, og du har en strategi for, hvad du vil gøre, hvis disse problemer opstår.

header image med tilladelse fra Stephanie Tucker

Bogdan Rancea

Bogdan er et grundlæggende medlem af Inspired Mag og har akkumuleret næsten 6 års erfaring i denne periode. På fritiden kan han lide at studere klassisk musik og udforske billedkunst. Han er også ganske besat af fixies. Han ejer allerede 5.