JAOO, dag 1: Craftsmanship and Ethics

JAOOs webbplats är på många vis en ganska dålig källa till information. Det är exempelvis svårt, för att inte säga omöjligt, att hitta någon som helst information om vad JAOO står för. "Java Object Orientation" är svaret man kan hitta på enstaka bloggar om man googlar. Jag gissar att man helt enkelt tonar ned denna bit därför att konferensen nu har en bredare publik än vad den förmodligen hade från början. En annan detalj som jag missat, liksom många andra förstagångsbesökare jag pratade med, var att det faktiskt är ett företag, Trifork, som arrangerar konferensen. Trots detta har konferensen väldigt stark "community"-prägel och mottot "for developers by developers" känns faktiskt äkta. Triforks CTO Kresten Krab Thorup inledde konferensen på måndagen med att betona att vad som gör JAOO annorlunda är att det är ett "software company setting up a software conference, not to sell, but to learn themselves".

Den som fick äran att öppna konferensen med en keynote var ingen mindre än Robert C. Martin (alias "Uncle Bob") som talade under rubriken "Clean Code II: Craftsmanship and Ethics". Bob Martin visade sig vara en fartfylld välartikulerad man som gestikulerar med hela kroppen för att engagera publiken och han fick i alla fall mig att bli riktigt inspirerad och engagerad. Faktum är att jag tycker ämnet för hans keynote var så pass intressant att jag ska försöka redogöra för det i detalj.

Efter en effektfull, men kanske något för lång och irrelevant, inledning där han använde Kresten Krab Thorups kropp som material för en historisk exposé över jordens historia och människans lilla del däri, ställde Martin den provocerande frågan: "do we have a profession"? Hans svar var tvekande; under en lång tid gjorde utvecklare lite som de ville, valde sig egen stil. Yrket har inte några regler och riktlinjer, ingen historia med ritualer som till exempel advokater och läkare. Men runt millennieskiftet något hända, vårt hantverk definieras och vi börjar få en historia som vår praxis kan luta sig mot. Det börjar bli möjligt att definiera ett yrke som kan luta sig mot en disciplin snarare än förlita sig på dokumenterade processer. Den disciplin Bob Martin förespråkar är förstås Agile.

För att visa sin hängivenhet till de principer och praktiker som denna disciplin bygger på bär Martin, och numera även många av JAOOs deltagare inklusive undertecknad, ett grönt armband med påminnelsen/uppmaningen "Test first". Men exakt vilka principer och praktiker är det vi talar om?

• Short iterations
  Martin förspråkar en eller två veckors iterationer, fyra är alldeles för lång tid. I slutet av varje iteration ska det finnas exekverbar kod, dokumentation, tester etc. Det ska i princip vara möjligt att leverera mjukvaran varannan vecka.
• Don't wait for definition
  Sitt inte och vänta på att någon annan ska definiera vad som ska göras, utan bidrag själv till definitionsprocessen genom att bygga kod och få feedback.
• Abstract away volatility
  Kod som är en mer trolig kandidat för förändring ska vara på ett ställe och kod som troligtvis inte behöver förändras ska vara på ett annat. "No JavaScript doing business logic in the GUI!"
• Decouple from others
  Koda inte direkt mot andras implementationer, då kan du lätt bli sittande och vänta på att de ska bli klara. Använd stubs, mocks, simulators och så vidare - då berättar du också för andra hur du vill att interfacen ska se ut.
• Never be blocked
  Detta är "The Prime Directive". Martin använde ett exempel med en grupp testare som "inte kunde göra något" eftersom deras testserver inte var konfigurerad. Har inte utvecklarna fungerande mjukvara på sina datorer? Sätt er vid en av dem! Något kan man göra medan man väntar...
• Avoid turgid viscous architectures
  En del arkitektur hindrar mer än den hjälper. Den skapas ofta av arkitekter som vill lösa allting. Ett sätt att komma till rätta med problemet är att låta arkitekterna utveckla: "If architects have to write code they have to live in the mess they've created."
• Incremental improvement
  Koden är obegriplig, svårföränderlig, otestbar o.s.v. Vad gör du? "Admit you have a mess and clean it up! Bit by bit, day by day, slowly clean it up." Gör det till en regel att alltid checka in lite bättre kod än du checkade ut. Vi gör ofta tvärtom - det är inte professionellt.
• No grand redesigns
  Ledningen är aldrig intresserade av detta. "But then the developers begin to bang the drums... And management resigns. Enter the Tiger Team!" De bästa utvecklarna bildar toppteamet som ska bygga det nya fantastiska systemet. "Det gamla systemet" är specifikationen, så hur svårt kan det vara? Samtidigt sitter andra utvecklare kvar och förvaltar och vidareutvecklar systemet i drift. Det blir som Zenons paradox: hur fort Aristoteles än springer måste han alltid först ta sig dit sköldpaddan började med sitt försprång, men då har sköldpaddan hunnit ytterligare en bit och så vidare i all oändlighet...
• Progressive widening
  Pragmatic Programmers kallar det tracing bullets, i XP kallar man det spikes: lägg till en liten feature som går hela vägen uppifrån GUI ned till databasen och fortsätt därifrån. "Add a thin slice, widen it progressively."
• Progressive deepening
  Få den tunna skivan att fungera ett lager i taget. "Make it run, make it work, make it fast."
• Don't write bad code
  Varför skriver man dålig kod? "Vi hade inte tid att skriva bra kod" är ett vanligt svar. Men har man i så fall verkligen tid att hantera konsekvenserna av dålig kod i form av fler defekter, svårare underhåll och så vidare? "Bad code is not something that slows someone else down months from now - it slows you down immediately!" Vad är det vi producerar, vad är vår artefakt? Ett systems beteende? Nej, det är koden som är vår produkt. "If the code is a mess, the product is a mess. Bad code stays forever, dragging the team down, eventually dragging the company down."
• Go fast, go well
  "The only way to go fast is to go well."
• Clean code
  "What is clean code? It is when the code reads in such a way that, as you read it, each line is what you expect it to be."
• Test-Driven Development
  "The jury was out on this one, but now they have come back and it is a best practice." När Bob Martin frågade publiken om de ägnade sig åt testdriven utveckling räcktes ett anmärkningsvärt stort antal händer upp. "All the time?" Något färre händer. Robert Martin använder puristens definition av TDD:
  1. Ingen produktionskod får skrivas innan du har ett test som misslyckas.
  2. Du måste sluta skriva enhetstest när det misslyckas och skriva produktionskod så att det lyckas.
  3. Du får inte skriva mer produktionskod än vad som behövs för att få testet att lyckas.
  Något färre händer kvar efter denna definition.
  Att bedriva TDD på detta vis tvingar oss att ha exekverbar kod hela tiden. "What makes code flexible? The effects of architecture and design are secondary. Tests are what makes code flexible and maintainable."
• QA Should Find Nothing
  Det är i alla fall den inställningen vi bör ha när vi kodar.
• 100% Code Coverage
  Använd ett verktyg som t.ex. NCover för att se till att din code coverage är i närheten av 100% (i närheten räcker eftersom de flesta verktyg aldrig når 100% eftersom de inte räknar in interface).
• Avoid debugging
  Titta på koden och hitta buggen där - koden fungerade ju för två minuter sedan (se TDD ovan).
• Manual Test Scripts Are Immoral
  "Tryck på den knappen, skriv in det och det i inmatningsfälten, kontrollera att resultatet blir XYZ..." Om och om igen. "Could you imagine doing that for a job?! It's immoral!" Låt testarna fokusera på kreativa, utforskande tester.
• Definition of done
  "What is the definition of done? All tests are passing."
• Test through the right interface
  Testa inte via ett grafisk gränssnitt. Om det inte är det grafiska gränssnittet som ska testas och då ska affärslogiken simuleras/stubbas.
• Apprenticeship
  Det bästa sättet att lära sig är att sitta med erfarna utvecklare vecka ut och vecka in. Parprogrammera.
• Use good tools
  Det finns mängder av verktyg där ute, de bästa är ofta Open Source. Varför? "They put care into code."

Ovanstående är hämtat från mina egna minnesanteckningar så vissa citat kanske inte är helt korrekta och möjligen har jag missat ett par punkter. Många av dessa punkter, ja förmodligen alla, är i någon variant kända för de flesta som intresserat sig för agila metoder de senaste åren. Och vissa av de Java-människor jag pratade med tyckte inte det var något att höja på ögonbrynen åt. Kanske beror det på min annorlunda bakgrund (.NET, icke-agila projekt), men jag tycker det var fantastiskt inspirerande att höra en prominent person som Bob Martin med självklarhet, glöd och passion konstatera att "så här är det, så här ska man arbeta - låt ingen intala dig motsatsen". Jag hoppas verkligen att min inspiration ska smitta av sig på andra i de projekt och sammanhang jag deltar i och att jag får tillfälle och möjlighet att tillämpa dessa goda riktlinjer i mitt yrkesutövande. Nu har jag i alla fall ett grönt band som påminner mig. :-)