Keskustelimme viime viikolla yksityisellä sektorilla työskentelevien ystävieni kanssa koodauskäytänteistä, erityisesti koodiarviointien käytöstä laskennallisessa tieteessä. Olen kirjoittanut syksyllä 2016 hieman samasta asiasta: laskennallisten ohjelmien lähdekoodien jakamisesta ja paremmasta dokumentoinnista julkaisujen yhteydessä.

Vaikka lähdekoodin jakaminen on yleistynyt viimeisen kolmen vuoden aikana, ei se ole edelleenkään itsestäänselvyys. Olen tunnistanut kolme syytä, mitkä vaikeuttavat avoimen koodin yleistymistä omalla alallani: koodi on liian epäselvää julkaistaviksi, koodi on vanhaa tai tarvittavaa teknistä osaamista ei ehdi ottaa haltuun koodin julkaisemista varten. Tunnistan näitä syitä myös itsessäni.

Hyvät koodauskäytännöt vähentäisivät ongelmia ja tekisivät koodista helpoimmin julkaistavaa. Laskennallisen mallin kirjoittamiseen pätevät pitkälti samat neuvot kuin muihinkin tietokoneohjelmiin. Kattava listaus hyvistä käytännöistä löytyy esimerkiksi täältä. Koodi sisältää tietokoneelle annettavien laskentaohjeiden lisäksi myös koodin kirjoittajan lisäämiä kommentteja, joissa kerrotaan, mitä koodin on tarkoitus tehdä. Omalla alallani olen huomannut koodien olevan usein hyvin kommentoituja, mutta toivomisen varaa on kuvaavissa muuttujannimissä ja ennen kaikkea versionhallintaohjelman käyttämisessä.

Laskennallisten mallien lisäksi tutkijat kirjoittavat paljon pieniä ohjelmia eli skriptejä, joilla tehdään esimerkiksi julkaisussa käytettävä kuva tai analysoidaan dataa. En pitkään kiinnittänyt skriptien tekemiseen hyvien käytäntöjen mukaisesti huomioita, mikä teki vanhoihin projekteihin palaamisen vähintäänkin haasteelliseksi. Kun tein viimeisintä julkaisuamme (julkaisun preprint, eli vertaisarvioimaton versio löytyy täältä), kiinnitin huolellisiin skriptien tekemiseen huomioita. Julkaisussa tehtiin käytännössä kahdenlaisia kuvaajia, joten kirjoitin molempien kuvaajien tekemiseen omat funktiot ja jaoin varsinaiset skriptit, joilla kuvat tehtiin, omiin kansioihinsa. Lisäksi kopioin kaikki analyysikoodit säännöllisesti ryhmämme GitLab-palvelimelle. Jätin tarkoituksella skriptit kaikkien nähtäville, mikä pakotti minut pitämään koodin luettavana. Näillä yksinkertaisilla muutoksilla koodien avaaminen uudestaan tuli huomattavasti kivempaa tässä kuussa, kun julkaisun vertaisarvioinnit saapuivat.

Koodiarvioinnit olisi hyvä tapa välittää hyviä koodauskäytäntöjä tutkijalta toiselle. Olen kuullut monenlaisia tapoja tehdä koodiarviointeja, joista parhain kuhunkin projektiin löytyy vain kokeilemalla. Internet on kuitenkin pullollaan erilaisia kehyksiä ja yleisiä ohjeita hyvälle koodiarvioinnille. Näkisin, että menestyksekkäässä koodiarvioinnissa keskitytään yhteen mallin ominaisuuteen tai yhteen skriptiin kerrallaan. Kestoltaan tällainen arviointi voisi kestää vaikkapa 30 minuuttia. Tärkeäksi näen myös, että arvioija on valmistautunut esimerkiksi miettimällä, miten itse toteuttaisi arvioitavan ominaisuuden ja arvioija on varmistanut, että koodi on hyvin luettavaa ja toimii. Koodiarviointien ilmapiiri olisi mielestäni aina positiivinen ja kannustava. Tavoitteena pitäisi mielestäni olla, että molemmat oppivat arvioinnista

Koodiarvioinnit ja hyvät koodauskäytännöt saattavat tuntua ensin turhalta. Minä näen niissä valtavasti potentiaali tutkijoiden ajan säästämiselle ja työn helpottamiselle. Hyvin dokumentoitu ja uudestaan käytettävä koodi on hitaampaa kirjoittaa kuin kertakäyttöiset skriptit, mutta tuottavat toistettavampaa tiedettä. Uskon, että jokainen tutkija, joka tarvitsee ohjelmointia työssään, on kokenut sen, kun vanhoista koodeista on etsitty päivätolkulla virheitä, jotta päästään samaan tulokseen kuin aiemmin.