Det är otroligt kul och inspirerande att se Coding Dojos tas emot så väl ute bland de företag jag besöker. Att det är väl mottaget bland utvecklare är uppenbart och kan bl a förklaras med “Code wins arguments”. I “gamla” inkörda team där diskussioner gått i stå och nötts länge kan helt plötsligt helt ny dynamik uppstå. De “gamla” argumenten som gått fram och tillbaka men bara varit abstrakta och teoretiska skall helt plötsligt omsättas i kod, med/inför kollegorna och “helt plötsligt” går det från abstrakt till konkret och inte bara fåtalet engagerar sig och har en uppfattning, utan flertalet.

De Coding Dojos jag driver hos kunder är just detta – praktiska övningar med ett mål eller en poäng. Ingen föreläsningsserie man sitter och nickar igenom och sedan släpper vind för våg. Med riktiga övningar, där alla deltar och skriver kod själva ökar deltagandet, engagemanget och det kritiska granskandet.

Eftersom det ofta uppstår diskussioner med uttryck som “jag brukar göra såhär”, “oj, så har jag aldrig gjort, eller tänkt” så är det viktigt att det inte finns lönesättande chef(er) på plats. Om deltagarna är rädda för att säga fel och börjar väga sin ord så försvinner en stor poäng med dojon. Jag försöker få alla att vara spontana med hur de tänker, att exponera hur de jobbar utanför dojon så att de kan få konstruktiv feedback på sitt arbetssätt. Lönesättande chef och/eller beställer behöver givetvis återkoppling också. Här följer ett exempel från förra veckan.

Hej Kund!

Efter lite hackiga, trevande steg med första övningen tyckte jag mig se en enorm skillnad till tillfälle två. Det märks att flera utvecklare försökt sig på det vi övade i vardagen! Jag tror mig se att så gott som alla utvecklare har fått en ny infallsvinkel till hur de ser på sin kodskrivning och den synen utvecklade vi med en mer realistisk övning ihop med mockning. Det var mycket bra frågor som dök upp, vilket tyder på att de är engagerade, intresserade, verkligen försöker anamma en annan kodordning och har en sund kritisk inställning till vad de gör själva (det är ju inte jag som skriver koden under övningen – jag bara guidar och ger tips)!

Övning 1:

Vi tog en enkel basövning (String calculator).
Vi introducerade red-green-refactor, Arrange/Act/Assert, bottom-up.
Vi tog baby steps bokstavligen med 1 minut som tidkrav att gå från röd till grön.
Vi såg triangulering som ett sätt att driva fram funktionalitet.
Grå zon: “täcker testen all funktionalitet? om inte, har vi använt test-driven utveckling?”

Övning 2:

Vi tog in en ny, ganska stor uppgift som är mycket mer realistisk (tagen från produktionskod).
Vi lade på ett nytt moment/tanke i form av en “testbacklog”. (Verkade vara en ny idé – diskuterade VAB-scenariot och vikten av att kunna dela kod ofta.)
Vi lade på mockning med Mockito. (En del var redan bekanta med Mockito.)
Grå zon: “ett par antydningar till att ändra kod utan att testen uttrycker den funktionella ändringen i koden”.
Vi refaktorerade kod lite oortodoxt (utan test, utan undo/bortkommentering).

Det var mycket motiverande för min del att se utvecklingen i teamet, det var en helt annan “mognad” i TDD-tänket och ett bra driv/bra dialoger. Parprogrammeringen såg bitvis fullständigt klanderfri ut – mycket kul att se! Nästan all kod drevs fram från test (två, tre tillfällen fanns antydan till att skriva kod som inte var testdriven/täckt av test).

Utvärderingen i slutet bjöd mer på kod- och designdiskussioner (jag vill aldrig avbryta sådant) så vi hann inte “utvärdera” så mycket, men på tavlan skrev jag upp:

+ bra frågor
+ bra övning
! refactoring gjorde koden mycket mer läsbar
! smidigt med @Mock
? Använda TestNG nästa gång

Mitt förslag är att vi nästa gång utvecklar i flera par parallellt (en dator per par med Eclipse är vad som behövs), lägger på Clean Code-aspekter och använder samma uppgift och ser hur vi kan få koden att se ut på olika sätt.