CEnhet

Jag ville använda unit-tester till ett Cocoa-projekt.

Dum som jag är så gjorde jag ett nytt försök med OCUnit, vilket jag skrivit om tidigare. Jag vet inte varför jag ens brydde mig. Det suger inte bara för att Steve Jobs har bestämt att man ska använda det på ett idiotiskt sätt, utan även för att det saknar dokumentation, saknar ett uppenbart sätt att köra sina unit-tester programmatiskt och presenterar sina resultat på ett dåligt sätt.

Nästa steg var att testa med Google C++ Testing Framework, som vi kör på jobbet. Det funkar ganska exakt som man vill att det ska göra, letar automatiskt upp ens testfall, kör dem och ger vettig output. Google Test är dock C++, och även om det går bra att blanda C och C++ så ska man tydligen inte försöka blanda C, C++ och Objective-C. Nitlott igen.

Samtidigt som Björn Skifs och Arne Hegerfors hoppade fram och vrålade "TREDJE GÅNGEN GILLT" i örat på mig (det piper fortfarande), så drog jag ner CUnit. Jag säger som Neal: "Aaaaah..." Det är lite mer jobb än med Google Test, eftersom C inte har RTTI, så man får snällt registrera sina testfall, men det som är trevligt med CUnit är att det går att använda på ett vettigt sätt. Och med lite snabbt hopkokad hjälpkod så är den extra ansträngningen för att registrera testsviter och testfall minimal.

CUnit får 3 sälar på den grönländska betygsskalan.

Skriv om, skriv rätt!

Jag har hållit på och läst "Working Effectively with Legacy Code" av Martin C. Feathers ett tag, och blev klar med den igår. Den tog inte tid för att den var tråkig, utan för att jag ville smälta delarna ordentlig. (Jag väljer att inte ta matsmältnings-metaforen vidare, det skulle bli obehagligt.)

Det är en bok som alla programmerare borde läsa, åtminstone de som inte kör test-driven utveckling av trivsel och ohejdad vana. Den här boken visar inte bara med väldigt konkreta exempel hur man inkrementellt förbättrar rutten kod, utan illustrerar även väldigt tydligt varför unit-tester är ett måste.

Författaren har uppenbarligen högt ställda krav. Han definierar legacy code som kod som saknar testfall. Det kan låta lite hårt, men han visar varför det är vettigt.

Om du någonsin har blivit irriterad på svårförståelig kod och det har känts jobbigt att fixa den, läs den här boken!

Da Scrumci-koden

Sedan urminnes tider har taskigt skrivna arkeologer spelade av Tom Hanks sökt den heliga graalen inom agile development-arkeologin: svaret på gåtan varför Scrum har trängt undan Extreme Programming. Givetvis handlar det om trender hitan och ditan, att IDG inte kan skriva om mer än tre saker i taget, men jag har under mystiska seanser fört samtal med andar, besökt idévärlden och ritat sanningstabeller och nått ett svar på gåtan.

Scrum är helt enkelt enklare att bända in i ett företag, eftersom det ser så harmlöst ut för de som bestämmer, d.v.s. de som har slips på sig och tänker med plånboken. "Visst, sure, ni utvecklare kan ju köra era iterationer och ha lite möten, det påverkar ju inte mig." Extreme Programming har inte bara ett lite läskigt namn (som dock kan låta lite hippt och edgy, vilket också har sina fördelar), utan ser ut budget-perspektiv livsfarligt ut. Par-programmeringen drar enligt enkel matematik ner produktiviteten till hälften, och kör man test-driven utveckling så lägger man lika mycket tid på att skriva testfall som att utveckla kod, vilket halverar produktiviteten en gång till.

Inget sådant i Scrum! Scrum ställer inga sådana krav på vad utvecklarna ska göra (parprogrammering och test-driven utveckling är dessutom bara en liten del av Extreme Programming, där finns en del som kan få slipsen att hicka till). Dessutom är det lätt att fuska med Scrum: finns det ingen på plats som förstår vad det handlar om så kan man lätt hoppa över retrospectives, reviews och till och med scrum, fippla med sprint-backloggen under pågående sprint, strunta i att ha produktägare eller scrum master, ha chefer som projektleder så att gruppen inte kan organisera sig själv etc.

Risken är dessutom stor att motståndet ökar om man inte kan få igenom förståelse för fördelarna med lättrörliga processer, vilket tvingar fram kompromisser. Grunden i Agile och Lean är att man förändrar saker som inte funkar som de borde. Förändring möter alltid motstånd. Motståndet kan leda till att Scrum-processen kvävs. Men man kan i alla fall skriva på företagets webbsida att man kör Scrum och att man har certifierat folk, så låter det som att man fattar vad som pågår.

De gamla rävarna som var med under den grå forntiden, för sådär 10 år sedan, får något nästan religiöst i blicken när de berättar om hur bra allt var när man körde Extreme Programming. Och jag tror att det finns goda anledningar till det: Scrum verkar enklare och möter mindre motstånd, men är svårare att lyckas med.

Följer man reglerna för Extreme Programming så får man mycket mer hjälp med det dagliga arbetet. Det går naturligtvis att kombinera Scrum och Extreme Programming, men det är inte så vanligt som det borde vara.

Sen kan man inte skylla allt på cheferna heller. Väldigt många utvecklare känner antingen inte till eller är skeptiska till refactoring, testdriven utveckling och parprogrammering. Men även om UML-nördarna kan dra sitt strå till stacken för att skjuta ner Extreme Programming så är jag övertygad om att det är Scrums falska smidighet som gör det så populärt.