Kaikki koodi on jossain vaiheessa legacya

Kaikki koodi vanhenee. Vanhentunut koodi muuttuu legacyksi. Jossain vaiheessa koodauksen Lara Croft kaivelee softan hautaholveja ja löytää tämän legacy-koodin. On meidän nykyhetken koodareiden käsissä miten koodin Tomb Raider käsittelee meidän tuotosta. Räjäytetäänkö kaikki palasiksi vai viedäänkö vaaroja uhmaten talteen. No ehkä koodia ei talteen viedä, saattoi mennä liian pitkälle vertauskuva tässä kohtaa. Mutta joka tapauksessa legacy-koodi voi kertoa tai olla kertomatta taustalla olevan tarinan löytäjälleen.

Legacy-koodi ei sinänsä ole pahaa tai väärää. Usein kyseessä on silloisten speksien pohjalta ja tarjolla olevien teknologisten ratkaisujen avulla rakennettu kokonaisuus. Hyvin usein vielä suunniteltu täyttämään sen hetkinen tai korkeintaan muutaman seuraavan vuoden tarve. Parhaimmassa tapauksessa sama koodi pienin muutoksin vie järjestelmää eteenpäin useita vuosia.

Oman kokemuksen mukaan koodi muuttuu legacyksi siinä vaiheessa, kun siitä tulee pullonkaula kehityksen suhteen. Tämä voi ilmetä skaalautuvuuden suhteen, laajennettavuuden suhteen tai vaikkapa ymmärrettävyyden suhteen. Koodin riippuvuudet voivat vanhentua, vaatimukset muuttua tai ympäristö vaihtua. Syitä on monia. Ja pullonkaula ei välttämättä ole iso, se vain rajoittaa kehitystä jollakin tapaa.

Olen huomannut että hyvin normaali tapa korvata legacy-koodia on refaktorointi. Pieni pala toimivassa järjestelmässä kirjoitetaan osittain uusiksi vastaamaan paremmin uusia vaatimuksia. Refaktorointia tapahtuu joskus hyvinkin tiheässä tahdissa, mutta koodipohjan kasvaessa sykli pitenee. Refaktoroinnissa suurena apuna on tietämys järjestelmän toiminnasta, olemassa olevat testit sekä dokumentaatio niin koodissa kuin vaikkapa vaatimusmäärittelyjen muodossa. Tämä on sitä osaa, jossa koodi (ja sen ympärillä olevat asiat) kertoo koodarille syitä olemassaololle. Tarina avautuu.

Sitten on se pimeämpi puoli legacy-koodista. Se tunkkainen holvi, jossa jokainen polku on täynnä kaikennäköisiä ansoja. Ja oikealta tuntuva suunta osoittautuu lopulta vääräksi. Tämä koodi on sitä, josta legacy on perinyt pahamaineisuutensa. Tieto järjestelmän toiminnasta on vajavaista ja pirstaloitua. Koodin dokumentointi ei ole ajantasaista tai sitä vain ei ole. Testit (mitkä testit?) eivät ole ajan tasalla jos niitä edes on. Jokainen optimistinen koodari muuttuu pahamaineisen legacy-koodin myyötä kyyniseksi ja pessimistiseksi. Ainakin väliaikaisesti.

Legacyn kanssa ei asiat kuitenkaan ole näin mustavalkoisia. Kyse ei ole edes janasta, jossa toisessa päässä on “hyvää” koodia ja toisessa päässä “pahaa” koodia. Ehkä kyseessä on joku matriisi, johon koodin eri osa-alueet jotenkin asettuvat. Huonossa koodissa voi olla jotain hyvää ja hyvässä jotain huonoa.

Meillä nykyhetken koodareilla tuntuu olevan kiire saada näkyvää aikaiseksi. Dokumentaatio on välttämätön paha, joka tehdään jos muistetaan. Syyllistyn tähän itse omissa projekteissa ja tulevaisuuden minä tuijottaa pahalla silmällä dokumentoimatonta koodia. Ja kiroaa omaa lyhytkatseisuuttaan. Niinpä tässä sanon nyt niin itsellenikin kuin myös muille koodareille: Dokumentoikaa koodi.

Kirjoittakaa niitä kommentteja, miksi joku rajatapaus vaatii ehtolauseen tässä. Kommentoikaa funktiot, metodit, parametrit ja palautukset. Kun refaktoroitte, kommentoikaa. Erityisesti niissä tapauksissa, joissa seuraatte tiedon kulkua ja joku muuttujanimi, funktiokutsu tai palautuva arvo on jotain muuta kuin mitä nimi antaa olettaa. Älkää jättäkö ainoaksi kommentiksi jotain tiketin numeroa. Versiohistoria on tikettien numeroita varten. Ja ehkä tärkeimpänä, jättäkää paikat siistimmiksi kun luovutatte koodin eteenpäin kuin mitä ne olivat siinä vaiheessa kun koodin itse saitte.