iterationer ligger fokus ofta på standupmöten, retrospektiv, planning poker, burndowns och sprintplanering. Däremot finns det ofta litet intresse för hur vi gör med vår kod för att den ska stödja korta iterationer och kontinuerlig leverans. I Scrum (och andra liknande agila ramverk) har vi lärt oss att arbeta tillsammans i team, prata ofta med kunder och ha korta iterationer så att vi kan ändra oss vad det är vi ska göra härnäst. Skitbra! Det vi glömmer bort är att bygga mjukvaran på ett sådant sätt att vi på ett enkelt sätt kan genomföra dessa förändringar.
sekund 1-4 veckor: “vanlig” scrum 2 ggr/dag: Facebook Var 11,6:e sekund: Amazon (Maj 2011, i snitt) ! Ju oftare vi levererar, desto jobbigare blir det att göra saker manuellt. Vi snackar sådana saker som automatisk verifiering av funktionalitet, modulär arkitektur (så att ändringar på ett ställe inte slår på ett annat), en design som gör att vi kan resonera med varandra om koden. Dessutom pratar vi så klart om automationsgrad på våra leveransprocesser.
till i början av min karriär Problem i produktutvecklingen. Många buggar - ofta kom de tillbaks. Dålig design (läs: långa metoder och stora klasser). Stress. Det gick t.o.m. så långt att ett tag gick till jobbet med ont i magen. Jag kände att det här inte var en situation jag skulle sätta mig i någonsin igen. Change agent: kollega som hade jobbat med TDD tidigare. Han visade och pratade om hur man gjorde, jag började leka med automatiska tester på kammaren. Jag insåg att jag behövde (och kunde få) hjälp med att få koden att hålla en hög kvalitet.
ett bråttom-projekt, en web-produkt. Av olika anledningar var vi sena. Diskussion om hur vi ville göra för att leverera tidigare. Vi jobbade redan övertid men hann inte leverera det vi skulle när vi skulle det. Beslut: vi skulle ta in fler utvecklare.
it later” ! (Brooks’s Law) “Alla” vet att projektet blir senare när fler utvecklare kommer in i projektet (alltså Brooks’s law). Det är dock inte 100% säkert att så alltid är fallet - ‘According to Brooks himself, the law is an "outrageous oversimplification”’ (källa: wikipedia-artikeln om Brooks’s law) Enligt Brooks: 2 faktorer som spelar roll här: ökad kommunikations-overhead och tid för den nya utvecklaren att komma in i projektet (“ramp up time”).
! Bild? Commits i core direkt! https://secure.flickr.com/photos/bryceworld/ 5094749137/in/pool-basejump Första veckan gjorde den nya utvecklaren commits i core-funktionalitet. Dessutom i en av de delar som var “värst”. Varför? Vi kom fram till följande i retrospektiv: * Det fanns tester som ett skyddsnät. * Testerna som fanns dokumenterade hur saker och ting skulle funka * (Sen var hon förbannat duktig också, men det är ju en förutsättning när du tar in en ny person i ett team - men hur man tar in folk i projekt är inte i scopet för detta seminarium. (Hint: intervjua med programmering, även om du tar in en konsult.))
dig när du hoppar i en trapets, vågar du hoppa både högre och längre, helt enkelt ta större risker. Samma sak i mjukvaruutveckling - vi vågar göra större förändringar om utvecklaren innan oss har “låst fast” sin funktionalitet och specat hur hen ville att modulen skulle fungera.
dina enheter bildar de en (exekverbar) specifikation för de enheterna. De är alltid uppdaterade, eftersom de körs i den kontinuerliga integrationen vid varje push.
var rörig, och i en monolit. Dessutom hade “många kockar” hade rört i kodbasen, med resultat bl.a. duplicerad funktionalitet, många buggar, specialisering inom teamen (endast kalle kan användarmodulen etc)
ledd av mig + kollega. Vårt mål: minska dupliceringen + förbättra designen - se till att saker återanvändes inom produkten. Samtidigt: stöd utvecklingen med TDD Men: lösningarna klart annorlunda mellan vårt och det andra kontoret: Det andra hade krångligare och större testmetoder, större setup etc (vi hade små enheter och många små test) Alltså: tekniskt sett “sämre” tester och kod hos det andra teamet.
kunde de på vårt kontor hela tiden fråga oss hur man skulle tänka och göra, vilket gjorde det mycket lättare för de andra utvecklarna att komma in i tankesättet. Detta liknar ett forskningsprojekt: implementera ungefär samma typ av funktionalitet - ett team har möjligheten att fråga någon som kan och ett team som måste maila/skype:a. De på andra teamet hade mycket svårare att få in tankesättet, vilket gjorde att resultatet blev (för) stora klasser och därmed jobbiga tester. Alltså: TDD på rätt sätt är svårt - erfarenhet krävs i teamet när man sätter igång. Annars är det lätt att åka i diket.
Stora tester, stor setup (6-8 parametrar per konstruktor) Dessutom - många mocks Svårt att förändra vid nya/förändrade krav Jag tappade lite tron på att TDD funkar väl.
är W. Edwards Deming Bra TDD != (enbart) regressionstester! Regressionstester = självvaliderande system Kvalitet = 0 defekter eller enkelt (och bulletproof) att ändra? Men: mer än bara regressionstester krävs! Alltså: tänk på (och förbättra) design! Dock är alltid målet en nollvision - vi vill inte ha några buggar. Uppkommer en bugg, skriver vi ett test och kör vidare!
min kod! Det som hade hänt var att jag hade missat att köra Refactor-steget i red-green-refactor. Min design var inte så bra som den borde varit. “Om något är svårt att testa - fundera på att ändra din design” Vid refactor-steget så försöker man se till att man får bort “smells”, alltså stora klasser, långa metoder etc. Det leder till enklare design och dessutom lättare testsetup. !
inga direkta resurser förutom vi) Sökmotor för läkemedelstillgänglighet - tänk pricerunner, fast sökning efter var ett receptbelagt läkemedel finns, istället för lägsta pris. Vår lösning körde på Vårdapotekets site.
systemet parsade ut grunddata ur en XML-fil Utvecklingen skedde med dummy-data (en delmängd av den riktiga datan) Vid första körningen av riktig data kraschade det pga slut på minne (vilket var ganska sent pga svårigheter att få tag på den riktiga filen) Så jag var tvungen att byta XML-parser, från att suga in hela dokumentet i minne till en SAX-parser (som hanterar nod för nod)
modul som resten av systemet berodde på kunde det bytas ut ganska enkelt. TDD är väldigt mycket en design-aktivitet. Eftersom parsern var en separat modul (med sina egna tester) var det enkelt att byta parsnings-strategi.
utveckling med intresserade! Jag har just startat upp en community på Google Plus (som heter “Testdriven utveckling”). Gruppen är gratis och öppen, gå med! ! (Varför Google Plus? Helt enkelt för att det funkar bättre för sådana här nördiga prylar än Facebook. (Och på LinkedIn:s grupper flyger det mest virtuell tumbleweed.)
rollbear
sylph01
moro
yukiny
o0h
akase244
yutobara
drumath2237
marcoroth
deka_morita
koic
takai
62gerente
sstephenson
destraynor
keavy
charlesmeaden
akosma
skipperchong
sarafernandez
cassininazir
minecr
aleyda
codingconduct
