For de fleste programmerere er det viktig å finne defektene i koden man produserer, slik at kvaliteten er høyest mulig. Man har ikke lyst til å gi ut programvare som er full av feil. Men et trist faktum er at de aller fleste programmer har defekter. Undersøkelser viser at kommersielle programmer har i snitt 20-30 bugs per tusen linjer kode.

Det er mange forskjellige typer defekter i kildekode, og noen er mindre kritiske for programkjøring enn andre, men alle feil bør finnes og fikses. Det finnes en del metodikker som kan senke feil-frekvensen. Noen eksempler på disse er Extreme Programming,Test Driven Developmen og Code Review

Disse metodikkene er fullverdige metoder for å øke kvaliteten på programvaren man produserer, og bør vurderes som en del av den totale utviklings-modellen.

Det er flere måter å finne bugs i kode. Et av disse er statisk analyse av koden. Statisk analyse er å gå gjennom koden og lete etter kjente mønster som indikerer feil, uten å kjøre koden. For Java finnes et program som heter FindBugs. Dette programmet søker gjennom byte-koden etter feil-mønster den kjenner igjen. Den kan f.eks. finne feil der man har glemt en break i en switch statement, eller indikere at noe er feil hvis den ser kode som ikke benytter retur-verdien fra en streng-operasjon. Findbugs kan også finne såkalte falske positiver, dvs at den indikerer at det er feil der det faktisk ikke er feil, men den har selvfølgelig som mål å finne færrest mulig slike.

Det som er veldig fint med Findbugs, er at den også finner kode som ikke nødvendigvis er feil, men som kan være en kjent men dårlig måte å skrive kode.

Jeg har testet FindBugs på et av mine personlige prosjekter, og den fant endel tvilsom kode og et par feil, som jeg sannsynligvis ikke hadde funnet selv før noe gale skjedde i programmet mitt. Jeg testet det også på prosjektet på jobb, og fant noen bugs som garantert hadde dukket opp senere og vært vanskelig å finne ut av. Jeg synes FindBugs er meget nyttig, og er blitt en integrert del av vektøyskassen min til utvikling. Versjon 1.1 er nettopp kommet, og bør sjekkes ut. Det kan være man blir litt flau når man ser hvilke rariteter FindBugs finner i koden, men de framtidige brukerne av programmene dine vil nok være fornøyd med resultatet.

Flere lenker:
Bloggen til forfatteren av FindBugs
Extreme Programming
Introduction to Test Driven Development (TDD)
Effective Code Reviews Without the Pain

Jeg har installert Linux hjemme med diverse hjelpeverktøy for utvikling. Mest fordi jeg er en tekno-junky, men også fordi jeg liker å pludre litt med ting hjemme som kan hjelpe meg å gjøre jobben min bedre.

På Linuxen min har jeg installert Subversion, DokuWiki, Bugzilla, CruiseControl, og MySQL. Jeg har konfigurert opp disse programmene slik at jeg kan sjekke inn kildekode i Subversion, så henter CruiseControl ut den koden og kompilerer den og sender meg en epost hvis den ikke greier å bygge det prosjektet kildekoden hører til.

Jeg har brukt DokuWiki til å kjapt kunne skrive ned spesifikasjoner og notater om ting jeg holder på med, og dermed ha dem lett tilgjengelig til senere. Bugzilla har jeg ikke brukt mye enda, men det er meningen at den skal hjelpe meg å holde oversikt over bugs i prosjektene mine.

Alt dette er vel og bra. Jeg har stort sett det jeg trenger til å kunne utvikle et produkt og holde oversikt over notater, og bugs, og evt om det er problemer med å bygge prosjektet fra kildekoden i Subversion.

Hvis jeg har en bug i et av prosjektene mine, må jeg skrive inn bugen i Bugzilla. Mens jeg holder på å fikse bugen skriver jeg kanskje noen notater i Wikien. Når jeg sjekker inn kode som er relatert til bugen skriver jeg innsjekkings-meldinger med notater om bugen også. Å holde dette i synk viser seg i praksis å være en tidkrevende og brysom jobb når det må gjøres manuelt.

I går leste jeg en artikkel om hvordan integrere Bugzilla, Subversion og en Wiki, slik at man enkelt kan legge inn lenker i Bugzilla til Subversion-filer, eller wiki-sider. Den forklarer også hvordan man skal få Subversion til å melde ifra til Bugzilla når en innsjekkingsmelding inneholde referanse til en bug, og legge til nye tags i wikien, så den automatisk lenker til bugs og kildekode i Subversion. Den viser også hvordan man auto-genererer ChangeLog filer direkte fra Subversion i forskjellige format.

Ingen av disse tingene er helt nye, men når man slår sammen alle verktøyene til en integrert verktøy-pakke, så blir resultatet ganske genialt! Det gjør det enklere og mindre tidkrevende å holde Bugzilla og Wiki og ChangeLogs synkronisert i forhold til koden, og man føler at man får mer utbytte av hvert enkelt verktøy når de er konfigurert slik. Jeg skal innrømme at det er totalt overkill for meg å sitte med et slikt system, men som tekno-junky er det veldig deilig å se hvordan man kan få til ting som dette. Det er nok mer noe for jobben enn for leking hjemmme.

Ifølge denne artikkelen er ikke alle programmeringsspråk like kraftige. Noen er mye bedre enn andre.

Det er vanskelig å ikke være enig etter å ha lest artikkelen. Han sier at man lett kan kjenne igjen språk man kan som ikke er så kraftige som språket man bruker i dag, men at det er umulig å vite om språk man ikke har erfaring med er bedre. De virker kanskje bare rare. Jeg tror det er på tide å lære noen nye programmeringsspråk.

Jeg kikket på Continuous Integration artikkelen til Martin Fowler for et par uker siden og oppdaget at han hadde oppdatert den ganske kraftig tidligere i år. Nå inkluderer den litt mer tidsriktig informasjon, som f.eks. å anbefale Subversion til versjonskontroll.

Kort fortalt handler artikkelen om hvordan man får ned antall bugs i kode, og minimalisert stresset forbundet med integrering av moduler til en fungerende build, ved å integrere hele tiden. Det gjøres ved at man har en såkalt ‘build server’, som Cruise Control. Denne programvaren sørger for å bygge hele løsningen og kjøre tester, automatisk og så ofte som mulig, enten på bestemte tidspunkt, eller når noen sjekker inn ny kode i versjonskontroll-systemet. Hvis noe går gale får de ansvarlige utviklerne beskjed i form av e-post eller, hvis de vil, kan de sjekke resultatene av byggingen på en vevside som genereres av Cruise Control. Artikkelen forklarer fordelene ved å gjøre dette, og hvordan få det til i praksis.

Jeg har installert og kjørt Cruise Control noen dager nå, og det virker som et solid system, som burde kunne brukes på de fleste prosjekter. Det må innrømmes at det føles som overkill for meg her hjemme, men det å ha praktisk erfaring med Continuous Integration kan bare være en fordel, slik jeg ser det.