I dessa agila tider sker allt mer utvecklingsarbete vid tangentbordet, men är det verkligen bra? Ställ er vid tavlan och rita pilar och bubblor innan ni knackar kod! Fast man kan inte göra som vi gjorde förr, BDUF är fortfarande dött.
Även om man parprogrammerar och kan diskutera fram kod och design och även om man nu för tiden inte fokuserar på att skriva dokument som ingen ändå kommer att läsa, får man inte glömma bort att göra design och arkitektur innan man sätter sig ner och implementerar. Så lyft på rumpan då och då och rita på tavlan. Hans Brattberg brukar hävda att ingen form av kommunikation är så effektiv som två personer framför en tavla.
Vid tavlan gör man både arkitektur och design. Eftersom vi jobbar agilt har vi alltså inte alla bitar på plats från start – inte ens arkitekturen – och därför behöver man komplettera (och refaktorera) även denna varje gång man lägger till nya funktioner av dignitet i systemet. En refaktorering av ett hörn i arkitekturen kan få stora konsekvenser i koden och just därför vill man stämma av den ofta. Annars riskerar man att åka på Big Bang.
Till hörnstenarna i systemkonstruktionen hör även domänmodellen. Inte heller här kan vi kosta på oss att göra den i förväg, utan den växer fram gradvis sprint för sprint. En av effekterna av att jobba agilt som jag märkt för egen del är att domänmodellen kan bli så mycket bättre, eftersom man putsar på den hela tiden och de nya objekt man lägger till är de som man precis skall till att använda i sin design och implementation.
Det här leder förstås till frekventa refaktoreringar av modellen och har man den persistent i en databas innebär det även frekventa uppdateringar av schemat. En del kanske backar inför detta, men det finns tekniker för att hantera detta som gör databasuppgraderingarna hanterbara eller rent av lätta. Kanske ännu ett ämne för ett framtida blogginlägg…
Det viktiga är att för det första ser till att ha en arkitektur och en domänmodell och för det andra inte låter någon av dem vara huggna i sten. Därför måste man se över och bättra på dem varje gång man tillför ny (vertikal) funktionalitet i systemet och detta kan man inte göra vid tangentbordet. Bästa sättet är att rita upp sin design på tavlan och se om den, arkitekturen och domänmodellen håller.
När man sedan sätter sig för att koda kanske man rent av börjar med en smärre refaktorering för att "kratta" för sin nya fuktionalitet.
Väl talat. Håller med helt.
I början finns så många oklarheter och frågetecken och då kan jag tycka att objekt och pilar på papper eller tavla,
gör att man snabbare konkretiserar frågor och angreppssättet.
Dessutom, om man själv anser att det man gör är tillräckligt viktigt för lite eftertanke och rump lyft – vilket det ju är,
så inser oftast de runt omkring en oxå att det man gör är viktigt. Det kan underlätta mycket.