Teen uusien ohjelmointiasioiden opiskelussa usein jonkinlaista “dummy”-projektia. Eli olen tekevinäni esimerkiksi muistilistaa, tai vaikka – sanotaan – hmm… jotain karttasovellusta. Tällainen lähestymistapa helpottaa hahmottamaan jollain tapaa sitä, mitä tekee. Eli puoliksi huijaa itseään: ei kirjoittele vain koodirivejä ilmaan ja käsittele täysin abstrakteja merkkijonoja tai numeroita, tietueita jne.

Mietin paljon softaprojektin eri osa-alueita. Speksaus on edelleen tärkeä osa, mutta se on myös jotenkin ongelmallinen ja rajoittavakin osa. Speksi tarkoittaa ohjelmiston määritellydokumenttia: niin käytetyn sanaston, tavoitteiden, tavoiteltavien hyötyjen, ohjelmiston sovellusalueen piirteiden, sen käyttötapausten, ja monen muun asian kirjaamista ja pohdiskelua.

Speksi muodostuu keskustelualustaksi, kun ohjelmistoa viedään tiimissä eteenpäin. Se on ohjelmiston eräänlainen aineeton koekappale, joka ei vielä toimi oikeasti. Speksi ei ole siis prototyyppi (prototyyppi on toimiva ohjelma, vaikka se olisi kuinka rajoitettu tai alkeellinen – silti, toimiva).

Ihan oikea tarve: kotiin!

Teen paraikaa oikeaan tarpeeseen softaa: haluan kotikäyttöön ostoslistan. Kyllästyin paperilappuihin, koska niitä varten pitää aina jostain vetää se lappu ja kynä. Kynä lisäksi pitää myös muistaa viedä kauppaan, jos paperilappua haluaa aktiivisesti käyttää: tarvii yliviivata ne asiat jotka on jo ostanut. Paperilappu myös usein unohtuu väärään paikkaan, siis yllättävän usein! Ja koska arvostan esteettisyyttä, paperilappu rypistyy; muste lähtee kosteudessa leviämään, ja lyijykynästä taas lyijyjälki tahraa ja pehmenee joskus sellaiseksi että lapusta ei saa selvää.

Hei, yllä on melkein ilmaiseksi vedetty se “unelma” -kohta speksiin; tätä minä haluan! Keskustelin asiakkaan, itseni kanssa, ja mietin, miksi haluan sen digitaalisen ostoslistan.

Jalostetaan silti toiseltakin puolelta: mitkä ovat digitaalisen ostoslistan huonot puolet?

Miettimällä ongelmia voidaan saada jonkinlainen parempi muoto ja toteustapa ostoslistalle. No, huomasin tällaiset asiat:

• mitäs jos kännykkä jää kotiin? Eli huomaa menneensä kauppaan, ja sitten se tieto onkin “ei saatavilla”. Huulipurettaa.
• onko tiedon syöttö oikeasti niin nopeaa ja helppoa kuin ajattelisi? Känny on usein lukittuna (“screen lock”) tjsp, joten alkuunpääsy voi olla hidasta.
• eipä kynäkään ole tosiaan aina saatavilla, jollei järjestä kotona aina jonnekin tiettyyn paikkaan esimerkiksi keittiössä tällaista luxusta
• entäs tietoturva yms?
• onko ostoslista helppo myös unohtaa / hävittää. Tällaista tietoa ei luulisi tarvitsevan mihinkään tulevaisuudessa… Eli poisto helpoksi, ettei ala kertyä “digiroskaa” kännykkään.

Speksi on perinteisesti tarkoittanut aika paljon tietorakenteita ja ohjelmistossa olevan tiedon hierarkiaa ja linkittymistä toisiinsa. Siis englanniksi: Entity-Relationship model. ER-mallit ovat jo aika raskaita ja puisevia dokumentteja, mutta voivat sinänsä auttaa sekä ongelman hahmottamisessa, pilkkomisessa että koodin kehityksessä. ER -malleilla haetaan ehkä eniten standardimuotoista helpotusta ohjelman keskeisimpien rakenteiden (oikeastaan: algoritmien, datan määrän ja ennakoitujen pullonkaulojen) dokumentoinnissa. ER-malli on toisaalta hyvin staattinen, ja kuvaa vain rakennesuhteet: ei esimerkiksi miten asiat “proseduraalisesti” toimivat, eli miten mekanismit suhtautuvat toisiinsa ajonaikaisessa koodissa.

Tässä kohtaa on aika hyvä pysähtyä hetkeksi. Heitän seuraavat kysymykset mietittäväksi:

• paljonko käyttäisit aikaa ostoslista-ohjelman tietorakenteiden mallintamiseen?
• mitä ensimmäiseksi tulee mieleen ostoslistassa käytettävistä rakenteista? Ovatko ne yksinkertaisia, monimutkaisia, selkeitä, epäselviä?
• ajattelisitko jotain tiettyä laajennusmahdollisuutta, jos ostoslistan saisi tehtyä viikossa jo toimivaksi ohjelmaksi?