Parhaita työpäiviä ovat sellaiset, jossa päivän lopuksi voi todeta tuhonneensa pari tuhatta riviä ohjelmakoodia.
– H-P, Webscale

Monelle IT-järjestelmien kanssa tekemisissä oleville ei-kehittäjille saattaa tulla yllätyksenä se, että kypsän järjestelmän kehittämisessä vaikein asia on monesti vanhentuneiden osien tuhoaminen. Johtuen juuri siitä vaikeudesta se on itselleni monesti suurinta työn iloa tuottava hetki, kun vihdoin saa teilattua lopullisesti pois vanhentuneita komponentteja.

Laadukasta ylläpitoa vai toteutuksen täysi uusiminen?

Tyhjästä rakennettavien järjestelmien alkukuukausina tuotetaan merkittävä määrä koodirivejä päivittäin, mutta saavutettaessa kypsä vaihe vuoden-kahden vaiheilla olennaisesti enemmän työtä vaatii järjestelmän laadukkaana ylläpitäminen ja olemassa olevien käyttötapausten tukeminen. Tästä pari vuotta eteenpäin ja väistämättömät muutostarpeet ovat jo lisänneet koodikannan kokoa, mutta vanhasta ei ole voitu vielä luopua, koska vuosien aikana niiden järjestelmien ympärille on ehditty jo rakentaa uusia integraatiopisteitä ja käyttötarpeita.

Kehitystiimien työ ei ole aivan halpa resurssi, jolloin kehitysjohtajilta tarvitaan valistuneisuutta sijoittaa riittävä osuus tästä resurssista vanhojen järjestelmien tarkasteluun, perkaukseen ja hyvälaatuisena pitämiseen. Ohjelmistokehityksessä työkalujen, ohjelmointikielien ja kirjastojen luonteeseen liittyy se, että näitä kehitetään jatkuvasti ja vanhoista kirjastoista löydetään toinen toistaan luovempia tapoja väärinkäyttää niiden tietoturvahaavoittuvuuksia. Mikäli komponentteja ei kehitetä, loppuu niiltä usein myös tuki ja se tarkoittaa samalla haavoittuvuuksien jäämistä pysyväksi. Tällöin ainoat vaihtoehdot ovat lähteä tukemaan komponenttia itse tai luopua komponentin käytöstä ja kirjoittaa oma toteutus uusiksi.

Monesti tällaisessa tilanteessa, jossa on pakko uusia oma toteutus on paras tilaisuus arvioida kyseisen toteutuksen tarpeellisuutta nykyhetkessä ennen työn käyttämistä sen päivittämiseen.

Tarpeeksi aikaa vanhojen koodirivien läpikäyntiin

Usein huomaan itse, että jo muutenkin vanhentuneet komponentit ylläpitävät vanhentunutta toimintatapaa, josta haluttaisiin eroon ylläpidettävyyden vuoksi: Jos sama toiminnallisuus voidaan muuttaa noudattamaan nykyistä toteutustapaa, voi hyvinkin olla kannattavaa tuhota vanha toteutus kokonaan ja päivittää riippuvuudet uudelle mallille.

Tämä voi näyttäytyä uuden kehityksen kannalta tyhjäkäyntinä, josta ei saada uusia ominaisuuksia esiteltäväksi. Se on kuitenkin mielekkäämpää tyhjäkäyntiä kehitystiimin kannalta kuin vanhojen ongelmakomponenttien ylläpitämiseen kuluva aika. Varsinkin kun tiimeissä on väistämättä vaihtuvuutta tekijöissä, niin vanhentuneiden komponenttien ylläpitoon voi olla yllättävänkin vaikea löytää kunnon osaamista ja ymmärrystä niiden sielunelämästä. Kehittäjänä arvostan sitä, että on säännöllisesti käytettävissä aikaa vanhojen palikoiden perkaamiseen, päivittämiseen ja erityisesti sen liputtamiseen, että järjestelmä pitää tuhota ja päivittää uuteen.

Suurelle suomalaiselle laitevalmistajalle tehdyssä muutaman vuoden pituisessa projektissa laskimme loppuvaiheessa keskimääräisen päivittäisten koodirivien määrän muutoksen per kehittäjä. Lopputulema oli noin +5 riviä koodia per päivä. Vanhat toteutukset oli hyvissä ajoin ajettu alas ja sillä saatu pidettyä kehitystyö mielekkäänä.