Kesän loppupuolella postiluukusta kolisi muiden TKK:n esitteiden seassa psykedeelisten kalojen siivittämä esite, jonka viesti oli jotakuinkin seuraava: “Javaa, kivaa, tänä syksynä.” Kivaa tai ei – ainakin täysin uutta. Saavuin Studio 1:lle vailla ohjelmointikokemusta, vaikka olenkin peuhannut koneiden kanssa jo esikouluikäisestä. Pascalia olin joskus kokeillut, sekä kirjoittanut joitain shelliskriptoja Linuxin bash-terminaalissa, mutta koodaus oli melko etäinen asia. Nyt, kun pohja valettu, on helppo jatkaa eteenpäin mikäli tarve vaatii.
Ennen kurssia luulin ohjelmoinnin suurimpien haasteiden olevan useiden kielten osaamisessa ja niiden laajuudessa. Osoittautuikin, että vajaan puolen vuoden javailun jälkeen pystyy saamaan enemmän tai vähemmän selkoa muidenkin ohjelmointikielten syntaksista, vaikkei välttämättä kyseisellä kielellä osaisikaan ohjelmoida. Suurin haaste ohjelmoinnissa onkin järkevän ohjelmointilogiikan opetteleminen. Sellaisen, että asiat
pyritään tekemään mahdollisimman yksinkertaisesti, mutta silti selkeästi. Niin, että muutkin saavat koodista selvää.
Hyvä ohjelmointitekniikka kehittyy yhä satojen ja satojen koodaustuntien tuloksena. Aivan kuten matematiikassakin: saman ongelman ratkaisemiseksi on tarjolla useita, jopa kymmeniä, ratkaisutapoja. Osa niistä on elegantteja ja tehokkaita – toiset kovin kömpelöitä tai vaikeaselkoisia. Järkevämmät ratkaisutavat säästävät resursseja, joka tietokonemaailmassa tarkoittaa sitä, että ongelman ratkaisemiseen tarvitaan vähemmän laskukapasiteettia. (Vrt. esim piin laskeminen Monte Carlo -menetelmällä ja monikulmiometodin käyttö)
Keskustelin muutamia vuosia sitten erään suomalaisen ohjelmoijan kanssa ja esitin pari toivetta, jotka olisin nähnyt mielelläni softan seuraavassa versiossa. Hän totesi, että nykyiseen versioon on vaikea koodata edellä mainittuja lisäominaisuuksia, mutta kertoi olevansa koodaamassa uusiksi softaa – kakkosversiota, johon kyseiset ominaisuudet olisivat tulossa. En käsittänyt, miksei vanhaa softaa voinut tai kannattanut enää laajentaa. Kunhan koodaisi vaan puuttuvan osan ja liittäisi sen kokoonpanoon?
Ei siis riitä, että ohjelmakoodi pelkästään toimii ja on selkokielistä. Sen tulisi olla myös helposti laajennettavaa. Kenties siten, että muutkin
pystyvät lisäämään ohjelmaan haluamiansa toiminallisuuksia. Ohjelmoinnissa, kuten muuallakin elämässä, hyvä pohjustus ja suunnittelu on puoli voittoa.
Aloittelevana koodarina tuli tehtyä monia “virheitä”. Koodiin tuli helposti overheadia – ajattelin asioita paljon monimutkaisemmin, kuin ne oikeastaan olivat. Seuraavana päivänä saattoi miettiä, mitä ihmettä oikein koodasi. Silti se toimi, vaikka neljä sisäkkäistä if-lausetta ei välttämättä ole järkevin tapa. Silmä kuitenkin kehittyi ja kurssin edetessä oppi uusia tapoja, millä koodista saa entistä esteettisempää.
Malliratkaisujen lukeminen auttoi runsaasti oman ohjelmointityökalupakin laajentamisessa. Vanhojen menetelmien tilalle tuli uusia ja tehokkaampia keinoja.
Ennen kurssia en myöskään uskonut, että hyvän ohjelmakoodin tekeminen vaatii niinkin draamattista määrää testausta. Metodin ei tarvinnut olla edes kovin monimutkainen ja silti sillä sai NullPointerExceptionin aikaan ainakin viidellä eri tavalla. Kun pelkästään tällä kurssilla tehdyt ohjelmat vaativat useiden tuntien eksplisiittistä testausta, en enää ihmettele, miksi Ubuntunikin kyykkää joskus!
Kaikki kunnia niille jotka ammatikseen koodaavat, sillä itse joudun sanomaan: “Ei kiitos.”
