Lauri Oikarinen työskentelee Profit Softwarella koodin laadun varmistuksen parissa ja toimii myös tiiminvetäjänä Tampereella.

Laadukas koodi on ohjelmiston rakennusmateriaali 

Ohjelmistojen kehityksessä ja rakennusalalla tietyt, yhteiset teemat toistuvat. Kummankin kohdalla huonosti tehty työ kostautuu pitkällä aikavälillä, jopa katastrofaalisesti. Rakennusvirheet, kuten huonolaatuinen koodikin, saattavat paljastaa vaikutuksensa vasta vuosien päästä aloituksesta. Sijoitus alkuvaiheessa saattaisi pelastaa kerrostalon kosteusvauriokorjaukselta tai ohjelmiston uudelleenkirjoitukselta.  

Koodin laatu on siis ohjelmistojen rakennusmateriaalina tärkeää. Ohjelmistot koostuvat eri osiensa lähdekoodeista, mitä pidetään usein ainoana koodina. Mutta näiden lisäksi koodiksi voidaan lukea kirjoitetut testit sekä esimerkiksi pilvialustojen ympäristökonfiguraatiot (infra as code). Tämän kaiken koodin laatua voidaan kuitenkin mitata ja parantaa samoilla menetelmillä. 

Tunnista laadukas koodi kolmesta peruspilarista 

Koodin laatua voidaan tarkastella toisistaan hyvinkin erilaisista näkökulmista ja alan ammattilaisille muodostuu omia mielipiteitä asiasta. Tässä blogissa tuodaan esille yksi näkökulma, jota muokkaa varmasti Profit Softwaren luonne finanssialan tuote- ja etenkin konsultointiyrityksenä. Toisen mielestä laatu saattaisi syntyä eleganteista suunnitteluratkaisuista, pienestä rivimäärästä tai vaikkapa ohjelmointikielen uusimpien ominaisuuksien käyttämisestä. Me lähdemme kuitenkin peruspilareista liikkeelle.

Laadukas koodi on:

  1. tarkoituksensa täyttävää,
  2. luettavaa sekä ymmärrettävää ja
  3. ylläpidettävää sekä laajennettavaa.

Vaikka virheet ohjelmistoissa ovat toistaiseksi vääjäämätön tosiasia, on hyvin vaikea arvioida koodi laadukkaaksi, jos se ei tee sitä, mitä sen kuuluisi. Vaatimusten täyttäminen laskettakoon laadun perusvaatimukseksi. Toisaalta koodin ei ole syytä olla monimutkaisempaa kuin sen tarkoitus vaatii. Huomioitavaa on kuitenkin se, että täysin virheettömänkin ohjelmiston koodi saattaa olla laadultaan heikkoa!

Koodi kirjoitetaan sen seuraavaa lukijaa varten; sen kohdeyleisö on hyvin selvä. Palvelinta tai palvelun käyttäjää ei (välittömästi) kiinnosta miten hyvin koodi on kirjoitettu. Sen sijaan Niilissä ei tarvitse virrata kovin paljoa vettä ennen kuin huonosti kirjoitettu koodi muuttuu hieroglyfeiksi sitä tulkitsevalle koodarille. Luettava ja helposti omaksuttava koodi on elinehto ohjelmiston pitkää elinikää suunnitellessa.

Joskus koodi voi olla joko yksinkertaista tai eleganttia. Korkea abstraktiotaso mahdollistaa tiiviin ja elegantin koodin, jonka ymmärrettävyys toisaalta kärsii. Toisaalta liian yksinkertainen koodi saattaa venyä tarpeettoman monimutkaiseksi tai pitkäksi. Tähän ei valitettavasti voi antaa yhtä ohjetta vaan on edettävä tilanne kerrallaan.

Viimeinen tärkeä laadun mittari on ylläpidettävyys ja laajennettavuus. Erilaiset suunnittelu- ja toteutusratkaisut saattavat lyödä nämä seikat lukkoon jo ohjelmiston alkuvaiheessa. Niiden muuttaminen on hankalaa eliniän varrella.

Huonolaatuinen koodi paljastuu useimmiten ylläpitovaiheessa. Muutokset koodiin paljastuvat suuritöisiksi ja tapahtuu regressiota: jo kertaalleen toimiviksi todetut toiminnot rikkoutuvat. Huonon koodin parissa työskentelevän koodarin motivaatio saattaa heikentyä ja ratkaisuja joudutaan sovittamaan huonon koodin ympärille: ”purkkaa puukotuksien päälle”. Kaiken tämän vaikutukset voinee jokainen päätellä.

Kola-tiimissä työskentelee koodin laadun asiantuntijoita eri puolilta Suomea.

Miten parannamme koodin laatua Profitilla 

Profit Softwarella olemme tunnistaneet tarpeet aktiivisesti varmistaa ja parantaa koodin laatua. Tähän tarkoitukseen perustimme kokonaisen Kola-tiimin, jonka juuret johtavat vuosien takaiseen koodin laadun parantaminen -nimellä kulkeneeseen projektiin. Nykyisin tiimissä on edustajia Tampereen, Espoon, Porin sekä Lahden konttoreilla. Näemme, että laadun parantaminen tapahtuu kolmella tavalla: tunnistamalla, kouluttamalla ja varautumalla. Seuraavassa käymme läpi hieman mihin toimenpiteisiin meillä on ryhdytty.

Huonolaatuisen koodin tunnistamisella saavutamme pari hyötyä. Tällöin tulee mahdolliseksi koodin muuttaminen, tässä tapauksessa laadukkaammaksi ilman vaikutuksia toiminnallisuuteen, eli refaktorointi. Joskus tämä on järkevä tapa toimia, toisinaan ei. Mutta se, mitä voidaan ja pitäisikin tehdä jokaisessa tapauksessa, on oppiminen ja kehittyminen.

Edellä mainittu refaktorointi helpottuu testauksen avulla, jota ilman on vaikea varmistua toiminnallisuuden ehjänä pysymisestä. Tähän tarkoitukseen soveltuu parhaiten yksikkö- sekä käyttöliittymätestit, jotka varmistavat, että toteutuksen muuttuessa toiminnallisuus on ennallaan. Ilman erillisiä testejä refaktoroijan täytyisi tuntea muutettava osa-alue läpikotaisin ja käydä kaikki toiminnallisuus läpi manuaalisesti, mikä jo kuulostaa lähes mahdottomalta. Tiimimme pyrkimyksenä on huolehtia siitä, että testejä kirjoitetaan jatkossa riittävästi.

Menetelmiä tunnistamiseen on useita. Pidämme esimerkiksi ryhmäkatselmointeja, joissa käydään koodimoduuli läpi porukalla ja kirjataan kaikkien osallistujien huomiot. Näin sekä koodin kirjoittaja että osallistujat oppivat hyvistä ja huonoista piirteistä. Toinen menetelmä on enemmän tai vähemmän jokaisen muutoksen läpikäynti. Useassa projektissamme on käytössä tapa, jossa toisen silmäparin täytyy aina käydä koodi läpi ennen sen käyttöönottoa. Viimeinen tunnistamisen väline ovat koodianalysaattorit, jotka käyvät läpi koodia ja antavat raportteja löydöksistään. Sääntöjä voidaan viilata tarpeen mukaan. Näiden työkalujen analyysit tukevat ihmisten läpikäyntiä ja tekevät sitä väsymättä ja johdonmukaisesti.

Koulutus ja oppiminen Kolan kulmakivinä

Kuitenkin tärkein toimenpide, jolla varmistamme koodin laatua, on koulutus, eli oppiminen ja kehittyminen. Mikään analyysi ja läpikäynti maailmassa ei riitä, jos samat asiat toistuvat joka projektissa. Rakentavalla palautteella pyrimme saamaan aikaan positiivista muutosta koodarien työskentelytapoihin ja kirjoitetun koodin laatuun. Jos kuluvan projektin aikana ei kaikkia piirteitä saada viimeisen päälle kuntoon, seuraavassa ne ovat jo paremmalla mallilla. Oppimisen menetelminä käytämme pitkälti samoja kuin tunnistamisessa: ryhmäkatselmointeja sekä kahden silmäparin menetelmää. Lisäksi suunnitelmissamme on kuukausittain julkaistavat opetusjulkaisut.

Automatisointi ja DevOps-toimintamalli auttavat tuomaan kaikki nämä menetelmät yhteen ja ne ansaitsisivat aivan oman blogikirjoituksensa. Automatisoimalla käännös-, testaus- ja asennusputkia saamme esimerkiksi välitöntä palautetta analysaattoreista sekä tulokset testiajoista.

Kaikki tämä synnyttää työtä ja kustannuksia. Mikäli aikatauluihin ja budjetteihin ei ole sisällytetty osuutta laadun varmistukselle, se valitettavan usein jää säälittävään sivuosaan. On ehdottoman tärkeää, että projektipäälliköt, myyjät ja vieläpä asiakkaan edustus huomioivat nämä asiat projektin suunnitteluvaiheessa. Tässäkin asiassa proaktiivisuus säästää rahaa pitkällä aikavälillä siinä missä reaktiivisuus saattaa kostautua kalliisti.

Laadukas koodi hyödyttää kaikkia 

Kaiken tämän laadunvarmistuksen tuotteena mainittakoon kaksi oleellista asiaa, jotka ovat kytköksissä suoraan toisiinsa: koodariemme kehittyminen sekä asiakastyytyväisyys. Kun koodarimme tuottavat laadukkaampaa koodia, asiakkaamme järjestelmät ovat helpompia ylläpitää sekä jatkokehitys on halvempaa ja turvallisempaa. Näin säästyy aikaa sekä rahaa ajan kuluessa. Proaktiiviset ja tarkoituksenmukaiset toimenpiteet laadunvarmistuksessa edistävät siis merkittävästi ohjelmistoprojektin onnistumista. 

 


Jos kiinnostuit työskentelystä Profitilla, tutustu avoimiin työpaikkoihimme urasivuillamme: careers.profitsoftware.com