6 näkökulmaa koodin laatuun: Näin ohjelmistokehitystiimit sopivat yhteisistä käytännöistä

Kun puitteet ovat kunnossa, kehittäjät pääsevät tuottamaan toimivaa koodia alusta alkaen. Mitä laatua varmistavia valintoja projektitiimi tekee uuden hankkeen alkaessa? Lead Developer Joni Helin lähestyy aihetta kuudesta näkökulmasta: 1) teknologiavalinnat ja tiimin kokoonpano, 2) projektitemplaatit, 3) parhaisiin käytäntöihin sitoutuminen, 4) versionhallinta, 5) infrastruktuuri sekä 6) koodin katselmointi ja kommentointi.

1. Teknologiavalinnat ja tiimin kokoonpano

Kun uuden ohjelmistoratkaisun esiselvitystyö on tehty ja asiakkaan tarpeet ovat selvillä, on aika kääriä hihat. Karkea teknologiapino ohjailee käytännön ratkaisuja projektin alkuvaiheessa.

“Cinialla iso osa-alue back-endin puolella on Java-ekosysteemi – ei tietysti siihen rajoittuen”, Joni Helin sanoo antaen esimerkin ympäristöstä, jota varten talossa on kertynyt runsaasti hyviä toimintamalleja.

Projektin resursointivaiheessa pohditaan näitä kysymyksiä:

• Ketkä ovat osaamisensa ja kokemuksensa puolesta parhaat henkilöt projektiin?
• Mikä on riittävä tiimin koko laadun varmistamiseksi?
• Onko kokoonpanossa sopivassa suhteessa senioreita ja kokemusvuosiltaan nuorempia tekijöitä, jotta jatkuvuus varmistuu jopa vuosien mittaisten, strategisten asiakaskumppanuuksien aikana?

“Haluamme välttää sitä, että ihmiset naulattaisiin kiinni projekteihin. Silloin osaavat tekijät kyllästyvät ja lopulta vaihtavat työnantajaa. Ilmiö on tullut aiemmin urallani vastaan moneen otteeseen, mutta Cinialla tämä on mielestäni tiedostettu hyvin. Pyrimme huolehtimaan siitä, että jokaisella on oikeasti mahdollisuus vaikuttaa siihen, miten he voivat edetä projektista toiseen.”

2. Projektitemplaatit

“Projektit ovat yksilöllisiä, tiimit ovat yksilöllisiä. Siksi emme Cinialla sanele erityisen tiukkoja käytäntöjä valmiiksi. Jokainen tiimi käy läpi tietyt, organisaatiotasolla määritellyt asiat. On projektin asia, millä tavalla ne huomioidaan”, Helin kertoo.

Esimerkiksi nämä check-listat auttavat sisäisten pelisääntöjen sopimisessa:

• Cinia Agile Projects Playbook: ketterän kehittämisen käytännöt, sprintin vaiheet ja eri roolien vastuut
• Project ramp-up checklist: käytäntöjä, jotka on keskusteltava ja dokumentoitava (documents, project-specific issues, meeting practices, tools, development, testing)

Cinian omien pelisääntöjen lisäksi asiakkaalta voi toki tulla reunaehtoja käytännön työskentelyyn, etenkin silloin, jos on kyse monitoimittajaprojektista ja scrum of scrums -metodologiasta tai työ tapahtuu turvatiloissa.

Lue lisää: “Rima saa olla korkealla” – Näin toimii ketterä kehittäminen Cinialla

3.   Koodin laatuun ja parhaisiin käytäntöihin sitoutuminen

“Me Cinialla haluamme, että koodi on laadukasta ja tasokasta. Se on meidän oma etumme. Kun koodi on yhtenäisesti tehtyä, kaikkien on helpompaa ymmärtää se ja kontribuoida olemassa olevaan koodipohjaan. Siksi panostamme laadun kehittämiseen sekä projekteissa että projektien ulkopuolella jatkuvasti”, Helin painottaa.

Esimerkiksi aiemmin mainitussa Java-ekosysteemissä parhaita käytäntöjä on monen tasoisia: 1) Javasta itsestään lähteviä, 2) maailmalla hyväksyttyjä sekä 3) Googlen tai muiden suurten organisaatioiden ohjaamia käytäntöjä. Miten Cinialla sitten käytännössä seurataan eri teknologioiden best practices -ohjeita ja niiden päivittymistä?

• Taskforcet toimivat jatkuvasti projektien ulkopuolella. Jokainen cinialainen voi valita itseään kiinnostavimman ryhmän (mm. backend, frontend, React ja vastaavat teknologiat, DevOps, CI/CD) toimipiste- ja tiimirajoista riippumatta. Taskforceissa vaihdetaan käytännön kokemuksia ja tehdään evaluaatiota organisaatiotason parhaiden käytäntöjen rakentamiseksi. Samalla tuotetaan Confluenceen materiaalia eteenpäin jalkautettavaksi.
• Tech-illat tarjoilevat kerran kuukaudessa ajankohtaisen tiedotuksen lisäksi katsauksen tiettyyn aiheeseen, kuten versionhallinnan workflow’hun, laadukkaiden kommenttien laatimiseen tai Clean code -periaatteisiin.
• Mattermostin eri kanavilla kerrotaan taskforce-työn tuloksista, ja jokainen voi tutustua materiaaleihin omaan tahtiinsa. Mattermostia kannustetaan käyttämään myös omien kokeiluiden ja niiden tulosten jakamiseen.
• Erillisillä kurssimoduuleilla voi opiskella yksittäisiä teknologioita, kuten tiettyä pilviteknologiaa. Näin voi ottaa haltuunsa esimerkiksi Azuren, jos AWS on jo tuttu.
• Seniori-junioriyhteistyö ja toisten tiimiläisten auttaminen varmistaa tiedon siirtymistä.

Mattermostin kaltaiset, sisäiset keskustelukanavat ovat CV-pankkia nopeampi keino silloin, kun ongelmien ratkomiseen tarvitsee viisaita päitä oman tiimin ulkopuolelta.

“Cinia on sen kokoinen organisaatio, että meillä voi hyvin kysyä apua kaikilta.” Lead Developer Joni Helin

4.   Versionhallinta

Ei riitä, että ohjelmakoodi itsessään on laadukasta. Miten sitä tuotetaan ja säilötään, millainen sen historia on? Millaisista inkrementeistä se koostuu? Kun projektin elinkaarivaihe alkaa olla tuotantopisteen takana eli se tuottaa jo lisäarvoa asiakkaalle, on laadukas historia erittäin tärkeä mahdollisten ongelmien selvittelyssä ja muutoksien impaktin analysoinnissa.

Cinialaiset käyttävät koodimassan ja workflown hallintaan GitLabia. Kukin projekti sopii parhaiden käytänteiden pohjalta muun muassa haaroituskäytännöistä ja kytkennöistä automatioistuun CI/CD-putkeen (continuous integration and continuous deployment). Käsillä olevaa hanketta voi verrata koestettuihin, toimiviin ratkaisuihin, poimia kirsikat kakusta ja hillota ne sopivaan muotoon. Millaisia repositoryja perustetaan mihinkin tarkoitukseen? Miten koodia ja komponentteja versioidaan? Kuinka siitä julkaistaan valmiita lopputuotoksia eri ympäristöihin?

5.   Infrastruktuuri

Ohjelmistoratkaisun vaatimusten mukaisesti työskentelyyn tarvitaan kehitys-, testaus-, staging-, tuotanto- ja koulutusympäristöjä, ja niitä varten taas joko rautaa tai pilvestä nostettua infrastruktuuria.

Projekti päättää ja sopii infrastruktuurista asiakkaan kanssa huomioiden sen, minne ohjelmistoratkaisun käyttöönotto kohdistuu: onko käytössä in-premises -konesali, hyödynnetäänkö privaatti-, julki- tai hybridipilveä tai käytetäänkö serverless-arkkitehtuuria. Käytäntöjen on oltava kaikille selkeät ja yhtenäiset.

“Tänä päivänä mahdollisuuksia on paljon”, Helin muistuttaa. “Siksi on tärkeää, että kerrytämme organisaationa kokemusta hyväksi havaituista toimintamalleista, emmekä tee samaa joka kerta atomeista asti uusiksi. Pyrimme minimoimaan manuaalisen työn, ja sen sijaan toteutamme infrastruktuuria monistettavina, skriptattuina tai muuten mekanisoituina ratkaisuina, oli teknologia mikä tahansa, esimerkiksi Terraform, AWS CDK tai CloudFormation.”

6.   Koodin katselmointi ja kommentointi

”Perinteinen koodin katselmointi on aivan ok, ja teemme sitä, mutta haluan korostaa jatkuvaa, ohjauksellista katselmointia sitä ennen”, Helin tähdentää. Nimettyjä reviewereitä, tarkistuslistoja ja testausautomaatiota ei siis unohdeta, mutta ne eivät riitä turvaverkoksi. Ei ole kenellekään mielekästä puurtaa viikkoa yksin ja todeta sitten, että työ on tehtävä alusta asti uudelleen.

Siksi uutta kehitystä ei tehdä pääkehityshaaraan, vaan se elää väliaikaisissa feature-haaroissa, kunnes riittävä kypsyystaso on saavutettu. Jokainen julkaisee omaa edistymistään jatkuvasti feature-haaraan, ja työ tulee heti näkyväksi muulle tiimille. Näin minimoidaan yhdessä harha-askelien määrä ja vaikutus.

Koodin kommentointi tähtää toimivaan kokonaisuuteen. Kun muodollisesti pätevät, mutta pitkällä tähtäimellä heikot ratkaisut huomataan ajoissa, projektille ei synny teknistä velkaa.

“Meitä ei kuormiteta sillä, ovatko koodin muotoilut oikeat. Sitä varten otetaan työkalut käyttöön jo projektin alussa. Ne muotoilevat, analysoivat ja poistavat mekaanisesti tunnistettavia heikkouksia. Näin katselmoinnissa ja kommentoinnissa pystytään keskittymään asioihin, joita vain ihminen voi huomata.”

Hyödyt ovat selkeät – valmiissa tellingeissä on helppoa toimia

Ohjelmistoratkaisuja ostava asiakas ilahtuu korkeasta laadusta, budjetissa pysymisestä ja siitä, ettei aikatauluihin tule odottamattomia muutoksia. Mutta mitä hyötyjä valmiit toimintamallit ja käytännöistä sopiminen tuovat itse projektityöhön? Lead Developer Joni Helin näkee edut selkeästi:

• Kehittäjän on helppoa toimia valmiissa puitteissa. Hänen ei tarvitse ylläpitää omaa ympäristöään ja rakentaa uutta aina alusta asti, vaan hän pääsee nopeasti tuottamaan lisäarvoa asiakkaalle.
• Kun versionhallinta toimii ja jokainen jättää jälkiä Confluenceen tai Jiraan, ja jokainen ymmärtää, mitä työkaveri tekee, tulokset ovat yhdenmukaisempia. Hiljaista tietoa on piilossa mahdollisimman vähän. Silloin myös liikkuminen projektien välillä on sujuvampaa.
• Ennakointi auttaa tekemään oikeita asioita mahdollisimman ongelmattomasti. Jokainen voi olla ylpeä työn jäljestään ja luottaa siihen, että softa toimii ensi viikolla – ja ensi vuonna.