Avainsana: ohjelmistokehitys
Puhutaan kielillä! Hiotun hyvän koodin syntysanat suomeksi
Millä kielillä ja teknologioilla Hiotun hyvä koodi syntyy ja mihin tarkoituksiin niitä käytetään? Kuten aina: riippuu siitä, mitä ollaan tekemässä. Jos olet hakeutumassa alalle ja erityisesti meille töihin tai harjoitteluun, on hyvä olla perehtynyt johonkin tässä jutussa mainituista kielistä ja alustoista.
Web-sovellusten backend
Olipa kerran .NET Framework, Microsoftin kehittämä ja omistama Windows-ympäristössä toimiva komponenttikirjasto, ja sen kumppanina C-kielen pohjalta hieman Javaa lainaten rakennettu C#-ohjelmointikieli. .NET Frameworkin kehittäminen alkoi kuitenkin jumittaa ja hidastua, mikä suljetussa lähdekoodissa aina on riskinä. Uudempaa aikaa edustaakin sen pohjalta syntynyt .NET, jota kehitetään avoimena lähdekoodina. Laaja kehittäjäyhteisö on taannut sille selkeän julkaisurytmin ja jatkuvan kehityksen, ja myös C#-kielestä syntyy jatkuvasti uusia versioita, joihin lainaillaan hyviä ominaisuuksia muista kielistä. Merkittävänä erona uusi .NET tukee useita käyttöjärjestelmiä (pois lukien eräät työpöytäsovellusten kehittämiseen tarkoitetut menetelmät).
.NET tarjoaa paljon valmiita paketteja ja kirjastoja kaikkeen mahdolliseen, esimerkiksi tietokantoihin ja lokitukseen. C#-kieltä ei perusteiden lisäksi juuri opeteta oppilaitoksissa, vaan se otetaan haltuun usein esimerkiksi Javan pohjalta.
.NETin sovellusympäristöt ja -kohteet ovat laajentuneet open sourceen siirtymisen jälkeen. Yksi uusimmista tulokkaista on web-selaimiin tarkoitettu Blazor, jonka avulla voi tuottaa frontendin käyttöliittymäkoodia C#-kielellä, kevyessä ajonaikaisessa ympäristössä. Hiotussa seurataan mielenkiinnolla tätä kehitystä, samoin kuin mobiilisovellusten rakentamiseen soveltuvaa .NET MAUI -alustaa.
Konenäkö: C++
Erityisesti konenäköohjelmoinnissa ja siihen liittyvässä kuvankäsittelyssä tarvitaan toista ceetä, eli C++kieltä, koska se on suorituskyvyltään nopeampaa kuin tulkkauksen vaativa C#. Tilanne voi tosin muuttua tulevaisuudessa, kun C#-kielestäkin on mahdollista tehdä natiivikäännöksiä AOT-teknologialla. Konenäkösovelluksissa on näihin päiviin asti toteutettu jonkin verran asioita myös matalan tason assembly-kielellä erityisen aikakriittisiin tarkoituksiin, mutta tämän tarve on vähentynyt merkittävästi kääntäjien kehityksen ja C++-laajennusten myötä. Eräs tällainen optimoijaa helpottava laajennus on Halide, joka generoi assemblya ja optimoi sen ajonaikaisesti huomioiden sekä rinnakkaistamisen, vektoroinnin että välimuistin hallinnankin. Kehitys kehittyy, käsityö vähentyy.
Selainohjelmointi
Selainohjelmointia on tehty perinteisesti JavaScriptillä, mutta viime vuosina Hiotulla sen on korvannut Typescript, jossa on monia C#-kieltä muistuttavia piirteitä. Selaimet eivät osaa käyttää TypeScriptiä sellaisenaan, vaan lähdekoodi transpiloidaan JavaScriptiksi selaimissa ajamista varten. TypeScriptille ja JavaScriptille on tarjolla runsaasti valmiita paketteja käyttöliittymäkehitykseen. TypeScriptin kaverina kulkee usein käyttöliittymäkirjasto React.js.
Neuroverkot
Neuroverkkoja Hiotussa opetetaan ja testataan Pythonilla; muita vakavasti otettavia vaihtoehtoja ei oikeastaan ole. Pythonilla opetettua mallia hyödynnetään tuotantokäytössä C++-koodilla, jota yleensä kutsutaan C#:n kautta. Yleensä neuroverkkojen alimman tason laskenta tapahtuu grafiikkasuorittimella, mutta GPU:n käsittely tapahtuu valmiiden kirjastojen kautta.
NET-alustalle on myös olemassa oma koneoppimisalusta ML.net, joka mahdollistaa neuroverkkojen opettamisen ja käyttämisen täysin C# käyttäen. Tulokset ja käytettävyys eivät kuitenkaan ole toistaiseksi olleet Hiotun standardeille riittävän hyviä, joten Pythonilla mennään. Hiotun neuroverkkotiimi seuraa neuroverkkojen kehitystä tiiviisti, mm. Papers With Code -sivuston avulla: mitä uutta on tekeillä ja tarjolla?
Sulautetut ympäristöt
Hiotulla embedded-maailmaa ei juurikaan tehdä, mutta toisinaan sillekin on tarvetta. Esimerkkinä voidaan mainita radiotekniikkaa hyödyntävä mittalaite, jonka mittaamat signaalit analysoidaan mikrokontrollerilla ennen PC:lle lähettämistä. DSP:lle ja mikrokontrollerille ohjelmisto kirjoitetaan yleensä C-kielellä ja assemblyllä.
Pitääkö olla guru-ninja-koodivelho-yksisarvinen?
Uusille työntekijöille tai harjoittelijoille kannustukseksi: kaikissa yllä mainituissa tekniikoissa ei meille tullakseen tarvitse olla guru. Erityisesti .NETistä löytyy paljon koulutusmateriaalia, ja uusien asioiden parissa aloitetaan pieninä palasina. Koodin kirjoittamiseen saa apuja sekä ihmisiltä että tekoälyltä.
Varsinaisten koodauskielten lisäksi HTML-merkintäkielen ja SQL-tietokantakielen osaamisesta on kovasti hyötyä, koska niitä hyödynnetään liki kaikissa projekteissa. Mitä ihmiskieliin tulee, suomesta, englannista ja oulusta on eniten apua, vaikka todistetusti myös turun murteella projekteja on viety maaliin loistavin tuloksin.
Kuva Gerd Altmann Pixabaystä
Softanostajan opas eli ohjelmistonostohousujen sovitusohje
Mistä ostajan ja myyjän pitäisi puhua, kun ollaan hankkimassa uutta ohjelmistoa? Mitä on syytä miettiä ensin ja mitä kannattaa ottaa huomioon, kun kauppaa hierotaan? Tässä Hiotun hyviä neuvoja, vuosien kokemuksella!
Ohjelmistokehitys ja kaiken perimmäinen merkitys
Miksi koko hommaan lähdetään? Aivan ensimmäisenä pitää selvittää, mitä ohjelman on tarkoitus tehdä – mikä on koko hankkeen syvin tarkoitus?
Ostajan kannattaa ehdottomasti kirjata ylös myös omasta mielestä päivänselvät asiat, etenkin omaan liiketoimintaan liittyen. Vaikka softakehittäjät ja myyjät olisivat kuinka viisaita ja taitavia omassa työssään, ajatuksia he eivät osaa lukea. Hyvää tulee harvoin niin, että ensin vain ideoidaan ja sitten heitetään pallo kokonaan softatalolle.
Käytännön prosessien pitää olla selvillä: mitä halutaan helpottaa? Mitkä ovat ne auttavat tekijät, jotka saisivat prosessin sujuvammaksi? Onko prosessista jo olemassa kuvaus? Jos prosessia aletaan selvitellä ja muutella siinä vaiheessa, kun softaa jo ollaan tekemässä, voi seurata kalliita ja epämiellyttäviä yllätyksiä.
Ohjelmistoissa on myös paljon asioita, jotka eivät sellaisenaan näy käyttäjälle ja joita ei tule ajatelleeksi. Nämä liittyvät esimerkiksi tietoturvaan tai laajennettavuuteen. Nälkä usein kasvaa syödessä, mutta jos softan laajennettavuutta ei oteta huomioon alusta pitäen, se ei välttämättä onnistu myöhemmin lainkaan.
Mitä maksaa?
Jos aiempi kokemus ja mielikuva on valmistuotteista, räätälöidyn ohjelmiston hinta voi yllättää kokeneenkin softanostajan. Kannattaa silti ensin selvittää, löytyisikö jo entuudestaan olemassa oleva valmistuote, joka on riittävän lähellä vastaavaa. Koska vertailu ei välttämättä ole helppoa, voit käyttää ammattilaista eli konsulttia apuna. Jos käy ilmi, että valmiit ratkaisut eivät riitä tarpeisiisi, kannattaa siirtyä osaavan ohjelmistoyrityksen hoteisiin.
On syytä myös miettiä, mihin olet valmis ja paljonko olet halukas investoimaan. Jos budjetti on tiukka ja projektisi pieni ja selkeä, voi saada kiinteähintaisen tarjouksen. Mutta mitä enemmän on selviteltävää ja aivan uusien asioiden tekemistä, sitä todennäköisemmin mennään tuntityöllä, jolle toki voidaan arvioida raamit.
Entä jos projektin aikana tulee uusia ideoita, jotka eivät mahdukaan raamiin? Silloin on syytä järjestää erikseen jatkoprojekti, joka arvioidaan erikseen.
Mitä ostetaan ja keneltä?
Ostajan on hyvä selvittää, ollaanko softaan ostamassa pelkkä käyttöoikeus vai immateriaalioikeudet. Ellei myyjä ota tätä selkeästi esiin, kysy. Miten projektille tai ohjelmiston käytölle esimerkiksi käy, jos ohjelmiston toteuttanut yritys myydään kesken prosessin? Voiko koodia vielä käyttää?
Riskianalyysi ylipäätään on suositeltavaa. Isoille, kokeneille ostajille on tuttua selvittää kumppanin taustat, mutta sama tulisi ensikertalaistenkin opetella. Millaiselta toimittajalta ollaan ostamassa? Millainen on taloustilanne, millaisia referenssejä yrityksellä on antaa? Millainen on maine?
Elinkaari ja tietoturva
Ohjelmiston elinkaarta kannattaa miettiä jo alusta lähtien. Mitä tapahtuu sen jälkeen, kun ohjelmisto on otettu käyttöön? Millaisia pilvipalveluita otetaan käyttöön? Millaisia tietoturva- ja muita päivityksiä tarvitaan? Millaista käyttökoulutusta? Mitä ylläpitosopimukseen kirjataan?
Tietoturvan suhteen on usein apua ulkopuolisesta testauskonsultista. Mitä kriittisempää toiminta on, sitä suuremmalla syyllä testaus kannattaa, vaikka siitä tulisikin lisäkustannuksia.
Kommunikaatio
Varaudu kertomaan selkeästi mitä haluat, toivot ja odotat. Avaa liiketoimintaasi, kerro budjetista, mieti riskejä. Muista ne itsestäänselvyydet: sinun alasi voi olla softantekijöille jotain aivan uutta. Tiedon pimittäminen – vahingossa tai tarkoituksella – on tuhon tie.
Toimittajalta on hyvä selvittää, ketkä tiimissä ovat mukana. Onko mukana kokemusta vai nuoria kykyjä, vai molempia? Avoimuus on tässäkin olennaista.
Alkukeskustelujen jälkeen ei aina ole syytä edetä suoraan tarjousvaiheeseen suunnittelemaan koko projektia. Jos ollaan tekemässä jotain ihan uutta esimerkiksi konenäön saralla, on usein fiksua aloittaa POCista eli konseptitodistuksesta tai pilottiprojektista, joissa asiat tarkentuvat. Niiden jälkeen tiedetään, kannattaako ylipäätään edetä, millä tavoin ja millaisista kustannuksista puhutaan.
Säännöllinen yhteydenpito projektin aikana on yhtä tarpeellista kuin perusteellinen aloitus. Missä mennään, onko tullut yllätyksiä tai uusia ideoita roadmapiin vietäväksi? Pysytäänkö arvioissa?
Softanostajan muistilista
Ennen ostohousujen prässäämistä kannattaa selvittää nämä asiat:
- Mitä on tarkoitus saavuttaa?
- Mitä uuden ohjelman on tarkoitus tehdä?
- Mihin prosessiin uusi ohjelmisto liittyy?
- Millainen prosessi on kokonaisuudessaan?
- Miten ohjelmisto auttaa tässä prosessissa?
- Minkä ongelman järjestelmä poistaa? Missä saadaan säästöjä?
- Häämöttääkö mielessäsi yksittäisen tarpeen sijasta pitempi projekti? Onko sille jo ajatuksissa etenemispolku?
- Onko jo olemassa valmistuote, joka ehkä täyttää tarpeesi?
- Millainen on budjettisi?
“Meidän ihmiset ruukaa tehdä parhaansa” – asiakasuskollisuus ei synny vippaskonsteilla
Hiotulla on vankka kokemus uskollisista asiakkaista. “Firman ensimmäinen asiakas on edelleen asiakkaamme – nyt jo kolmannen yrityksen kautta. Siitä ensimmäisestä tuli sittemmin osa Rautea, joka on nykyään meidänkin emoyhtiömme”, kertoo Hiotun toimitusjohtaja Satu Lapinlampi. “Kaikki asiakkaat eivät toki ole koko ajan tilaamassa, vaan palaavat asiaan aina kun tarvetta ilmenee.”
Uskotaan. Mutta miten tähän oikein päästään? Mitä pitää tehdä oikein?
“Kaikki lähtee siitä, että meillä tehdään niin hyvää työtä kuin mahdollista”, sanoo Lapinlampi. “Koodarit ovat asiakasrajapinnassa ja pystyvät hyvin kuuntelemaan asiakasta. Lisäksi meillä asiakasta ei sidota eikä rajoiteta: rakennettuihin ratkaisuihin annetaan laajat käyttöoikeudet, ja asiakas voi halutessaan jatkaa toisen toimijan kanssa. Me luotamme omaan tekemiseemme: asiakkaan pitämiseen ei tarvita vippaskonsteja.”
Asiakaspysyvyyttä ei ole Hiotulla varsinaisesti mitattu, mutta asiakkuuksia seurataan säännöllisesti. Jos asiakkuus ei jatku, sille on perustellut syyt: asiakkaan liiketoiminta on muuttunut tai päättynyt. Harvinaisissa tapauksissa syynä ovat olleet pitkittyneet muutostoiveet, joista ei ole projektin alussa ollut puhetta. Projektinaikaisia yllätyksiä pyritään taklaamaan etukäteen mahdollisimman hyvällä ennakkosuunnittelulla ja työmäärän arvioinnilla – tässä kantapääkokemus auttaa.
“Esimerkiksi web-projekteissa tyypillisesti Eirolan Mikko ensin juttelee asiakkaan kanssa, kyselee ja kirjoittaa tarvittavat kuvaukset. Sen jälkeen tehdään arvio: lasketaan ensin optimistinen Strömsö-skenaario, sitten mahdollisimman realistinen skenaario ja kolmanneksi pessimistinen skenaario. Näiden yhdistelmästä syntyy tietyllä kaavalla yleensä erittäin hyvin kutinsa pitävä lopullinen työmääräarvio.” Tarjoukseen arvio päätyy vaiheisiin palasteltuna: asiakas näkee, mistä hinta koostuu.
Vilpitön pyrkimys läpinäkyvyyteen
Konenäköpuolella ennakkoarviointi on vaikeampaa. Tämä johtuu yksinkertaisesti siitä, että usein tehdään asioita, joita ei ole ennen tehty. Olosuhteet asiakkaan tiloissa vaihtelevat, ja aina tarvitaan erilaisia kameroita ja muita kilkkeitä.
Pohjalla ovat tietysti yleiset IT-sopimusehdot: jos projektin aikana syntyy asiakkaasta johtuvia yllätyksiä, muistutetaan tuntihintamallista. Konenäköprojektienkaan työmääräarvioinnissa ei silti toki tikkaa heitetä, vaan nojataan kertyneeseen kokemukseen ja valistuneisiin arvauksiin. “Meillä on vilpitön pyrkimys läpinäkyvyyteen”, sanoo Lapinlampi. “Tätä asiakkaat arvostavat.”
Kaiken keskiössä ovat osaavat tekijät. “Meidän ihmiset ruukaa tehdä parhaansa. Ne nauttii, kun saa opetella uutta.”
Miten parhaansa tekemisen yrityskulttuuriin kasvetaan, kun mukaan tulee uusia ihmisiä?
“Uuden työntekijän kanssa pidetään aina ensin 1–2 tunnin kalvosulkeiset perusasioista. Tärkeät työsuhdejutut ovat senkin jälkeen kaikkien saatavilla Teamsissa”, kertoo Lapinlampi. “Mutta olennaista on käsitellä heti alkuun kaiken perusta: arvot, toimintatapa, asiakkaan kunnioittaminen. Edes selän takana ei puhuta pahaa.” Kehityskeskusteluissa tästä on tullut toimarillekin hyvää palautetta.
“Käsittämättömän hienoja asioita”
Millaisia asioita toimitusjohtaja itse arvostaa asiakaskokemuksessa?
“Olen valmis maksamaan enemmän hyvästä”, Lapinlampi toteaa. “En tarkoita luksusta, vaan henkilökohtaisuutta – oli kyseessä sitten B2C tai B2B. Meillä on esimerkiksi kahden hengen tilitoimisto, josta mielellämme pidämme kiinni: palvelu on joustavaa, neuvovaa ja opastavaa. Sama kokemus on liikelahjatoimittajasta – olemme käyttäneet samaa henkilöä jo vuosikausia. Tai vuokranantajamme Technopolis, ja erityisesti vastaanoton älyttömän mukava Teija: jos jotain tarvitaan niin sehän järjestyy.”
Hiotun suhteen asiakassuhteen ydin lienee tässä. “Meidän asiakkaat tekee siistejä juttuja, siis niin käsittämättömän hienoja asioita. Niistä on helppo innostua”, hehkuttaa Lapinlampi, mutta muistuttaa: “On mahtavaa, kuinka asiakkaita voidaan auttaa ihan yksinkertaisillakin softatoteutuksilla, vaikkapa excelöinnin korvaavalla web-sovelluksella tai tuotetietojen siirtymistä helpottavilla ratkaisuilla. Vaikka projekti olisi softaprojektina pieni, sillä voi olla jonkun asiakkaan tuottavuuden kannalta yhtä iso vaikutus kuin toiselle asiakkaalle on suurisuuntaisella sovelluksella.”
Hiottu testiautomaatio – näin sen teet!
Testiautomaatio on viime vuosina rynninyt ohjelmistokehitykseen, ja syystä. Aika on rahaa: manuaalitestaukseen verrattuna automaatiolla säästetään paljon, kun ihmiset voivat keskittyä toisiin asioihin. Kuulostaa ihmiskunnan ja yritysten unelmalta: jälleen yksi tarkkuutta vaativa, työläs, toisteinen ja aikaa vievä vaihe voidaan jättää tietokoneiden huoleksi. Vaan onkohan tuo ihan niin yksinkertaista?
“Testausta tehdään monella tasolla”, huomauttaa Kari Lapinlampi. “Koodaritasolla tehdään yksikkötestejä tietyn ominaisuuden tarkistamiseksi. Automaatiossa sen sijaan testataan koko järjestelmää päästä päähän, ja pidetään sekä vanhat että uudet ominaisuudet koko ajan mukana kuviossa.”
Automaatiolla saadaan helposti ajettua myös aiemmat testit nopeasti ja täsmälleen samalla tavalla. Näin varmistetaan, etteivät uudet muutokset aiheuta uusia ongelmia. Jos esimerkiksi testataan verkkosivustoa, automaatiotestaus voidaan ajoittaa yöajalle, ja katsoa tulokset seuraavana päivänä. Koodin laatu säilyy hyvänä – ja samalla koko lopputuotteen.
“Pintapuolisella käyttäjätestauksella ei mitenkään päästä samaan laadunvarmistustasoon kuin automaattitestauksella”, sanoo Kari Lapinlampi. “Isossa projektissa olisi ylipäätään mahdotonta, että ihminen tekisi kaiken. Toki ihmistyötäkin tarvitaan kokeilevaan testaamiseen.”
“Ja määrittelyyn”, lisää Jarmo Pylkkö. “Testien määrittelyä ei voi automatisoida: siihen tarvitaan joku, joka osaa kuvata, millaisia käyttötapauksia tiettyyn ominaisuuteen liittyy.”
Kun kehitys – runko, rakenne ja käyttöliittymä – ovat riittävän pitkällä, testit kirjoitetaan toteutettaviksi käyttöliittymää vasten. Kooditason testausta toki tehdään alusta pitäen, esimerkiksi tietokannan käyttötapoja.
Testeillä ei tutkita vain toiminnallisuuksia, vaan myös suorituskykyä. Onko vaste riittävän nopea? Kestääkö järjestelmä kuormitusta? Miten häiriötilanne syntyy? Millaisia häiriöt ovat? Kehityksessä tulee päivittäin vastaan tilanteita, joissa on riskinä, että aiemmin tehty paikkaus lakkaa toimimasta. Ilman testausta ja koodinmuutoksia asiakas saattaa esimerkiksi saada virheellisen kuvan jonkin prosessin toiminnasta. Väärää dataa tarjoava, mutta oikealta näyttävä toiminto on vaarallisempi skenaario kuin se, ettei mitään tapahdu.
Kertakorjauksesta ikivihreisiin
Ohjelmistokehityksen tahti on muuttunut olennaisesti viime vuosina. “Nykyään uusia ohjelmistoversioita tulee melkein viikon välein”, sanoo Kari Lapinlampi. Ohjelmistoista on tullut ikivihreitä, evergreenejä: koko ajan julkaistaan pieniä parannuksia. “Uusienkin versioiden pitää silti olla testattuja. Versioiden julkaisukäytännöt ovat muuttuneet perusteellisesti: jatkuvan ohjelmistokehityksen CI/CD-putkessa uuden version julkaisu voi tapahtua nappia painamalla.”
Testi kertoo, onko mahdollista edetä. Koodari kehittää yksikkötestit, ja ne yhdistetään pääkehityshaaraan. Hiotulla testiautomaatiosofta Jenkins huomaa tämän, hakee uuden koodin ja ajaa testit. Jenkins on integroituna versionhallintaan. Jenkinsin kaverina käytössä on Python-pohjainen Robot Framework.
Ohjelmistoja on tarjolla paljon. “Jenkins valikoitui meidän käyttöömme, koska se on avointa lähdekoodia, ollut pitkään olemassa, hyvin tuettu ja taipuu mihin käyttöön tahansa”, toteaa Jarmo Pylkkö.
Vaikka asioita kuinka automatisoitaisiin, perusasiat pysyvät.
“Viestintä on todella tärkeää”, korostaa Kari Lapinlampi. “Kehittäjän ja testaajan välisen kommunikaation täytyy pelata.”
“Niin se tahtoo mennä, että ensin kehittäjä vie iloisena muutokset pilveen”, Jarmo Pylkkö nauraa. “Sitten testaaja lähestyy koodaria ja vetää tämän alas: lopetapa juhliminen ja palaa jäljittämään ja korjaamaan.”
(Kuvan piirteli parhaan ymmärryksensä mukaan Crayion-tekoäly. Emme ostaisi siltä käytettyä polkupyörää.)