Ajatuksia ohjelmistoriippuvuuksista

Nykypäivän runsaat ohjelmistokirjastot tarjoavat käyttövalmiita toiminnallisuuksia, joita voi helposti tuoda työn alla olevaan projektiin. Nykyisten hallintatyökalujen myötä on koodin uusiokäyttäminen helpompaa kuin koskaan.

Samalla täytyy kuitenkin pitää mielessä, että kun ohjelmistoriippuvuuksien määrä nousee, myös riippuvuuksiin liittyvät riskit kasvavat. Mitä enemmän ohjelmistossa on riippuvuuksia, sitä enemmän ohjelmisto on riippuvainen muista ihmisistä – heidän osaamisestaan ja halustaan pitää riippuvuus vakaana ja turvallisena käyttää.

Tehdäänpä pieni ajatuskoe. Sanotaan vaikka, että projektissa on 100 riippuvuutta, jotka ovat 99-prosenttisen varmoja ja turvallisia. Äkkivilaukselta vaikuttaa siltä, että projekti on kohtuullisen vakaa ja turvallinen.

Eipä keulita, vaan turvaudutaan matematiikkaan.

Laskutoimituksen yksinkertaistamiseksi pelkistetään tilanne seuraaviin olettamuksiin:
• jokainen riippuvaisuus on itsenäinen eikä riipu muista riippuvuuksista
• jokainen riippuvuus on vakaa 0,99 todennäköisyydellä

Todennäköisyys sille, että kaikki 100 riippuvuutta ovat turvallisia ja vakaita on 0,99^100 = 0,37 eli 37 %. Toisin sanoen, on olemassa 100 % - 37 % = 63 prosentin riski, että ohjelmiston riippuvuuksien kanssa tulee jotakin ongelmia. Riski on aika korkea – on todennäköisempää, että ongelmia tulee, kuin että niitä ei tule.

Tosielämä ei tietenkään ole näin yksioikoista: Riippuvuudet ovat myös kytköksissä toisiinsa ja riippuvuuksien hyödyt voivat olla riskejä merkittävämmät. Riippuvuuksien määrä vaihtelee ja yksittäisen riippuvuuden luotettavuus voi olla reilusti yli 99 %. Tekemäni oletukset ja ilmaisemani huolenaiheet voivat olla monen ohjelmistoprojektin kannalta lähes merkityksettömiä tai hyvä testausjärjestelmä nappaa ajoissa kiinni kriittiset riippuvuudet jne, jne, jne.

En sano, että meidän pitäisi luopua ohjelmistoriippuvuuksista.

Niitä saa ja pitää jatkossakin käyttää, mutta harkiten.

Russ Cox kirjoitti vastikään kiinnostavan tekstin ohjelmistoriippuvuksien hallinnoinnin ongelmista ehdottaen muutamia keinoja, joilla lieventää riippuvuuksien riskejä.
• tarkista riippuvuus
• testaa riippuvuus
• luo abstraktio riippuvuudelle
• eristä riippuvuus
• vältä riippuvuus
• päivitä riippuvuus
• pidä riippuvuuksiasi silmällä

Vahva lukusuositus, jos syvällisempi perehtyminen aiheeseen kiinnostaa!

Lienee helppo huomata, että minä kannatan "enemmän on vähemmän" -periaatetta riippuvuuksien käytössä. Mielipiteeseeni on varmasti vaikuttanut se, että olen työskennellyt todella pitkään saman tuotteen, saman koodin kimpussa (lähes 19 vuotta sitten koskin ensimmäistä kertaa koodiin, jonka versiota N tänä päivänä työstän). Pitkäikäisessä tuotannossa on pakko harkita tarkkaan, mihin riippuvuuksiin, niiden päivityksiin ja uudelleenarviointiin haluaa itsensä sitoa vuosiksi eteenpäin.

Vuosien saatossa olen muutaman kerran kahlannut läpi sen tilanteen, jossa riippuvuus on päivitetty, jotta se on yhteensopiva ohjelmointiympäristön päivityksen kanssa. Olen uudelleenarvioinut kaikki riippuvuudet, vaihtanut jonkun riippuvuuden toiseen ja luopunut jostain (ei-kriittisestä) ominaisuudesta yhteensopimattomuuden vuoksi.

Myöhemmin olen saanut tilaisuuden nauttia siitä runsaudesta, joita nykyiset avoimen lähdekoodin ohjelmistokirjastot tarjoavat. Olen ollut hippasilla ohjelmistokirjastojen päivitysten kanssa ja korjannut ongelmia, joita päivitykset ovat aiheuttaneet. Joissain tapauksissa koodimme on ollut rikki kaikessa hiljaisuudessa, ja vika on paljastunut riippuvuuden päivityksen myötä. Toisinaan riippuvuuden päivitys on vaatinut oman koodimme päivitystä yhteensopivaksi. Oli miten oli, vaikka arvostankin kirjastojen runsautta ja käytänkin niitä aika paljon, olen sitä mieltä, että vähemmän on usein enemmän.

Riippuvuudet ovat hyviä siinä tilanteessa, kun ne ratkaisevat ison ongelman. Pienemmistä ongelmista puhuttaessa lainaisin Rob Piken sananlaskua:

"Pieni kopiointi on parempi kuin pieni riippuvuus."

Lähteet

• Russ Cox, "Our Software Dependency Problem", January 2019. https://research.swtch.com/deps
• Rob Pike, "Go Proverbs," November 2015. https://go-proverbs.github.io/

Johan Jansson
tekninen johtaja