Priima vs. sekunda

Vaikka taideteoksen laatua ei voi objektiivisesti määrittää, Shakespearen näytelmän ja keskimääräisen televisiosarjan käsikirjoituksen kirjallisten ansioiden vertailu on helppoa lähes kenelle tahansa. Sen sijaan kieltä osaamattomalle esimerkiksi huonon animesarjan ja Kurosawan mestariteoksen käsikirjoitusten vertailu on mahdotonta. Vastaavasti ohjelmakoodin laadun - ja siten sen tekijöiden ammattitaidon - toteaminen ei onnistu maallikolta. Pieni satsaus kolmannen osapuolen suorittamaan koodin laadun katselmointiin (auditointiin) jo projektin alkuvaiheessa kannattaa, jos omasta organisaatiosta ei löydy tarvittavaa osaamista.

Pasi Kovanen

Pasi Kovanen
Software with Passion.

3 kommenttia

pasi sanoo:

Kiitos hyvistä kommenteista! Tässä lisää näkemyksiäni aiheesta.

Ohjelmoijien tulee muistaa, että useimmiten asiakas omistaa automaattisesti jokaisen koodirivin, joka versiohallintaan viedään. Asiakkaalla on näin ollen oikeus ja mahdollisuus tutustua koska vaan siihen, millaista vastinetta rahoilleen saa.

Asiakkaan tuskin protoiluvaiheessa kannattaa vielä koodin laatua alkaa tarkkailla, koska protoilun kesto on murto-osa projektin kokonaiskestosta ja pelkästään onnistunut protoilu lisää jo luottamusta. Lisäksi protoilukoodia ei saa päätyä valmiiseen tuotteeseen.

Koodin laadun merkitys kasvaa huomattavasti ajan kuluessa. Monet tietojärjestelmät joudutaan uusimaan 5-10 vuoden välein hyödyntämään vaihtuneita teknologioita. Tällaisissa uudistusprojekteissa olleilla on usein kokemuksia siitä, mitä heikkolaatuinen koodi aiheuttaa. Monasti vanhan järjestelmän ainoa kuvaus on lähdekoodi, joka on erittäin vaikealukuista – esimerkiksi pitkiä funktioita tai metodeja joiden merkitys jää epäselväksi, surkeasti nimittyjä muuttujia ja muita tyypillisiä ongelmia. Viimeistään tässä vaiheessa huonolaatuinen koodi tulee maksamaan paljon.

Kokenut ohjelmoija pystyy jo tunnissa-parissa antamaan hyvän arvion koodin laadusta joten projektin kokonaiskustannuksissa tämä ei tunnu mitenkään.

Kirjan “Clean Code: A Handbook of Agile Software Craftsmanship” ensimmäinen kappale antaa lisää perusteluja miksi huono koodi tulee kalliiksi.

Koodin Orja sanoo:

Mitäs koodia projektin alkuvaiheessa on katselmoitavaksi? Jotain ensimmäisiä protoiluja? Onkohan niistä varmuudella vedettävissä minkäänlaisia johtopäätöksiä?

Yleensäkin omasta mielestäni ne ongelmat projekteissa harvemmin koodin laatuun fokusoituvat, ennemminkin analyysi/suunnitteluvaiheen virheisiin. Toki jotain epäilyksiä voi olla aiheen herätellä, mikäli koodipuoli tyystin holtittomalta vaikuttaa…

Jukka Aakula sanoo:

Kieltämättä hyvä ajatus.

Lopultahan kuitenkin on kyse luottamuksen kasvattamisesta. Ei firman joka ostaa räätälöidyn koodin tarvitse siitä mitään ymmärtää paitsi laatu.

Liity keskusteluun