Tick-the-Code - ohjelmistosuunnittelijalle

Mitä voit ohjelmistosuunnittelijana odottaa saavasi Tick-the-Code -menetelmältä? Olethan jo nyt tarpeeksi kiireinen ilman mitään lisätehtäviäkin. No, siinäpä se. Et voi saada mitään, jos et anna mitään. Jos ongelmasi on aika, tai oikeastaan sen puute, sinun on vaikea hoitaa kaikkia tehtäviäsi. Voi olla, että managerisi laskevat tuottavuuteesi vain toimittamasi toiminnallisuuden määrän. Tuntuu siltä, etteivät he ymmärrä tai edes tiedä sisäisen laadun konseptista. Aikapaineessa on tuhottoman helppoa yrittää säästää aikaa jättämällä koodi hiomatta niin selkeäksi ja ymmärrettäväksi kuin osaisit. Tai sitten kerrot itsellesi, että vain viivästät hiomista. Tarkoituksesi ei ehkä ole edes tehdä niin, mutta niin tapahtuu. Koodisi sisäinen laatu alkaa kärsiä.

Tähän mennessä lienet huomannut, että huono sisäinen laatu korreloi virhemäärien kanssa. Mitä huonompi sisäinen laatu on, sitä enemmän virheitä koodissa todennäköisesti on. Mitä enemmän virheitä on, sitä enemmän korjattavaa sinulla on. Mitä enemmän korjattavaa sinulla on, sitä vähemmän aikaa sinulla on tuottaa uutta toiminnallisuutta. Mitä vähemmän uutta toiminnallisuutta tuotat, sitä ahdistuneemmaksi managerisi tulee. Mitä ahdistuneempi managerisi on, sitä enemmän painetta hän kohdistaa sinuun. Mitä enemmän painetta sinuun kohdistuu, sitä huonompaa koodisi sisäinen laatu on. Yhteenvetona: mitä kiireisempi olet, sitä kiireisemmäksi tulet (jos tingit laadusta).

Kiireen noidankehästä on vain yksi terve pakotie. (kts. Kaavio 1.) Sinun tarvitsee nostaa koodisi sisäistä laatua käyttämättä siihen paljon aikaa. Se on ainoa TERVE tapa.

Sisään astuu Tick-the-Code, menetelmä tahattoman monimutkaisuuden löytämiseen lähdekoodista. Alustavien ohjelmistotieteellisten tutkimusten mukaan Tick-the-Code mittaa monimutkaisuutta ohjelmistomoduuleista aivan kuten syklomaattinen lukukin. Kuva 1. osoittaa kuinka syklomaattinen luku ja tikkimäärät muutamasta avoimesta lähdekoodimoduulista korreloivat keskenään. Sarjan korrelaatio oli vahva 0.7.

On myös osoitettu, että Tick-the-Code -menetelmää käyttäen kehittäjät löytävät omasta koodistaan paljon enemmän kehitysmahdollisuuksia kuin perinteisin menetelmin. Kuva 2. osoittaa kuinka paljon aivan tavallisten kehittäjien tarkastustehokkuus kasvoi heidän opittuaan Tick-the-Code -menetelmän. Löydösten määrän kasvu on vaikuttava. Keskimääräinen henkilökohtainen kehitys oli viisinkertainen (mitattuna 39 ohjelmistosuunnittelijan yhden tunnin työllä.) Kokeessa käytetty lähdekoodi oli oikeaa tuotantokoodia. Kun kehittäjät olisivat omin neuvoin löytäneet keskimäärin 34 korjattavaa asiaa, Tick-the-Code -menetelmällä he löysivät (todellakin löydettiin, 'jälkeen'-luvut ovat todellisia tuloksia, kun 'ennen'-luvut on ekstrapoloitu 15 minuutin etsinnän pohjalta) keskimäärin 105 parannettavaa asiaa kukin! Tämä osoittaa, että lähes kuka tahansa ohjelmistokehittäjä voisi olla paljon tehokkaampi etsiessään ja löytäessään tuotantokoodin parannuksia. Etkö sinäkin haluaisi olla parempi?

Tick-the-Code on myös erittäin nopea. Tunnissa voit käydä läpi tuhat riviä koodia. Tunnissa pystyt löytämään merkittävän määrän parannusehdotuksia. Jos teet parannukset, säästät merkittävän määrän aikaa, koska sinulle jää vähemmän virheitä korjattavaksi. Taulukossa 1. näet kokeiden kattaman koodimäärän.

Kuinka Tick-the-Code oikein löytää nämä parannukset? Sen voima tulee tarkasta keskittymisestä ja periaatteista. Menetelmässä on tarkasti ennaltamääritellyt koodaussäännöt, jotka pohjautuvat hyviin koodausperiaatteisiin. Tarkistajat keskittyvät yhteen sääntöön kerrallaan ja etsivät sen rikkomuksia koodista. Keskittynyt tarkistaminen selittää suuret löydösmäärät.

Periaatteet tekevät löydöksistä relevantteja. Periaatteita on neljä: "Puuttuva tieto", "Ylimääräinen tieto", "Kaaoksen aiheuttajat" ja "Vaaralliset oletukset".

Nimensä mukaisesti Puuttuvan tiedon periaate sanoo, että "koodin tulee sisältää kaikki tarpeellinen." Tämän kategorian säännöt etsivät puuttuvia paloja, kuten vakioiden nimiä (MAGIC), loogisia polkuja (ELSE) ja sulkuja (PTHESES).

Puuttuva tieto aiheuttaa virheitä ylläpidossa. Ainakin aikaa hukataan, kun vaatimusmäärittelyjä täytyy tarkistaa turhasti, jne. Turhasti, koska koodi voisi yhtä hyvin jo sisältää tarvittavan tiedon.

Ylimääräisen tiedon periaate on äskeisen vastakohta: "koodissa ei saa olla mitään turhaa." Tämän kategorian säännöt etsivät tarpeettomia kommentteja (DRY), käyttämätöntä koodia (DEAD) ja monistettua koodia (UNIQUE). Mitä enemmän koodia on, sitä vaikeampaa ylläpito on. Tämä on (lähes) ainutlaatuinen ominaisuus, joka vain Tick-the-Code -menetelmässä on. Pystytkö nimeämään toisen muodollisen tavan turhien rakenteiden poistamiseen koodista?

Kaaoksen aiheuttajat rikkovat vaateen "pyri koodissa aina selkeyteen." Tämän kategorian säännöt pyrkivät paljastamaan koodin osia, jotka monimutkaistavat sitä turhaan. Liian pitkien funktioiden käyttö (CALL), niiden huono nimeäminen (NAME), sekä epäselvä tarkoitus (FOCUS) aiheuttavat varmasti ongelmia. Syvästi sisäkkäinen koodi on liian hankalaa ymmärtää, tai testata tehokkaasti. Tällaisten asioiden poistaminen koodista tekee siitä yksinkertaisempaa. Mitä yksinkertaisempaa koodi on, sitä helpompaa sitä on ylläpitää rikkomatta sitä.

Joskus koodi luottaa järjestelmän muihin osiin liikaa. Digitaalisen herkissä ympäristöissä pienimmätkin epätarkkuudet voivat aiheuttaa jopa kuolemanvakavia virheitä, joten on järkevää antaa ohjeeksi "älä luota mihinkään sokeasti." Vaarallisten olettamusten kategoria korostaa varmuutta. Kategorian säännöt auttavat löytämään paikkoja, joissa kenties kannattaisi varmistaa selustansa. Osoittimia ei pitäisi käyttää, jos niiden arvo voi olla NULL (NEVERNULL), eikä muitakaan arvoja pitäisi tarkistamatta käyttää (CHECK-IN). Liikenteessä tällainen varmisteleva ajaminen tarkoittaa omista oikeuksista luopumista turvallisuuden hyväksi. Varmisteleva koodi saattaa joutua tinkimään suorituskyvystään toimiakseen aina varmasti oikein.

Tällainen koodin periaatteellinen tarkistaminen tuottaa relevantteja koodin kehitysmahdollisuuksia käden käänteessä. Eikä ainoastaan lähdekoodi parane, vaan Tick-the-Code -menetelmää käyttävät kehittäjät kehittyvät oppiessaan noudattamaan hyviä koodausperiaatteita.

Jos mielestäsi koodauksen ei pitäisi olla pelkästään virheiden korjausta ja saman koodin jatkuvaa käsittelyä typerien ja hankalasti löydettävien virheiden takia, kokeilepa Tick-the-Code -menetelmää. Se ei vie juurikaan aikaa, mutta sen tuottama vaikutus työelämäsi laatuun voi olla erittäin positiivinen. Mitä voisit muka hävitä?