Tutustuminen itselle uuteen järjestelmään etenee pieni pala kerrallaan - pitää jaksaa sietää sitä, että kokonaiskäsityksen saamiseen menee aikaa
Anttiolli Aho tuli viime keväänä mukaan uuteen projektihankkeeseen. Käsillä oli asiakkaan jo olemassaoleva sovellus, jonka ylläpito ja jatkokehitys tuli ottaa haltuun. Tuosta alkoi vähittäinen tutustuminen ohjelmistokokonaisuuteen, joka palvelee henkilöstövuokrausyrityksen toiminnanohjausjärjestelmänä usean tuhannen ihmisen työyhteisöä.
– Asiakkaalta lähti vanha järjestelmä alta, ja nyt oli ensimmäinen tavoite saavuttaa se toiminnallisuuden taso, joka oli mahdollinen vanhalla systeemillä. Asiakas haluaa teettää myös uusia ominaisuuksia, mikä tuo tekemisen kokonaisuuteen omat paineensa.
Anttiolli on fullstack-devaaja, jolla on kokemusta käyttöliittymistä, tietokannoista ja palvelinpuolen toteutuksista. Tältä pohjalta oli nyt edessä ennalta tuntemattoman järjestelmän opettelu.
– Olen ollut aiemminkin vastaavissa tilanteissa. On ollut myös projekteja, joissa olen ollut mukana alusta lähtien, ja tämä olisi kaikkein mieluisin tilanne. Koodarina haaveilen siitä, että saan aloittaa hankkeen aivan nollapisteestä, jolloin pääsen vaikuttamaan esimerkiksi työkaluihin ja toteutuskonsepteihin.
Oleellista on ymmärtää, mitä käsillä olevalla sovelluksella halutaan tehdä, ja mitä sillä voi tehdä tällä hetkellä. Toisaalta pitää ymmärtää, miten tämä tilanne on saavutettu teknisesti, ja mitä jatkossa halutaan saavuttaa.
Koodi on lähtötilanteessa musta laatikko. Kun kyseessä on agile-periaatteella kehitetty sovellus, prosessissa ei ole välttämättä syntynyt juuri mitään dokumentaatiota. Teknisestä puolesta oli karkean tason arkkitehtuurikuvia, ja demoamalla saatiin tietää, miten järjestelmää käytetään.
Kun uusi asiantuntija tulee mukaan käynnissä olevaan projektiin, perehtyminen lähtee siitä, että hän osallistuu projektitiimin päivittäiseen työhön. Hän saa scrum-taululta tehtävätiketin, bugitiketin tai yksinkertaisen ominaisuuden työstettäväksi. Tätä kautta hän pääsee kaivelemaan koodia joltain kulmalta.
– Itse aloitin käyttöliittymään tehtävällä lisäyksellä. Katsoin koodista, missä kohdin asia on ja mitä se on syönyt. Siitä se lähtee, ison valkoisen alueen täyttäminen pikkuhiljaa. Ymmärsin, miten käyttöliittymä on rakennettu ja miten kamat jaoteltu koodissa. Näin backendiin vieviä kutsuja, ja kun backend palautti hassuja arvoja, kurkistin jo serverinkin koodia.
Kerralla ei tule mitään massiivista ymmärrystä koodista, mutta ideana on purkaa iso laatikko pieniin osasiin ylhäältä alaspäin. Itse opiskellen löytyy tietous aina siitä osuudesta, mikä on kulloinkin tarpeellista. Samalla kehittyy käsitys erilaisista softan sisäisistä riippuvuuksista.
Teknologiamielessä vastaan tulee uusia kirjastoja ja frameworkkeja, jolloin pitää välillä opiskella ja ottaa selvää näistä konsepteista. Työ on välillä paljolti nettihakujen tekoa ja ohjelmakirjastojen omien kotisivujen läpikäyntiä.
– Jos käsissä on mutkallisempi tapaus, voi olla tarpeen käyttää muutama vartti youtube-videoiden katseluun, bussimatkalla tai illalla kotona. Tämä on hiukan viihteellisempi mutta joskus myös tehokkaampi tapa opiskella.
– Kun olen saanut yhden tiketin valmiiksi, seuraava on jo sprintissä odottamassa. Näin vähitellen edeten sovellus alkaa olla jo jossain vaiheessa ainakin semi-tuttu.
Anttiolli totesi viime vuonna kesälomien jälkeen, että kevät tuli tehtyä melkein pelkästään käyttöliittymätöitä. Loma-aikaan hän oli paikalla ainoa ohjelmistokehittäjä, ja palvelinpäähän ilmaantui ongelmia.
– Siinä huomasin, että jo alkuun olisi ollut hyvä tehdä enemmän läpileikkaavaa perehtymistä koko sovellukseen. Kun itselle uusille osa-alueille tulee kiirekorjauksia, niiden selvittäminen voi viedä aikaa. Kokeneempi tietää virheviestin pohjalta heti, mistä ongelma todennäköisesti löytyy. Jos tämä tuntuma vielä puuttuu, vian rajaamiseen menee aikaa ja kokista.
Hyvä esimerkki tästä oli loma-aikana ilmoitettu vika, joka osoittautui lopulta käyttäjälähtöiseksi ongelmaksi.
– En tuntenut palvelimen logiikkaa siltä osin, missä järjestyksessä se prosessoi dataa. Softakaan ei ollut niin hyvin koodattu, että se olisi estänyt käyttäjää toimimasta väärin. Jouduin opiskelemaan järjestelmää hyvän tovin ennen kuin saatoin osoittaa sormella käyttäjää ja todeta, että tässä kohdin tuotteessa ei ollut vikaa.
Pitkä kokemus alalta auttaa arvaamaan ongelmaselvityksissä jonkin verran, vaikka ei olisi koodia lukenutkaan. Usein löytyy jokin aavistus, mistä homma voisi olla kiinni. Silti tietotekniikka onnistuu usein yllättämään, ja kovasti välillä ihmetellään, miten kummassa tämäkin on mahdollista.
Devaustyössä näkyy usein se, että kaikki mitä tehdään, on pian tuotantokäytössä. Jos hankkeessa on nuoria tekijöitä, koodissa voi olla samantapaisia asioita monella eri tavalla tehtyinä.
– Uusilla kavereilla olisi hyvä olla joku kokeneempi katsomassa perään, miten asiat kannattaa tehdä. Pientä kuria kannattaa pitää yllä, ajatuksella että ”tuokin toimii, mutta jos teet näin, niin koodista tulee paremmin ylläpidettävää”.
– Aina pitäisi olla vähintään taisteluparin verran tekijöitä hommassa kiinni, ja samanaikaisesti. Yhdessä tehden syntyy yhteinen kulttuuri ja arkkitehtuuri. Jos tekijä koodaa kammiossaan yksin, hän voi mennä useinkin siitä missä aita on matalin. Tämä tuottaa tulevaisuuteen teknistä velkaa ja päivitysvelkaa. Kun tehdään juttuja helpolla tavalla, uusien asioiden tekeminen todellisuudessa hidastuu.
Dokumentaatiota ei pakosti tarvita, jos asiat käyvät koodista ilmi tarpeeksi selkeästi. Koodin pitää olla hyvin jäsenneltyä ja rakennettua, ja tämä myös ohjaa tekemään koodia oikealla tavalla. Kurinalaisuus auttaa ymmärtämisessä, ja se nostaa tuottavuutta heti alusta lähtien.
Devaajan pitää pystyä sietämään sitä, että hän ymmärtää ensin vain pieniä osia, ja näkymä laajenee vähitellen. Anttiolli on oppinut, että kaikkea ei voi hahmottaa heti. Kokonaisuus on pilkottava tarkoituksenmukaisiksi palikoiksi, joihin voi tarpeen mukaan syventyä pidemmälle. Kun tätä toistaa tarpeeksi, kohdesovellus ei olekaan enää valkoinen tyhjä arkki.
– Itselläni työn alla olevassa järjestelmässä on edelleenkin paljon tiedostoja ja paikkoja, joita en ole käynyt lukemassa.
Alkuun ymmärtää sen, että ei ymmärrä vielä paljoa käsillä olevasta kokonaisuudesta. Iloa löytyy siitä, että otan pienen palan haltuun ja ymmärrän sen toiminnan. Tämä antaa motivaatiota opiskella taas lisää.
– Joskus ongelmaselvittely voi olla kovin vähän motivoivaa ja stressaavaakin, kun homma vaatii paljon perehtymistä ja kiire painaa päälle.
Anttiolli tietää, että ei ole olemassa sellaista silverbullettia, jolla kaikki tuskat katoaisivat hetkessä. Ongelmaselvittelyä voi edesauttaa pienillä arkipäivän asioilla.
– Kun suunnittelija tuijottaa koodiriviä ja ihmettelee, mitä tässä tapahtuu, ääneen ajattelu ja debugin käyttö ovat usein avuksi. Välillä on otettava aikalisä ja katsottava vähän etäämpää, mitä ongelmakohdassa todella tapahtuu.
– Siinä on hyvä miettiä, mitä ymmärrän ja mitä en. Mitkä asioista, joita en ymmärrä, vaativat välitöntä reagointia ja mihin voi palata myöhemmin? Mikä on blokkeri juuri tälle hommalle?
Laajan softakokonaisuuden äärellä on tarpeen priorisoida omaksuttavia uusia asioita. Jos on kiire, suunnittelija tutkii vain ne kohdat, jotka pitää saada toimimaan.
– Kaiken muun kanssa on hyväksyttävä, että en ymmärrä mitä niiltä osin tapahtuu. Mutta tämä ei haittaa. On vain tärkeää tunnistaa asiat, joita ei ole tarpeen ymmärtää juuri tässä hetkessä.
Refaktoroinnista
Kun muokattavana on tarpeeksi monimutkainen systeemi, tulee helposti mieleen, että sellaisen haluaisi kirjoittaa uudelleen. On kuitenkin niin, että pieniä juttuja voi kirjoittaa uudelleen melko riskittömästi. Jos jotain isompaa kokonaisuutta yrittää tehdä uusiksi, tekijä saa harvoin saa aikaan oikeasti jotain parempaa. Riskinä on se, että tuotokseen tulee paljon uusia bugeja.
– Joskun voi tuntua siltä, että softassa pitäisi muuttaa monta asiaa. Tällöin on usein hyvä vain istua käsien päällä ja antaa isompien remonttien olla. Näin suunnittelija voi välttyä räjäyttämästä jotain ihan tyystin hajalle.
Jos saatavilla on pitkään projektissa olleita ihmisiä, heiltä voi aina kysyä, miksi jokin asia on tehty juuri tietyllä tavalla. Näin ei tarvitse alkaa turhaan arpomaan. Jos tekijä on vain jokin nimimerkki versiohistoriassa, ei tiedetä onko jokin toteutuksen kyseenalainen kohta tehty tietoisesti vai vahingossa. Ehkä tekijä on vain ollut tyytyväinen siihen, että koodi kääntyy.
Selkeässä koodissa asiat on selkeästi nimetty ja jäsennelty. Koodista on mahdollista tunnistaa rakenteita, joiden mukaan asioita on tehty.
– Itse en pidä rivimäärän minimointia tärkeänä. Oleellista on, että koodista tulee riittävän selkeää.
Full stack devaajana parasta on se, että näkee kokonaisuuden päästä päähän. Vastaan ei tule tikettejä, joihin ei voisi koskea.
– Olen tykännyt niin käyttöliittymäpään tekemisestä ja suunnittelusta kuin backendin matalan tason koodinnysväämisestäkin. Nämä voivat olla joskus toisistaan todella etäisiä alueita. Tällainen moninaisuus pitää tehtäväkentän kiinnostavana.
– Jos olisin keskittynyt vaikka pelkästään tietokantapuolelle, tietyntyyppiset ongelmat ratkeaisivat helpommin. End to end -ulottuvuus on kuitenkin itselleni luontevampaa, koska olen toiminut asiakasrasjapinnassa ja product owner -hommissa. On hienoa hanskata kokonaisuus päästä päähän, huolehtia siitä, että koko ketju on kunnossa.
Teknologiavalinnoista
Teknologian valinnat eivät ole yksinkertaisia juttuja. Lopputuloksena voi olla monenlaisia kombinaatioita ja kompleksisiakin toteutuksia, ja matkan varrella moni ratkaisu voi osoittautua virheelliseksi. Siinä mielessä, vaikka kuinka suunnittelija olisi itse päässyt speksaamaan kaikki jutut, kokonaisuus voi olla parin vuoden päästä samassa tilanteessa kuin jos käsissä on alun perin muiden speksaama ja toteuttama systeemi.
Web- ja javascript-maailmassa tulee hirveällä tahdilla uutta frameworkkia ja vanhat kuolevat pois. Oleellista on tehdä ero muodinmukaisten työkalujen ja tekniikoiden ja kypsempien ja hyväksi koettujen ratkaisujen välillä. Valinnat eivät ole helppoja.
Onko mahdolista valita väärin?
Jos käsillä on iso kokonaisuus, ja tekijöinä on kokematonta porukkaa, kiusaus mennä viimeisen muodin mukaan voi olla suuri. Tämä voi johtaa ongelmiin, vaikkapa kun valitaan ohjelmointikieliä, jotka eivät ole kovin tuttuja eivätkä tunnettuja.
Annos konservatiivisuutta tässä kohdin voi tuottaa pitkäjänteisempiä ja paremmin aikaa kestäviä valintoja.
– En ole ollut itse tilanteissa, joissa käsiteltävä järjestelmä olisi täysi katastrofi.
Teknologioiden ja toteutusratkaisujen vaihtaminen on usein mahdollista. Tästä kuitenkin syntyy harvoin asiakkaalle suoraa lisäarvoa, josta tämä olisi halukas maksamaan. Asiakas katsoo enemmänkin uusien tuottavien ominaisuuksien perään.
Teknologian vaihtamisessa on aina se riski, että jotain hajoaa. Hyvä testiautomaatio voi taklata tällaisia ongelmia, mutta järjestelmä junnaa ominaisuuksien kehityksen osalta paikallaan.
Kun juna on lähtenyt liikkeelle, tehtyjen valintojen kanssa pitää vain elää. Jos ilmenee jotain todella rampauttavaa, on tehtävä muutoksia. Tässä kohdin tarvitaan valpasta tuotekehityksen ohjausta, mikä ei ole välttämättä joka yrityksessä kovin korkealla prioriteetilla.
Uudessa projektissa Anttiolli käyttäisi esimerkiksi backend typescriptiä ja react käyttöliittymäframeworkia. Typescript on javascriptin päälle rakennettu kieli, jossa on tietotyypit mukana. Osaava suunnittelija pystyy tekemään sen avulla robustimpaa koodia kuin monella muulla kielellä.
-----------------------
Blogi on tehty Anttiolli Ahoa haastattelemalla
