Hyvä koodi ei synny pelkästään teknisestä osaamisesta.
Teollisten koneiden ja laitteiden ohjelmistokehityksessä hyvä koodi näkyy ennen kaikkea lopputuloksessa: kone toimii suunnitellusti, muutoksia voidaan tehdä hallitusti ja järjestelmä pysyy ylläpidettävänä myös vuosien päästä.
InSolutionin kesäpäivillä pysähdyimme pohtimaan tätä koodauksen filosofiaa käsitelleessä workshopissa. Keskustelu kiteytyi muutamaan perusasiaan: ongelman ymmärtämiseen, hyvään arkkitehtuuriin, datan omistajuuteen, uudelleenkäytettävyyteen, dokumentointiin ja kokonaisuuden testaamiseen.
Ensin ongelma, sitten ratkaisu
Teollisessa ohjelmistokehityksessä pelkkä tekninen määrittely ei riitä. Ohjelmoijan täytyy ymmärtää myös koneen, laitteen tai prosessin toimintaa ja sitä, mitä ratkaisulla tavoitellaan.
Jos käyttöliittymässä käyttäjä esimerkiksi syöttää koneelle arvon, ei riitä, että tieto saadaan teknisesti välitettyä PLC:lle. Tekijän pitää ymmärtää myös, mitä arvo prosessille tarkoittaa, millaiset arvot ovat sallittuja ja mitä tapahtuu poikkeustilanteissa.
Tärkein kysymys ei siis ole ensimmäisenä “miten tämä toteutetaan?”, vaan “Mitä tällä oikeastaan halutaan saada aikaan?” Kun tavoite ymmärretään oikein jo alussa, myös teknisille ratkaisuille saadaan oikea suunta.
Hyvä arkkitehtuuri näkyy erityisesti silloin, kun jokin muuttuu
Harva rakentaa tarkoituksella vaikeasti ylläpidettävää järjestelmää. Spagettia syntyy yleensä vähitellen: yksi poikkeus tänne, toinen tuonne ja kiireessä tehty ratkaisu vielä kolmanteen paikkaan. Siksi arkkitehtuuria kannattaa miettiä ennen toteutusta.
Hyviä kysymyksiä ovat esimerkiksi:
- Mitä tapahtuu, jos tämä laite tai komponentti vaihdetaan myöhemmin toiseen?
- Voidaanko samaa ratkaisua hyödyntää seuraavassa konemallissa?
- Missä data sijaitsee ja kuka sitä saa muuttaa?
- Ovatko eri järjestelmän osien väliset rajapinnat selkeitä?
Täydellistä modulaarisuutta ei tarvitse tavoitella, eikä kaikkea kannata abstrahoida varmuuden vuoksi. Tavoitteena on rakenne, jossa yhden asian muuttaminen ei hajota viittä muuta.
Kuka omistaa datan?
Yksi workshopin keskeisistä aiheista oli datan omistajuus.
Erityisesti PLC-ohjelmoinnissa järjestelmä pysyy selkeämpänä, kun jokaisella kokonaisuudella on vastuu omasta toiminnastaan ja datastaan.
Ajatellaan esimerkiksi kuljetinta. Kuljettimella voi olla moottori, antureita ja tilatietoja. Hyvässä rakenteessa kuljetin tietää oman toimintansa ja ohjaa moottoria tarvitsemallaan tavalla sen sijaan, että järjestelmän muut osat muuttaisivat suoraan moottorin sisäisiä tietoja.
Kaikkea dataa ei tarvitse eikä pidä jakaa kaikkialle.
Selkeät vastuut ja rajapinnat tekevät kokonaisuudesta helpommin ymmärrettävän, testattavan ja uudelleenkäytettävän.
Uudelleenkäyttö syntyy suunnittelusta
Uudelleenkäytettävyys ei tarkoita vanhan projektin kopioimista uuteen hakemistoon.
Se syntyy hyvästä arkkitehtuurista, selkeistä rajapinnoista ja sopivasti rajatuista kokonaisuuksista. Kun hyväksi todettuja ratkaisuja voidaan hyödyntää uudelleen, seuraavan projektin tekeminen helpottuu.
Kaikkea ei kuitenkaan kannata rakentaa yleiskäyttöiseksi.
Hyvä suunnittelu on myös kykyä tunnistaa, mitkä asiat kannattaa vakioida ja mitkä ratkaista projektikohtaisesti.
Kommentoi miksi, älä kaikkea
Hyvän koodin pitäisi kertoa mahdollisimman pitkälle itse, mitä siinä tapahtuu. Kommentin tärkein tehtävä on usein kertoa, miksi jokin ratkaisu on tehty.
Erityisen tärkeää tämä on silloin, kun toteutus poikkeaa normaalista toimintatavasta esimerkiksi asiakkaan prosessin, laitteen ominaisuuden tai aiemmin havaitun ongelman vuoksi.
Tekoäly helpottaa nykyään myös dokumentointia ja kommentointia, mutta määrä ei korvaa laatua. Olennaista on jättää seuraavalle tekijälle riittävästi tietoa ratkaisujen taustoista ilman, että tärkeä tieto hukkuu massaan.
Testaa kokonaisuus, älä vain omaa osuuttasi
Projektissa voidaan testata jokainen yksittäinen osa onnistuneesti ja silti päätyä järjestelmään, joka ei asiakkaan näkökulmasta toimi.
PLC-ohjelmoija on testannut oman osuutensa. Käyttöliittymän tekijä omansa. Sitten käyttäjä painaa HMI:n nappia – eikä mitään tapahdu. Siksi yksi tärkeimmistä testauksen periaatteista on yksinkertainen:
Testaa koko ketju HMI:n napista PLC:n lähtöön ja fyysisen laitteen toimintaan asti.
Asiakasta ei lopulta kiinnosta, toimivatko järjestelmän yksittäiset komponentit irrallaan.
Asiakasta kiinnostaa, toimiiko kokonaisuus.
Hyvä koodi ei synny sattumalta
Hyvän ohjelmistokehittäjän tunnistaa teknisestä osaamisesta, mutta teollisissa järjestelmissä yhtä tärkeää on kyky ymmärtää koneen toimintaa, asiakkaan tarvetta ja ratkaisun koko elinkaarta.
Huippukoodari kysyy ensin, mitä oikeasti ollaan ratkaisemassa. Hän miettii, kuka datan omistaa, rakentaa selkeät rajapinnat, dokumentoi olennaisen ja varmistaa lopuksi, että kokonaisuus toimii käyttäjän näkökulmasta asti.
Hyvä koodi ei ole itseisarvo, vaan osa toimivaa kokonaisuutta.
Parhaimmillaan se ratkaisee oikean ongelman, on ymmärrettävää myös seuraavalle tekijälle ja antaa tilaa muutoksille ilman, että koko paketti pitää rakentaa uudestaan.
Haluatko jatkaa aiheesta?
Jos teollisen ohjelmistokehityksen, automaation tai ohjelmistoarkkitehtuurin kehittäminen on ajankohtaista, jutellaan mielellämme lisää. Ota yhteyttä
