Tick-the-Code - koeajo

Tulosta koodia. Tuhat riviä riittää mainiosti. Mukaanlukien tyhjät yms. rivit. Jos tunnet C-kieltä, voit tulostaa vaikka tämän avoimen lähdekooditiedoston (<20kB). (Tiedostossa käytetään Unix-tyylisiä rivinvaihtoja (LF).) Koeajettuasi (tai koetikattuasi) sen, voit verrata tuloksiasi omiini. Niiden pitäisi täsmätä suurin piirtein.

Ota kirkkaanvärinen, ohut tussi (ei-musta kynä siis). Varaa tunti keskeytyksetöntä aikaa. Etsi rauhallinen paikka, johon vetäytyä, jos työympäristösi on meluisa. Suojele laatuaikaasi ja sitoutumistasi. Hiljennä puhelimesi ja hakulaitteesi, unohda sähköpostit, tekstiviestit ja muut häiriötekijät. Piiloudu henkilökohtaisilta keskeytyksiltä. Kyseessä on vain yksi tunti. Kuka tahansa voi olla tavoittamattomissa tunnin.

Nyt olet valmis aloittamaan.

Ota tämä sääntö vakavasti. Älä kyseenalaista mitään sääntöä tarkistajana. Vaikka sääntö tuntuisi kuinka yksinkertaiselta hyvänsä, tarkista se käsin. Vaikka voisitkin tehdä skriptin tarkistamaan sitä, älä tee. Yksinkertaiset säännöt auttavat sinua rentoutumaan.

Lupaa, ettet kyseenalaista seuraavaakaan sääntöä. Noudata vain sitä! Lupaa se minulle!

MAGIC-sääntö sanoo, ettei koodiin saa kuulua kovakoodattuja arvoja. Sinun tulee tarkistajana ympäröidä (kirkkaanvärisellä kynälläsi) kaikki pelkät numerot (42), kirjainvakiot ('b') ja merkkijonot ("characters"), jotka löydät keskeltä koodia, ja nimetä ympyrä sanalla "MAGIC". Löydettyäsi jotain, tikkaa se ja siirry etsimään seuraavaa. Älä pysähdy ihmettelemään. Älä edes mieti, miten "korjaisit" sen. Numeron löytämiseen ja tikkaamiseen ei pitäisi monta sekuntia kulua. Etene niin nopeasti kuin vain suinkin pystyt. Tavoitteena on huomata kaikki sääntörikkomukset.

Tikkaa nollat (0) ja ykköset (1) riippumatta siitä, missä ne ovat. Kyllä, jopa for-silmukassa.

Tikkaa pelkät numerot taulukon indekseinä (array[4]).

Älä tikkaa arvoa NULL, se ei ole kovakoodattu arvo.

Älä tikkaa #define- tai const -arvoja, niillä on jo nimet.

Älä oleta, että sinun tarvitsee tehdä tikeille jotain. Älä huolehdi siitä vielä. Tulet tikkaamaan myös kohtia, joita ei muuteta. Mutta ainakin tikkaat vauhdilla.

Kunhan olet käynyt läpi koko koodin tikaten joka rikkeen, laske ne ja kirjoita tulos ylös lähdekoodin kansilehdelle (esim. MAGIC: 55). Kirjaa ylös myös aika minuuteissa. Jos tässä vaiheessa heräsi kysymyksiä tai huomioita, kirjaa nekin ylös.

Tämän säännön perustelut ovat siinä, että numerot ja muut arvot, jotka taianomaisesti ilmestyvät koodiin, ovat todellinen riesa ohjelmistojen ylläpidolle. Lisäksi eri arvojen väliset riippuvuudet puuttuvat usein kokonaan koodista. Aikaa ainakin menee hukkaan, kun ylläpitäjä yrittää selvittää, kuinka muuttaa koodia oikein.

Toinen sääntö on nimeltään ELSE. Etsi kaikki if-ehdot, joista puuttuu else-haara. Toisin sanoen etsi ensimmäinen if-ehto ja tarkista onko sillä else-haara. Jos ei ole (eikä kommenttia siitä, ettei sitä tarvita), ympäröi if-sana (joka siis siellä on) kivan kirkkaalla värillä ja kirjoita niin lähelle sitä kuin pystyt - lukukelpoisella käsialalla - säännön nimi: "ELSE". Etsi sitten seuraava if-lauseke. Muuta ei tarvitse tehdä. Koita löytää jokainen puuttuva else-haara.

Ketjun if-else-if tulee päättyä else-haaraan, muuten se rikkoo tätä sääntöä ja pitää tikata.

Säännön järki on siinä, että unohtunut else-haara voi olla vaarallinen looginen reikä koodissa. Vaikka kielen syntaksi ei vaadikaan else-haaraa, ja vaikka se onkin monissa tapauksissa tarpeeton, sen puuttuminen hankaloittaa ylläpitoa, sillä sekä tarpeettomat että unohtuneet else-haarat näyttävät samoilta.

Yleisenä ohjeena mainittakoon, että jos olet kahden vaiheilla tikatako vai ei, niin tikkaa. Epävarmuutesi kertoo, ettei kaikki ehkä ole kunnossa. Asia on myöhemmin tarkistettava. Tikkaa kohta, jotta muistat tarkistaa.

Sitten seuraa sääntö nimeltä TAG. Tagihän kiinnitetään normaalisti esimerkiksi matkalaukkuun tai varpaaseen. Jotkut kommentit ovat kuin tagejä, kuin merkkejä keskeneräisyyksistä koodissa. Sääntö kieltää sellaisten kommenttien käyttämisen. Keskeneräisen koodin viimeistely saattaa unohtua. Silloin koodi ei tee kaikkea, mitä sen tulisi. Joskus merkkikommentit osoittavat unohtuneisiin asioihin, jotka ovat aina ongelmallisia äärimmäistä tarkkuutta vaativassa digitaalisessa maailmassa.

Merkkikommentti kutsuu luokseen viimeistelemään homman. Yksinkertaisimmat merkkikommentit sisältävät sanan TODO, FIXME, XXX, HACK tai vaikkapa käyttäjänimen tai jotakin muuta helposti löydettävää. Hankalammat vain vihjaavat keskeneräisyydestä päättymällä kysymysmerkkiin (?) tai kolmeen pisteeseen (...). Lue kukin kommentti ja tikkaa ne, joissa vihjataan keskeneräiseen koodiin tai jotka ovat muuten epävarmoja. Ehkä on tullut aika viimeistellä homma.

Jotkin kommentit saattavat mainita väliaikaisista korjauksista liittyen johonkin tiettyyn kääntäjäversioon. Sellaiset kommentit tikataan mahdollisesti vanhentuneina. Olisiko tullut aika päästä eroon väliaikaisista ratkaisuista.

Seuraava sääntö on nimeltään CLOSURE. Kun vapautat dynaamista muistia (free()), osoitin, jonka sait varatessasi muistilohkoa (malloc()), osoittaa edelleen vapautettuun lohkoon. Se näyttää täysin normaalilta ja käyttökelpoiselta, mutta sen käytöstä seuraa ongelmia.

Etsi paikkoja, joissa osoitin pitäisi asettaa NULL-arvoon, eli tehdä käyttökelvottomaksi. Käyttökelvottomuus tarkoittaa sitä, että osoittimen tahattomasta käytöstä seuraa sen verran selkeä virhetilanne, ettei sitä voi olla huomaamatta.

Tämä sääntö sopii kaikkiin tilanteisiin, joissa osoitin, viite, olio, kahva tai jokin muu resurssi ei enää ole käytettävissä. Tietokannat, pistukat (socket) ja tiedostonkäsittely sisältävät kaikki "avaa- ja sulje"-pareja, minkä jälkeen osoitin tai kahva tulisi tavalla tai toisella tehdä käyttökelvottomaksi.

Paikanna koodia, joka tarvitsee lisää sulkuja. PTHESES-sääntö pätee niin aalto-, kaari- kuin hakasuluillekin.

Jos esimerkiksi monimutkainen laskutoimitus pakottaa miettimään operaattorien laskujärjestystaulukkoa, jotta ymmärrät laskujärjestyksen, on siinä liian vähän sulkuja.

Tarkista makrot erityisen hyvin, ne kaipaavat usein lisäsulkuja.

Ehtoa if tulisi aina seurata kaarisuluilla ympäröity koodilohko, vaikka kyseessä (tällä hetkellä) olisikin vain yksi koodirivi.

Tämä siksi, että sulutettuna koodin muuttaminen ei ole niin virhealtista kuin ilman sulkuja. Ilman yhtä riviä ympäröiviä sulkuja on olemassa vaara, että lohkoon lisätty sisennetty koodirivi vain näyttää olevan if-then-lohkon sisällä.

/* alkuperäinen */        /* väärä muutos */          /* oikea muutos */
if('expression')          if('expression')            if('expression'){
    just_one();      =>       just_one();                 just_one();
                              yet_another_one();          yet_another_one();
                                                      }

Sääntö ei määrää, mihin sulut tulisi sijoittaa. Se on tyyliseikka, eikä sellaisissa ole vääriä vaihtoehtoja, vain erilaisia mielipiteitä.

Tätä sääntöä kutsutaan nimellä CALL. Tehtäväsi on etsiä koodilohkoja, jotka voisivat olla oma funktionsa tai metodinsa, mutta eivät ole. Lohkoja löytyy parhaiten pitkistä funktioista ja metodeista. Ympäröi koko lohko, jolla on selkeä tehtävä ja josta saisi hyvän alirutiinin.

Modulaarisuus on kommenttien ohella tärkeä teema Tick-the-Code -menetelmässä. Koko sääntökokoelmassa on kaikkiaan neljä modulaarisuussääntöä ja neljä kommenttisääntöä. Vaikka suurimmat suunnittelupäätökset on jo tehty arkkitehtuurivaiheessa (missä arkkitehtuurivaiheessa?), peliä ei ole täysin menetetty koodausvaiheessakaan. Valtavista funktioista voidaan pilkkoa pienempiä, helpommin hallittavia rutiineja. Vähän kerrassaan isokin järjestelmä muuttuu hallittavammaksi. Olettaen tietenkin, että käytettävissä on tarpeeksi aikaa. Siksi sinun tuleekin toistaa tämä harjoitus ensi viikolla. Pienin, mutta säännöllisin teoin voit käydä läpi suurenkin järjestelmän ilman että se vaikuttaa häiritsevästi normaaliin työhösi.

Nyt olet käynyt koodin läpi kuudesti. Laskepa yksittäisten sääntöjen tikkimäärät yhteen ja kirjaa se kokonaisajan viereen etusivulle.

Jos käytit oikeaa koodia, vie se koodin ylläpitäjälle ja pyydä häntä vilkaisemaan löydöksiäsi. TÄRKEÄÄ: Pidä huoli siitä, että ylläpitäjä ymmärtää, ettei yksikään tikki pakota mihinkään toimenpiteisiin. Ylläpitäjän ei tarvitse tehdä mitään turhaa(n). Joka säännön takana on kuitenkin tärkeä koodausperiaate ja mikä tahansa tikeistä saattaa osoittaa oikean heikkouden lähdekoodissa. Jokainen tikki on parannusmahdollisuus, joten niitä ei tulisi jättää kokonaan huomiotta.

Lähetä kommenttisi ja kysymyksesi osoitteeseen testdrive@tick-the-code.com. Jos lähetät tarpeeksi yksityiskohtaiset tiedot koeajostasi (kunkin säännön tikkien määrät, tarvitsemasi ajan, tarkistamasi koodin määrän ja ohjelmointikielen) niin minä lähetän sinulle Tick-the-Code -sääntökorttisetin. Muista ilmoittaa postiosoitteesi.

Jos käytit esimerkkikoodia, voit nyt verrata tuloksiasi tuloksiini oikealla. Niiden tulisi suurin piirtein täsmätä.

Jos haluat tämän koeajon jälkeen oppia vielä lisää, pyydä toki Tick-the-Code -koulutustarjousta yritykseesi tai kaupunkiinne.