Vuodesta 2010 alkaen olen työskennellyt enemmän tai vähemmän päätoimisesti Android-sovellusten parissa. Näiden vuosien aikana olen ehtinyt olla monessa mobiiliprojektissa mukana ja niin kirjoittaa kuin katselmoida tuhansia rivejä ohjelmakoodia.

Mitä vanhemmaksi ja kokeneemmaksi kehittäjäksi olen itse kehittynyt, sitä enemmän olen alkanut kiinnittää huomiota piirteisiin jotka löytyvät hyvästä lähdekoodista.

Käyn tässä kirjoituksessa läpi havaitsemiani asioita ja kerron miksi ne ovat tärkeitä tekijöitä lähdekoodin laadun kannalta. Vaikka esimerkkini tulevat pääosin Android-maailmasta, ovat taustalta löytyvät perusideat sen verran yleisiä että niitä voi soveltaa myös muille alustoille.

1. Kirjoita vähemmän koodia

Yksinkertaisin ja nopein tapa lähdekoodin laadun ja luettavuuden parantamiseen on koodin määrän vähentäminen. Mitä vähemmän koodia projektissa on, sitä helpompi ohjelman toiminta on ymmärtää ja sitä vähemmän siinä on virheitä.

Projektin koodimäärän vähentäminen on helpointa aloittaa usein toistuvista tehtävistä ja rakenteista. Tällaiset rakenteet tulisi toteuttaa joko niin geneerisesti että samalla koodilla voidaan toteuttaa kaikki tarvittavat tapaukset tai, jos mahdollista, käyttäen valmista kirjastoa.

Kirjaston käyttäminen ongelman ratkaisuun on helppo tapa vähentää oman koodin määrä ja parantaa laatua. Näin varsinkin tilanteessa jossa käytettävä kirjasto on noussut standardin asemaan. Tällaisen kirjaston hyvä puoli on siinä että se on usemmiten laadukkaampi ja testatumpi kuin itse tehty ratkaisu.

2. Kommentoi kirjoittamasi koodi

Helpoin tapa tehdä kirjoittamasta lähdekoodistasi helpommin ymmärrettävää on lisätä koodiin kommentteja. Kommenttien tarkoitus on selventää mitä koodi tekee ja miksi näin tehdään. Kokemusteni perusteella lähdekoodin kommentointia harjoitetaan kuitenkin kovin harvoin.

Yleinen argumentti koodin kommentointia vastaan on että kommentit eivät pysy ajantasalla, koska lähdekoodi elää ja muuttuu niin nopeasti. Näin ollen koodin kommentointi on turhaa työtä sillä kommentit ovat kuitenkin ennemmin tai myöhemmin vanhentuneita. Pidä tätä argumenttia koomisena siitä syystä, että kommentit pitäisi nähdä osana lähdekoodia, ei erillisenä osana jota ylläpidetään jos aikaa ja jaksamista löytyy.

Kommentoimattoman koodin keskeinen ongelma on siinä että uuden kehittäjän on vaikea ymmärtää kokonaiskuvaa sekä eri osioiden tarkoitusta ja tavoitteita. Toisaalta myös projektin kehityksen myöhemmissä vaiheissa on bugien korjaaminen vaikeampaa, jos kehittäjällä ei ole tietoa miksi koodi toimii näin ja toimiiko se alunperinkään oikein.

3. Tunne työkalusi ja käytä niitä oikein

Kuten alussa mainitsin, koodin määrän vähentäminen on yksinkertaisin tapa parantaa koodin laatua. Kuitenkin yhtä tärkeä laadun tae on ymmärtää ja tuntea käytössä olevat työkalut ja ohjelmointikielen luokkakirjastot.

Olen todistanut usean kokeneen kehittäjän, myös itseni, kompuroineen eri tietorakenteiden kanssa. List-, Set- ja Queue-luokille on omat paikkansa ja niiden käyttö riippuu ratkaistavasta ongelmasta. Esimerkiksi Javassa List-luokkaan on mahdollista tallentaa duplikaatteja, mutta Set-luokkaan ei. Valitsemalla oikean tietorakenteen pystyt keskittymään itse ongelman ratkaisuun ja jättämään turhan koodin, esimerkiksi duplikaattien poiston, pois.

Työkalujen tunteminen ja niiden oikeanlainen käyttö on ikävä kyllä pitkällinen prosessi. Tähän ei ole nopeaa ratkaisua, ainoa tapa kehittyä tällä saralla on yrittää aina oppia uutta lukemalla alan julkaisuja ja muiden kirjoittamaa koodia sekä tietenkin tekemällä töitä kokeneempien ihmisten kanssa.

4. Mieti sovelluksesi arkkitehtuuria

Aiemmista kohdista voi huomata, että sovelluskehityksessä annetaan paljon painoarvoa itse lähdekoodille. Kuitenkin vähintään yhtä tärkeä ominaisuus laadun takana on lähdekoodin ja toiminnallisuuksien jäsentelty eli ohjelman arkkitehtuuri.

Ohjelmiston rakentaminen hyvällä arkkitehtuurilla ei ole aivan yksinkertainen asia, koska hyvä arkkitehtuuri riippuu täysin työn alla olevasta ohjelmistosta. Se mikä toimii yhdessä projektissa, ei välttämättä toimi toisessa ollenkaan. On kuitenkin olemassa muutamia ohjenuoria joita noudattamalla voi olla varma että ohjelmistosta ei tule täyttä katastrofia arkkitehtuurimielessä.

Ensiksi ohjelmiston eri osat tulee jaotella järkeviin kokonaisuuksiin. Esimerkiksi käyttöliittymäkoodi, bisneslogiikka ja tiedon varastointi on kannattavaa erotella omiin osioihinsa. Näin ollen ohjelman eri osiot voivat tarjota rajapinnan ulospäin ja samalla piilottaa sisäiset tekniset ratkaisunsa. Kun tulevaisuudessa osioita mahdollisesti muutetaan, on muutokset rajattu osion sisäisiin luokkiin tai julkisiin rajapintoihin ja niitä käyttäviin luokkiin.

Toisesta näkökulmasta katsottuna, lähdekoodin jakaminen loogisiin osioihin auttaa myös uusien kehittäjien sopeutumista projektiin. Kun ohjelmakoodi on jaoteltu selkeästi omiin kokonaisuuksiinsa on eri osioiden sekä kokoinaisuuden toiminnallisuus helpompi hahmottaa. Näin ollen tiimiin liittyvän työntekijän on helpompi hypätä mukaan ja lähteä kehittämään ohjelmistoa eteenpäin.

5. Testaa virheiden varalta

Ohjelmistokehityksen tiimellyksessä syntyy aina bugeja. Välillä bugit ovat pieniä ulkoasuun liittyviä asioita ja välillä suurempia logiikkaan liittyviä virheitä. Bugit itsessään ovat inhimillisiä, ja niiden syntymistä tuskin koskaan pystytään täysin estämään.

Paras tapa virheiden määrän minimoimiseen on ohjelmiston testaus. Ohjelmistokehityksessä harmittavan usein testaus jätetään kuitenkin toissijaiseen rooliin ja siihen paneudutaan kunnolla vain jos aika ja resurssit antavat myöten. Näin ollen on yksi tapa vähentää helppoja virheitä kehitysvaiheessa on käyttää ohjelmakoodin analysointiin tarkoitettuja työkaluja.

Analysointityökalut käyvät ohjelmakoodia läpi analysoimalla sen rakenteita ja etsivät koodista tunnettuja virheitä. Työkalujen, kuten FindBugs ja Error Prone, ajaminen on suositeltavaa tasaisin väliajoin sillä ne löytävät virheitä ja riskialttiita kohtia myös paremmistakin projekteista.

Tämän lisäksi jokaisen mobiilikehittäjän pitäisi ajaa säännöllisesti oman alustansa Lint-työkalua projektiansa vasten. Lint vastaa pääosin edellä mainittuja analyysityökaluja toiminnalisuudeltaan, mutta sisältää kyseiselle alustalle kohdennetun virhelistan. Esimerkiksi Android-lint -työkalu osaa tutkia Androidille tyypillisiä virheitä niin käytettävyyden kuin tietoturvan saralta.

Jatkoa varten

Hyvän ohjelmakoodin kirjoittaminen on moniosainen prosessi. Sen hallitseminen ei ole erityisen vaikeaa, mutta vaatii aikaa ja tarkkuutta. Homman ideana on ymmärtää mitkä valinnat parantavat lähdekoodia ja mitkä teot huonontavat sitä. Tekemisen ja omien kokemusten kautta huomaa parhaiten asiat jotka toimivat ja osat jotka vaativat prosessissa parantamista. Matka paremmaksi ohjelmistokehittäjäksi vaatii kärsivällisyyttä ja tuhansia riviä koodia, sillä paremmaksi kehittäjäksi ei voi tulla kuin koodaamalla.