Kolme askelta laadukkaaseen koodiin Clean Code -oppien mukaan

Järjestelmiä saatetaan ylläpitää vuosikymmeniä, ja siksi koodin laadulla on merkitystä. Sitä, että koodi valmistui erityisen nopeasti, tuskin kukaan muistaa enää viikon, saati vuoden päästä. Sen sijaan huonosti kirjoitettu koodi näkyy koko järjestelmän käyttöajan. 

Siististä koodaamisesta on kirjoitettu oppaita (esim. Robert C. Martinin eli Uncle Bobin Clean Code) ja on myös olemassa staattisia skannereita (SonarQube yms.). Silti on hyvin tavallista, että koodin ylläpitämisessä on ongelmia. Yleensä tämä koskee nimenomaan kirjoitettua uutta koodia. On otettu käyttöön jokin hieno uusi framework, mutta koodi ei ole erityisen selkeää.

Itselleni on tärkeää, että pystyn koodaamaan helposti ylläpidettävää koodia. Tämän osaamisen kehittämisessä Clean Code on ollut minulle tärkeä ohjenuora. Käyttämällä hieman aikaa, ennen kuin laitan koodin versionhallintaan, saan tehtyä laadukkaampaa koodia ja säästän aikaa ylläpidosta.

Huomioimalla kolme asiaa parannat koodia merkittävästi:

1. Järjestele ja siivoa koodi siten, että esimerkiksi metodit ja luokat ovat mahdollisimman lyhyitä. Tällöin niitä on helpompi ymmärtää. Clean Code -kirjassa on jopa esimerkki neljän rivin metodista. Uncle Bob ei määrittele mitään sääntöä metodien pituudelle, mutta on selvää, että 556 rivin pituiset metodit tai parin tuhannen rivin luokat eivät ole helposti ymmärrettäviä. Tämä pätee myös esimerkiksi käyttöliittymän Javascript-koodiin, joka myös helposti paisuu kuin pullataikina.
2. Käytä kuvaavia nimiä esimerkiksi muuttujien ja metodien nimeämiseen. Jos olet lisäämässä koodiin muuttujaa vaikka etunimeä varten, harkitse, olisiko esimerkiksi “firstName” ymmärrettävämpi kuin “x4”. Kun käsitellään käyttäjän sähköposteja viikonlopun jälkeen, voisiko metodin nimi olla “processUserEmailsAfterWeekend” mieluummin kuin “doThings”?
3. Luovu kommentoinnista. Clean Code -kirjasta opin, että kommentit ovat yleensä turhia. Uncle Bob vaikuttaa vihaavan kommentteja (sekä niiden kirjoittajia). Jos kommentit jäävät uimaan koodin joukkoon eikä niitä päivitetä, on todennäköistä, että ennen pitkää kukaan ei ymmärrä kommentteja eikä uskalla tehdä niille mitään. Jos metodi on lyhyt ja hyvin nimetty ja koodi selkeää, niitä ei tarvitse kommentoida lainkaan. On parempi käyttää aikaa koodin siivoamiseen kuin epäselvän koodin kommentoimiseen.

Edellä kuvattuja asioita voi käytännössä toteuttaa esimerkiksi näin:

Metodi       

       /**
          The things:
                -check
                -processes emails before weekend (note if possible)
                -saves data
           Check ticket IPA-245 (but no IPA-244!!)
       **/
       public int doThings(X45Holder x1) {
                int x2, var3, var45 = 0;
                // note: current code processess emails after weekend
                // kanta alas ja ylös, jos ei auta soita Kale 040-764 7939
                …
                897 riviä sekavaa koodia
                …
                return !(noYesAlertMode – 0.5);
       }

olisi selkeämpi näin:       

       public void processEmailsAfterWeekend(Parameters parameters) {
              checkParameters(parameters)
              List<Email> emails = fetchEmailsAfterWeekend(parameters)
              List<ProcessedEmail> processedEmails = processEmails(emails)
              saveProcessedEmailsToDatabase(processedEmails)
       }

Mitkä ovat kolme sinulle tärkeintä asiaa koodin ymmärrettävyyden kannalta?

Mika Tapanainen, Full stack developer, Fonzit Oy