Coding Dojo på Contiki
- Wednesday, April 29th, 2009
- Skriv en kommentar
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
Kategorier: Jobb, NNUG / community, Testing / TDD.
RSS feed for kommentarene.
Tilbaketråkk.
April 30th, 2009 at 9:42 am
Som deltaker i dojo’en fikk jeg lyst til å skrive en kommentar. Jeg syntes dette var kjekt og lærerikt, og jeg har lyst til å ha flere slike sesjoner. Denne gangen hadde vi en ikke-relevant programmeringsoppgave da Texas Hold’em dessverre ikke er med i Contikis domain. Jeg tror dette er mulig å gjøre også med “ekte” arbeidsoppgaver. Jeg tror det ville gitt det en annen opplevelse, som i hvert fall er verdt å prøve ut. Da blir det i hvert fall mindre fiendtlig mottatt av ledelsen.
Vi endte opp med flere lange diskusjoner om hva TDD egentlig innebærer og selv om Torbjørn er ganske selvsikker i sine meninger betyr ikke det at han har rett. Slik jeg ser det er det to retninger innen TDD og Torbjørn holder til i den ene leiren og hevder at den andre leiren misforstår/tar feil. Jeg er sikker på at de andre sier det samme om Torbjørn’s leir.
Torbjørn skriver også om at vi strengt tatt ikke drev med parprogrammering da vi i effekt hadde tre navigatorer. Grunnen til det tror jeg har litt med måten vi har drevet med parprogrammering før, nemlig hvor man ikke sitter på siden av hverandre, men i steden sitter mot hverandre. Da avbryter man bare den andre når man vil og mye mer naturlig enn når man bruker gamlemåten hvor man har en navigator. Å ikke si i fra når man føler man ser noe som man mener er feil, føles ikke riktig …
April 30th, 2009 at 9:56 am
Bra kommentar, Halvard. Jeg vil bare få påpeke at når jeg sa at “den andre leiren” misforstår, så mener jeg at de misforstår i forhold til hva Kent Beck, TDD’s gjennoppdager, sier. Det er mange veier til mål, men jeg har stor trå på TDD slik jeg nå forstår det, og pusher det etter beste evne inntil jeg erfarer noe bedre.
Jeg har også tro på å prøve ut Coding Dojo på relevante arebidsoppgaver, men vil anbefale å venne seg til det med oppgaver uten “legacy code”, som bare vil være en forstyrrende faktor. Målet vil da endre seg fra å lære TDD, parprogrammering og teknikker, til å faktisk produsere fungerende kode – som selvsagt også er et verdig mål, bare ikke det jeg var ute etter.
Og ja, jeg er enig i at når man var bare fire stykker så var det helt naturlig at alle fikk uttrykke meningene sine. Vi hadde ikke trengt å si at noen var navigator i det hele tatt. Dette ville derimot ha fungert dårlig om vi var f.eks. 10 utviklere, tror du ikke det? Da tror jeg man burde vist mer respekt for paret som programmerte (det finnes jo mange riktige måter å gjøre ting på), og heller lære noe ved å forsøke å tilpasse seg til det som allerede er gjort når det er ens egen tur til å delta i paret.
December 19th, 2009 at 10:34 am
[...] Og det er mye å snakke om – mitt problem er å klare å velge. Jeg kunne tenke meg å snakke om alt fra prinsipper som Single Respoinsibility, Don’t Repeat Yourself og Command Query Separation, via TDD og parprogrammering til patterns som Strategy, State, Visitor osv. Det kan også være et greit fora for å introdusere eller gå dypere inn i ulike verktøy som IoC, NDepend, osv. Og jeg ønsker også å utfordre teamet med å snakke om andre programmeringspråk, og å gjøre mere praktsike tings – noe i retningen av coding dojo. [...]