Me maksamme (teknistä) velkaa

Pääsääntöisesti me vastaamme projektin tuloksena syntyneen verkkopalvelun ylläpitämisestä ja jatkokehittämisestä koko palvelun elinkaaren ajan. Tästä johtuen saamme usein jälkiviisastella omien ratkaisujemme kanssa ja miettiä, miten hommat olisi pitänyt tehdä, jotta myöhemmät ongelmat oltaisiin voitu välttää. Tämä on paitsi jonkin verran turhauttavaa, myös parhaimmillaan oikein opettavaista.

Tekninen velka

Ohjelmistokehityksessä puhutaan usein ”teknisestä velasta”, jolla alunperin tarkoitetaan hätäisesti tai ajattelematta tuotettua koodia, jossa siis on tavallaan otettu tuotannollista velkaa ylläpidettävyyden tai jatkokehitettävyyden kustannuksella. Nykyään teknisen velan katsotaan olevan kokonaisuudessaan rakennetun ja optimaalisen toteutuksen erotus. Oli miten oli, kantavana ajatuksena kuitenkin on se, että huonot toteutukset kasvattavat velkaa enemmän kuin hyvät.

Vaan mitenkäs sitten tietää, mikä olisi optimaalinen toteutus ja miten kaukana siitä ollaan? Miten voi siis tietää, kuinka paljon teknistä velkaa kustakin toteutuksesta syntyy? No, ei mitenkään. On mahdotonta täysin tarkkaan tietää, mitä tarpeita toteutukselle on tulevaisuudessa. Toisaalta monella toteutustavalla on todennäköisesti useita ominaisuuksia, joiden perusteella niiden voidaan väittää olevan optimaalisia. Teknisen velan arviointi toteutusta tehdessä onkin erittäin hankalaa, ja velan lopullinen määrä selviää vasta joskus paljon myöhemmässä palvelun elinkaarivaiheessa. Silloin saattaa ilmoille lennähtää rennon letkeä lausahdus: ”Ei per*e! Kuka tanopää tän on tehnyt!?”

Koska juuri mikään toteutus ei ole optimaalinen, kertyy teknistä velkaa lähes kaikesta. Tekninen velka on kuitenkin hyvin epätasa-arvoista, ja sen vaikutukset jakautuvat erittäin epätasaisesti toteutuksen sisällä. Alempien arkkitehtuurikerrosten tekninen velka saattaa määrällisesti olla suurta, mutta se ei välttämättä palvelun elinkaaren aikana koskaan eräänny maksettavaksi. Toisaalta ylempien kerrosten velan vaikutukset voivat rajautua hyvinkin pieneen osaan kokonaisuudesta, mutta velka kasvaa korkoa nopeammin, jos juuri tuohon osaan tehdään kehitystä usein. Teknisen velanoton voidaan joissakin tapauksissa katsoa olevan myös laskelmoitu riski: mutkat voidaan jossakin kohtaa vetää todella suoriksi, jos on erittäin epätodennäköistä, että tästä aiheutuvaa merkittävää teknistä velkaa koskaan pitäisi maksaa takaisin.

Aivan kuin universumissa muutenkin, entropia kasvaa myös kehitettävässä verkkopalvelussa sen elinkaaren aikana.

Velkataakka painaa

Tekninen velka vaikeuttaa toteutuksen ylläpitoa ja jatkokehitystä. Käytännössä velan vaikutukset näkyvät esimerkiksi seuraavilla tavoilla:

• Näennäisen yksinkertaisen muutoksen tekeminen palveluun edellyttää huomattavan suuren osan uudelleensuunnittelua. Tämä aiheuttaa suuren potentiaalin erilaisille virheille eri puolilla palvelua.
• Jatkokehitystoimenpiteiden myötä palveluun lisätään duplikaatteja aikaisemmin totetetuista toiminnoista. Tämä ilmenee usein sellaisissa tilanteissa, joissa aikaisemmat toteutukset on liian tiukasti liitetty niiden käyttökonteksteihin.
• Kehittäjät eivät uskalla koskea aikaisempiin toteutuksiin ollenkaan, vaan rakentavat uudet toiminnallisuudet kiertämällä olemassa olevan koodin ohi. Tämä aiheuttaa paitsi duplikaattitoteutuksia, myös erittäin hämmentäviä rakennelmia, jotka paisuttavat teknistä velkaa entisestään.

Aivan kuin universumissa muutenkin, entropia kasvaa myös kehitettävässä verkkopalvelussa sen elinkaaren aikana. Jatkuvasti lisääntyvä kompleksisuus tuo mukanaan kaaosta ja alkujaan elegantin suoraviivaiset toteutukset kasvavat vuosien saatossa sienirihmastoa muistuttavaksi labyrintiksi. Voiko tätä vastaan jotenkin taistella?

Velallisen elämää

Teknistä velkaa ei voi välttää, joten sitä on opittava hallitsemaan ja sen kanssa on opittava elämään. Tärkeimmät ohjeet teknisen velan aiheuttamien ongelmien minimoimiseen ovat:

• Koodaa vasta, kun olet ratkaissut ongelman: Selvitä ensin, mitä ongelmaa olet taklaamasssa. Kun ongelma on selvillä, ratkaise se. Kun olet keksinyt ratkaisun, tee toteutus.
• Refaktoroi jatkuvasti: Muista jättää koodi parempaan kuntoon kuin missä se oli ennen kuin koskit siihen. Muista ennenaikaisen optimoinnin vaarat ja pidä YAGNI-periaate mielessäsi. Refaktoroinnin tavoitteena on parantaa koodin ilmaisua ja tuoda esiin tarkoitus koodin takana.
• Maksa velkaa pois: Jotta tekninen velka ei jossakin osassa palvelua pääse kasvamaan ylivoimaiseksi, sitä kannattaa suunnitellusti maksaa pois. Ihan kaikenlaisista toteutuksista ei vain yksinkertaisesti saa kalua, vaikka niitä kuinka refaktoroisi. Mitä aikaisemmassa vaiheessa nämä toteutukset pystytään vaihtamaan järkevämpiin, sitä edullisempaa se on.

Teknistä velkaa ei kannata pelätä, mutta se pitää osata tunnistaa ja sen hillitsemiseksi on tehtävä jatkuvasti työtä. Tekninen konkurssi ei ole kenenkään etu.