De siste par månedene har jeg lest Code Complete (Second Edition). Håndboken i “konstruksjon av software” skrevet av Steve McConnell er meget populær, og mange har skrytt mye av dem. Code Complete er f.eks. den første på Jeff Atwoods liste over anbefalte bøker for utviklere. Jeff sier:

“Do yourself a favor. Make this the first book you read, and the first book you recommend to your fellow developers.”

Boken gav meg mye, men jeg skulle ha lest den noen år tidligere i min karriære. Den gav meg ikke så mye nå som den ville ha gjort for 6-7 år siden.., men den var likevel inpirerende, og dekker veldig mange ulike deler av det å være en utvikler. Den er også ganske nøytral i forhold til ting som Agile og TDD – den baserer seg på 40 års erfaring fra software-bransjen, og poengterer at ulike metoder passer for ulike prosjekter, at det ikke finnes én sannhet som passer for alt.

Part I og II handler mye om det å forstå software-faget, og om å gjøre et godt design-arbeid før man begynner å kode. Dette var inspirerende, og fikk meg til å se at vi gjør alt for lite av dette nå som vi har blitt så smidige. Selv om man tillater endringer er det mye godt som kan komme ut av fornuftig designarbeid.

De to neste delene handler om kvalitet på det laveste nivået i kode. Part III inneholder 110 sider dedikert til bruk av variabler: Om viktigheten av varabelnavn, om ulike datatyper, osv. PART IV handler om statements: Hvordan kode organiseres, bruk av if og switch .. case, bruk av looper, andre kontroll-strukturer, tabelldreven logikk/metoder m.m.

Part V handlet om forbedring av kode, og her var det mye bra. Forfatteren snakket om hva kvalitet er for noe, og hvorfor vi trenger det. Det handlet om testing, om debugging, code-tuning, og sist men ikke minst refakturering – boken har en meget god liste over refaktureringsteknikker.

Part VI har tittelen “System Considerations”, og handler bl.a. om ting som hvordan størrelse påvirker ulike aspekter under utvikling, om endringshåndtering, om team-arbeid, og om estimering og måling. Det var også et kapittel om hvordan man som utvikler skal administrere sin manager – dette var veldig morsomt. Videre er det kapitler om integrasjon og om ulike verktøy for utviklere.

Part VII, den siste delen, handler om Software Craftmanship. Her tar forfatteren oss ett hakk videre opp på kvalitets-stigen og snakker om layout, kodestil og selvdokumenterende kode. Han snakker om hvilke egenskaper som gjør en utvikler dyktig (som inspirerte meg til å skrive om en utviklers karakter), og om en rekke andre “craftmanship-tema”.

Code Complete er veldig grundig, og refererer veldig mye til andre, kjente publikasjoner, og til undersøkelser og forskning som underbygger forfatterens påstander. Du finner for eksempel konkrete tall som forteller hvor mye du kan tjene på å bruke teknikker som code reviews og parprogrammering. Deler av boken var mindre interessante fordi jeg allerede har mye erfaring, men jeg leste likevel alt, for innimellom kom det alltid noen gullkorn det er verdt å ta med seg. Andre deler av boken var helt uforglemmelige, og gav meg et nytt perspektiv på utviklingsprosessen. Code Complete anbefales derfor på det varmeste.

Knagger: Code+Complete

I dag kom jeg over en side som heter abetterteam (takk til Mark Nijhof for tipset). Siden er et verktøy for å måle et utviklingsteams kvaliteter og skape en diskusjon i teamet.

Spørsmålene skal besvares av hele teamet, men jeg kunne ikke dy meg, og forsøkte å besvare på teamets vegne – for å se hvordan det hele virket. Og her er resultatet:

I fire av de fem kategoriene ligger vi på det røde feltet, som betyr at øyeblikkelig forbedring er påkrevd. Kun i kategorien Releasing er vi såvidt inne på det gule feltet, som betyr at forbedringer er nødvendig (men ikke øyeblikkelig).

abetterteam forklarer at det er prosessen og diskusjonen som spørsmålene skaper som er det viktigste, og det er jeg nok enig i – det var mange, viktige spørsmål å diskutere der, og jeg håper vi kan ta oss tid til en sesjon rundt dette spørreskjemaet i teamet vårt. Men selve resultatet er også svært tydelig, og gir gode tips til hordan vi kan forbedre oss.

Jobber du for å gjøre teamet ditt smidig anbefaler jeg at du tar en titt abetterteam.

Å lese Code Complete har inspirert meg til å dele noen erfaringer, betraktninger og tips med resten av utviklerne i teamet. Så nå har jeg bestemt meg for å gå systematisk til verks og distribuere nye tips ukentlig – internt på Contiki. Vi bruker en MediaWiki jeg satte opp for snart to år siden (ContikiWiki) til å samle og dele kunnskap og informasjon, og der har jeg nå opprettet en egen side der hvor det skal dukke opp et tips hver uke.

Denne første uken er tipset mitt hvordan man kan ta en lang rutine og gjøre den om til en klasse for å gjøre koden enklere å lese og vedlikeholde. Jeg har tatt et reelt eksempel fra vår egen kode, valgt ut helt tilfeldig, og refakturert etter beste evne. Det var lærerikt for meg også – og det er litt av poenget med å gjøre det, selvfølgelig.

Jeg tenkte først at jeg også skulle poste tipsene mine her på bloggen. Men mengden Contiki-kode og formatet på tipset gjør at det ikke egner seg så godt denne gangen. Jeg tror jeg vil vurdere det fra gang til gang – hvis det er noe som er av allmenn interesse, og det ikke innebærer så mye ekstraarbeid, så legger jeg det nok ut her også.

I Contiki jobber vi kontinuerlig med å forbedre måten vi arbeider på. Blant annet har vi tuklet en stund med en endelig definisjon av det vi kaller “done done” – hva som må være på plass for at man er helt ferdig med en utviklingsoppgave.

Og nå har jeg laget en cartoon style poster som viser definisjonen vår. Ta en titt her for full A3 størrelse.