onsdag 29. april 2009 Jobb CodingDojo
I går arrangerte jeg min første Coding Dojo. Jeg har tidligere skrevet om at jeg har lyst til å prøve ut dette formatet på NNUG, men tenkte det ville være et bra første steg å forsøke det på jobben.
En Coding Dojo er et møte hvor en gruppe utviklere jobber sammen for å løse en programmeringsoppgave. Fokuset er å lære seg og praktisere teknikker. Man bruker testdrevet utvikling og parprogrammering, og utviklere av ulike erfaringsnivåer skal føle seg velkomne til å bidra. Hvert femte til syvende minutt rullerer man, slik som dette:
Dojo er japansk, og er navnet på et sted hvor man lærer kampkunst, som for eksempel Judo og Karate. Innenfor disse disiplinene foregår læring gjennom eksempel; man observerer hvordan de som er høyest gradert utfører sine teknikker, og forsøker så selv gjennom å imitere det man har sett. Dette prinsippet kan også fungere innenfor programmering.
Jeg valgte en oppgave designet for Coding Dojo's kalt KataTexasHoldEm, beskrevet her. Jeg hadde forsøkt meg på samme oppgaven kvelden før, og skjønte raskt at oppgaven sansynligvis var for omfattende for de to timene vi satte av til dette. Men jeg håpte likevel den ville gi oss endel erfaring både med parprogrammering og TDD, samtidig som det var et passe spennende domene å modellere.
Det er meningen at publikum skal kunne komme med kommentarer til paret som programmerer. Vi var derimot bare fire utviklere som deltok, og dette førte til at vi i praksis var én driver og tre navigators som uttrykte meningene sine i munnen på hverandre. Kvartett-programmering viste seg å være noe langsommere enn parprogrammering, men også veldig stimulerende. For fremtiden vil jeg likevel forsøke å kontrollere publikum bedre.
Jeg følte vi lærte mest om TDD. Vi så blant annet flere ganger hvordan vi tok for store steg, som gjorde at vi mistet kontrollen noen ganger. Jeg la stor vekt på at man skal få testene grønne så raskt som mulig, og så bruke mer tid på å forbedre og refakturere koden - noe som ble klart for meg etter at jeg leste Kent Becks TDD bok. Vi gjorde også refaktureringer som virket unødvendige.
Etter at vi var ferdige (dvs etter at tiden var ute) snakket vi om hvordan det hadde gått, og vi sammenlignet også løsningen med det jeg hadde gjort kvelden før. Vi ble bl.a. enige om at vi hadde hatt for lite fokus på å skrive tester som førte til fremdrift, og i stedet fokusert for mye på unntakshåndtering - en vanlig feil som ofte fører til at man missliker TDD. Det er viktig å huske at TDD ikke dreier seg om testing, men å bruke tester til å drive design av kode. Dette var nok grunnen til at jeg hadde hatt fått implementert en større del av løsningen i løpet av samme tid.
Jeg lærte forsåvidt endel av å gjøre oppgaven alene også. Det var spennende å se hvordan designet mitt endret seg for hver ny test jeg skrev - endringer jeg ikke hadde forventet. Jeg fikk også tatt i bruk en annen ting jeg blogget om for en stund siden, nemlig Specification pattern. Her er for eksempel objektet som implementerer regelen for om en pokerhånd inneholder ett par:
public class OnePairSpecification : ISpecification<Hand>
{
// Constructor hidden to save space..
public bool IsSatisfiedBy(Hand candidate)
{
for (int i = 0; i < candidate.Count; i++)
{
for (int j = 0; j < candidate.Count; j++)
{
if (i != j
&& candidate[i].IsSameRankAs(candidate[j]))
{
return true;
}
}
}
return false;
}
}
Å implementere forretningsregler som objekter er utrolig kraftig.., absolutt noe jeg anbefaler.
Så, for å oppsummere: Coding Dojo var absolutt en suksess. Mine kollegaer syntes det var et par spennende timer, det var lærerikt, og gav oss inspirasjon. Og jeg har fått enda mer tro på at dette er noe som kan egne seg som et alternativt format på brukergruppemøter i NNUG.
Knagger: Coding Dojo, Contiki, NNUG, parprogrammering, Specification Pattern, TDD