Miksi muiden koodi on paskaa?

Devaajien on joskus vaikeaa ottaa koppi toisten aloittamasta projektista, koska muiden kirjoittama koodi tekee pahaa. Outoa, miksi? En ole koodari, mutta voin vilkaista.

Projekteja toteutetaan usein tiukalla aikataululla, jolloin koodin hiomiseen ja kaunisteluun ei ole aikaa. Tällöin priorisoidaan ja tehdään tietoisiakin oikaisuja, jotta tuote saadaan oikeaan aikaan ja toimivana ulos.

Eikä siinä vielä kaikki.

Julkaisun jälkeen saattaa käydä ilmi, ettei tuote toimi toivotulla tavalla ja se vaatii monilta osin perustavanlaatuista uudistusta. Kun mukaan astuu lennossa tehtyjen suunanmuutosten jälkeen uusi devaaja, näyttää vanha koodi hänelle helposti epäloogiselta härveliltä – etenkin jos kommentointi on tehty huolimattomasti.

Joskus sen sijaan koodissa ei itsessään ole edes kummempaa vikaa, kunhan vain ärsyttää lukea sitä. Tätä toisten koodiin kohdistuvaa negatiivista tunnereaktiota voi selittää joillain käytännön jutuilla ja kognitiivisilla harhoilla.

Lukeminen on vaikeampaa kuin kirjoittaminen

Koodia kirjoittaessa on itse kärryillä siitä, mihin pyrkii ja miten aikoo tavoitteeseen päästä. Joskus tulee otettua vähän kiertoteitä tai kyhättyä matkan varrella pari purkkaviritelmää, mutta kirjoitusvaiheessa logiikka toimii, ainakin omasta mielestä. Kun joku muu alkaa ottaa selvää koodista, asetelma on erilainen. Abstruse Goose on tehnyt tästä suositun sarjakuvan.

Ikäviä tunteita ei synny vain silloin, kun lukee toisen kirjoittamaa koodia. Omakin vanha tuotos voi näyttää kamalalta, jos ei enää muista, miksi on päätynyt tiettyihin valintoihin. Yksi luku, jonka avulla arvioida koodin laatua, on WTFs/minute eli montako “mitävittua” lukijalta pääsee minuutissa.

“Koodin kirjoittaminen on ylätasolla kommunikointia. Tärkeintä on kertoa, mikä koodipätkän tarkoitus on ja miksi se on siinä. Kun nämä ilmaistaan selkeästi kommenteissa, lukeminen helpottuu eikä ärsytä niin helposti”, sanoo Qvikin Software Architect Kaarlo Lahtela.

Sitten kolme kognitiivista harhaa, joilla on monesti osuutta asiaan.

1. Ikea-efekti

Ihmiset antavat enemmän arvoa tuotteille, joiden rakentamiseen he ovat itse osallistuneet – riippumatta siitä, miten tuotteen rakennus on sujunut. Sama juttu koodissa: itse kirjoitettua koodia on helpompi arvostaa kuin toisen.

“On apua, jos joutuu itse esittämään omaa koodiaan välillä toisille devaajille. Kun uudella devaajalla ei ole samaa hiljaista tietoa projektin historiasta, huomaa usein joutuvansa sanomaan milloin mistäkin koodinpätkästä että ‘kas, tämä ei ole nyt ihan parasta, mutta tuollaisena se on toiminut ja on ollut tärkeämpää tekemistä’”, sanoo Qvikin Principal Software Engineer Pertti Kröger.

“Tästä olen ainakin itse saanut perspektiiviä siihen, että muidenkin koodi näyttää samalla tavalla paskalta samoista syistä. Olennaista on luottaa, että muutkin ovat päteviä ammattilaisia ja että jokin syy aina on.”

2. Tuttuusvaikutus (Mere-exposure effect)

Pidämme asioista, jotka ovat meille tuttuja. Tutkimuksissa tämän on todistettu pätevän vaikka mihin: sanoihin, ääniin, kuviin, hahmoihin, kasvoihin, ruokiin, brändeihin.

Koodia lukiessa toisen logiikka voi tuntua vieraalta, jolloin siitä on vaikeampi pitää. Oma koodi ja oma logiikka ovat sen sijaan tutuimpia ja siksi niistä on helpompi pitää.

Teknologiafirmoilla on yleensä omat, hieman toisistaan poikkeavat ohjeistukset, joiden pohjalta eri koodikieliä kirjoitetaan. Tämä johtaa siihen, että kun on tottunut oman firman tuottamaan koodiin, se voi näyttää paremmalta kuin toisen firman. Esimerkiksi Qvikin Swift-tyyliopas näyttää tältä.

“Devaajan on helppo ymmärtää ja kirjoittaa koodia tutulla arkkitehtuurilla, tyylillä sekä kirjastojen kanssa. Tätä voi helpottaa formatoimalla koodi automaattisesti tuttuun tyyliin esim. Prettier-työkalun avulla”, sanoo Qvikin Head of Front-End Development Jani Mikkonen.

3. Perusarviointivirhe (Fundamental attribution error)

Ihmisille on tyypillistä arvioida toisten tekemisiä eri kriteereillä kuin omia tekoja. Omissa toimissa ulkoisten tekijöiden merkitystä korostetaan etenkin, jos kaikki ei ole mennyt täysin suunnitellusti. Toisten tekemisiä ei sen sijaan ole yhtä luontevaa lähteä selittelemään ulkoisilla tekijöillä.

Vähänkin vanhempaa koodia lukiessa on esimerkiksi hyvä muistaa, että ohjelmointikielet kehittyvät ja parhaat käytännöt muuttuvat.

“Toisinaan hetki sitten ohjelmointialustan parhaita käytäntöjä noudattanut koodi voi olla vanhentunut, jos alusta tai käytetty kirjasto on muuttunut”, sanoo Qvikin Senior Software Engineer Jussi Pekonen.

“Tämä voi aiheuttaa turhautumista, jos alustan kehityshistoria ei ole toisen koodia lukevalle tuttu. Samoin aivan uusin ratkaisutapa voi vaikuttaa pöhköltä sellaisen silmissä, joka ei ole itse kyseiseen tapaan ehtinyt tutustua.”

Virheist oppii ja kokemust karttuu

Kaikki ohjelmoijat eivät tietenkään vihaa muiden koodin lukemista. Etenkin uran alkuvaiheessa kokeneempien tekijöiden koodi voi tarjota lukijalle tärkeitä oppeja ja oivalluksia.

“Koodilukutaito on osa ammattitaitoa. Muiden virheistä oppimalla voi lopulta kehittää myös omaa koodia ja sen luettavuutta”, Kröger sanoo.

Vihantunteet eivät välttämättä myöskään kohdistu koodia kirjoittaneeseen henkilöön, vaan kyseessä on pikemminkin teknologiaraivoa muistuttava tunne.

“Toisten koodin lukeminen ja arviointi helpottuu, kun tunnistaa tämän ilmiön ja sen syyt.”

Kuvitus: Aija Malmioja