Miksi C:llä on kivempi koodata



Viime aikoina on tullut työstettyä kahtakin projektia, joissa edes jokin osa kehitystyöstä on C:llä kirjoitetun komponentin muokkaamista. Ei ehkä aivan sattumalta molemmissa tapauksissa päädyin olemaan se kehittäjä, joka tämän tehtävän saa. Vaikka projektien substanssit olivat kovin erilaiset, molemmissa tapauksissa silmään oikein erityisesti pisti, että C:llä on oikeastaan kivempaa koodata kuin esimerkiksi Javalla tai Pythonilla. Jäin välittömästi miettimään mistä ihmeestä tämä voi johtua.

Yleisestihän on hyväksytty, enkä sitä aio kiistää, että nykyaikoina käytettävistä ohjelmointikielistä C on ehkä se fossiilisin jäänne, ja sillä minkään substantiaalisen toiminnallisuuden aikaansaaminen on kaikkein hitainta. Kaiken mahdollisen joutuu tekemään itse. Vaikkei tekisikään kaikkea itse, vaan käyttää jotakin kirjastoa sen tekemiseen (ja nykyään on hyvälaatuisia C-kirjastoja asioiden tekemiseen, verrattuna tilanteeseen esim. 20 vuotta sitten), pelkästään niiden kirjastojen käyttäminen on C:ssä tavattoman verböösiä. Erityisesti poikkeusten puute johtaa tuotantolaatuisen C-koodin tilaan, jossa puolet koodista on virheenkäsittelyä varten. Tämä aiheuttaakin jo kerrannaisvaikutuksen, kun pöhöttynyt ohjelmakoodi on jo hitaampi lukeakin, eikä pelkästään kirjoittaa. Lukeminen voi olla nopeampaa kuin kirjoittaminen, mutta sitä tehdään koodille niin monta kertaa enemmän, että itse asiassa lukemisen vaiva usein dominoi huonojen käytäntöjen aiheuttaman sakon suuruutta, ei niinkään kirjoittamisen.

Ohjelmoijan hyvä olo taas syntyy siitä flow-tilasta, johon ohjelmoija pääsee saadessaan jotakin aikaan.

Miten siis C:llä on kivaa koodata, vaikka noin suhteellisesti ottaen ei saa kovinkaan paljon aikaan? Onko perimätiedossa vikaa?

Tavallaan on, ja tavallaan ei ole. Virhe yllä oli väittämässä, että pitäisi olla aikaansaannoksia päästäkseen flow’hun. Luulen, että kirjoitusintensiivisillä välineillä flow syntyykin pelkästään kirjoittamisen määrästä. C:llä käy niin, että käyttääkin tavanomaista suuremman osan ajastaan kirjoittamiseen yksinomaan siksi, kun kirjoittamista on niin paljon. Tämä väistämättä vähentää sitä osuutta, jossa tuijotetaan tyhmänä tyhjää ruutua ja ihmetellään.

Tyhmänä tuijottamisen määrä per aikaansaatu toiminnallisuus ei toki vähene mihinkään. Se saattaa jopa lisääntyä. Mutta tyhjänä tuijottamisen määrä per aika vähenee kyllä.

Pahinta tässä ilmiössä on se, että yhdistettynä ihmisten taipumukseen hyperboliseen diskonttaukseen moni saattaa ruveta suosimaan C:tä toteutuskielenä lyhyen tähtäimen palkintojen takia. Tämä on eduksi minulle tässä ja nyt, mutta huomista itseäni kohtaan ei kovin kohteliasta — puhumattakaan siitä kuinka epäkohtelias tällainen valinta on tiimin muita jäseniä kohtaan. Ohjelmistotuotanto nyt harvemmin on yksinäistä puurtamista. Itse asiassa kaikenlaisten tuottavuus- ja muiden hyvyysmetriikoiden soveltaminen ohjelmistotuotannossa yksilöön on vähintäänkin kyseenalaista, ja mahdollisesti vahingollista puuhaa.

Pohditaan ideaalista scrum-tiimin kokoa, seitsemää henkilöä. Oletetaan, että tiimissä on fiksu ja taitava ohjelmoija, joka ulosmittaa oman tuottavuutensa täysillä cowboy-koodaamalla. Toimintatapa aiheuttaa ajoittain harmia muille jäsenille koodin spontaanisen rikkoutumisen muodossa. Ei kovin usein, ehkä kerran viikossa jokainen tiimin jäsen ihmettelee, miksi koodin invariantit eivät säily. Selvittelyyn menee pari tuntia kultakin ja ongelma saadaan korjattua. Jos aiheuttajan tuottavuus on huonojen käytäntöjen ansiosta kaksi kertaa suurempi kuin muiden, ollaan vielä saamapuolella.

Varsinaiset ongelmat alkavat vasta siinä kohdassa, kun tiimin muutkin jäsenet rupeavat miettimään, että mitä tässä oikein mitataan. Jos professionalismi ei ole sillä tasolla, että estää huonoihin käytäntöihin vajoamisen metriikoilla pelaamisen vuoksi (erityisesti jos tuottavuusmetriikoita käytetään bonusperusteena), kuukauden päästä toinenkin jäsen päättää optimoida oman tuottavuutensa ja uhrata tiimin tuottavuuden. Lopulta käy niin, että kaikki aika tiimissä käytetään sen kanssa painimiseen, ettei vedetä samaan suuntaan.

C ohjelmointikielenä vaatii tavallista suurempaa professionalismia välttääkseen poteroitumisen. C:tä ei kielen minimalistisuuden vuoksi tyypillisesti käytetä sellaisenaan, vaan sen päällä on jos jonkinlaista kirjastoa ja kehystä sellaistenkin asioiden tekemiseen, jotka muut kielet hoitavat oletusarvoisesti. Se, että nämä eivät ole kielen standardiominaisuuksia helposti vähentää niiden tunnettuutta kehittäjien keskuudessa. Niinpä riski siitä, että matalan tason kielellä tehty koodi sisältää käytäntöjä, jotka eivät ole yleisesti ymmärrettyjä, on suurempi kuin korkean tason kielessä.

Hyvillä tiimikäytännöillä näitä riskejä voidaan toki minimoida. Tämän jutun aikana on jo varmaankin käynyt selväksi, että pidän tärkeänä tiimin jäsenten merkityksen alaspelaamista ja tiimin identiteetin nostamista. Kun koodin omistajuus on tiimillä eikä jäsenellä, voidaan pitää kiinni siitä, että myös huonommin standardoidut kehitysympäristöt standardoidaan edes tiimin sisällä. Menetelmien ei tarvitse olla formaaleja jos, ja vain jos, tiimi kokee tavoitteet yhteisiksi ja ylipäänsä on olemassa tiimin identiteetti. Seitsemän soolokoodaria samassa huoneessa ei ole tiimi, vaan katastrofi täydessä vauhdissa.

Yhä laajempien kokonaisuuksien de facto standardointi (kts. Javan ja Pythonin standardikirjastot) ja ohjelmistoprojektien suurenemisen myötä tapahtunut kehitystiimien koon kasvaminen eivät ole ole missään tapauksessa toisistaan riippumattomia tapahtumia, jotka vain ovat sattuneet tapahtumaan yhtaikaa. Modernit välineet sekä mahdollistavat että edellyttävät moderneja käytäntöjä. C:llä koodaaminen saattaa olla hauskaa, mutta se on eri asia kuin että se olisi fiksua.

Tämän artikkelin on kirjoittanut Teemu Kalvas ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Yksi kommentti artikkeliin ”Miksi C:llä on kivempi koodata

  1. Minusta C:llä on toinenkin puoli joka tekee sillä koodaamisesta hauskaa: Minimalismin ansiosta se on mahdollista osata kokonaan. Kun koodarille on näkyvissä mitä jokainen rivi tekee, miten kääntäjä sitä lukee ja millaiseksi koodiksi se lopulta kääntyy, tyhmänä tuijottaminen vaihtuu osaamisen tunteeksi. Hölmönä vertauksena voisi sanoa, että koodari ei etene täysin sokkona vaan hallitussa mittarilennossa. Tämä on myös yksi syy siihen, miksi C:n päälle kasatut frameworkit tuntuvat niin ikäviltä: jokainen uusi palikka on aluksi hallitsematon musta laatikko.

    C:n kanssa hallinnassa pysyminen on harvinaisen tärkeää koska suunnilleen jokainen virhe on fataali. Sivistyneemmillä kielillä tämä ei enää pidä paikkaansa, mutta kerran opittu paranoia pysyy tiukassa.

    Minusta kielivalinta ei vaikuta tiimin toimintaan aivan niin paljoa. Tarpeeksi päättäväinen cowboykoodari onnistuu torpedoimaan projektin kuin projektin ja samalla vakuuttamaan firman johdon omasta välttämättömyydestään yhtä hyvin Javallakin, vaikka se on vakiintuneiden käytäntöjen suhteen tiukimpia kieliä. Jostain syystä näitä sankareita on ollut mukana suurimmassa osassa projekteista joissa olen ollut mukana, kielestä riippumatta.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *