Lyntalen “Agile sier du? frAgile sier jeg” jeg holdt på Smidig 2008 er en del av ønskereprisene fra konferansen på XP Meetup den 17. November. Dette er en ypperlig anledning til å få med seg det beste av det du ikke fikk sett under konferransen eller for deg som ikke kom deg dit er det en anledning til å se hva du gikk glipp av.

Detaljene om hvordan du kan delta finner du på Oslo XP November Meetup. Vi ses!

Oppdatering: Presentasjonen min fra møtet ligger nå ute, sammen med alle de andre presentasjonene, så du kan se dem dersom du lurer på hva jeg snakket om.

Dette var første gang jeg var på XP Meetup i Oslo og jeg må si det ga mer smak. Utrolig mange folk, veldig bra foredrag og ikke minst gode diskusjoner etter foredragene. Hvis du ikke var der så burde du angre, for dette er et community som er av de beste på planeten når det gjelder smidige metoder.

Jeg har vokst opp på en gård i fjellbygda Folldal og er dermed veldig mottagelig for analogier og eksempler som tar utgangspunkt i gårdsdrift. Overraskelsen min var stor da jeg leste en artikkel av XP-guru Kent Beck som nettopp bruker bøndenes metode for å dyrke åkeren for å vise hvordan man kan gjøre det samme i applikasjons design.

Artikkelen First One, Then Many tar for seg et klassisk dilemma innen systemutvikling. Du skal lage et system som skal håndtere en transaksjon i første omgang, men man antar at det vil måtte håndtere mer enn en senere.  Klassisk systemutviklings litteratur sier da at du må ta høyde for dette i ditt design. Kent forklarer i sin artikkel hvorfor dette ikke er en god ide og han bruker bonden som utgangspunkt.

Bønder dyrker ikke åkeren sin for at den skal være komplett fra dag en, han dyrker den for at den skal være perfekt når det er tid for innhøsting. Derfor bruker bonden ikke bare en sort frø, han bruker gjerne flere sorter frø for å oppnå best resultat. Bonden bruker en frø type som gror raskt for å stabilisere jordsmonnet i tillegg til den egentlige sorten frø som gror litt saktere. På denne måten sørger han for at åkeren over tid blir utnyttet optimalt.

Jeg er veldig enig i Kent sin måte å tilnærme seg applikasjons design. Gjennom å gjøre “smarte” antagelser og å “ta høyde for” ting så skaper man problemer for den som kommer senere. Det er langt bedre å ha en kodebase som reflekterer det som systemet faktisk gjøre, enn en kodebase som inneholder halvveis implementert funksjonalitet. I Lean Software Development kalles dette søppel (eller waste (eller ennå mer trendy kalles det muda)). Søppel har en tendens til å skape ubehag dersom det opptrer i større mengder og blir liggende over tid. Derfor er jeg helt enig med Kent sine tanker om å la kodebasen reflektere hvordan virkeligheten faktisk er. Det gjør det enklere å både vedlikeholde og videreutvikle en løsning.

Hvis du tenker på Kent sin artikkel neste gang du sitter å forsøker være kreativ når du spesifiserer et grensesnitt så vil du, kunden og systemet nok takke deg til slutt.

Flex har virkelig begynt å få fotfeste i Norge det siste året. Dette merker man i jobbannonser hvor det stadig oftere er nevnet Flex kompetanse og man merker det med antallet hendvendelser som kommer angående hjelp til å begynne med Flex.

Å starte med Flex er ikke noe stort problem og de fleste utviklere klarer veldig lett å komme igang med å lage applikasjoner. Tilsvarende lett er det å gå i en del fallgruver og gjøre en del feil. Jeg har arbeidet med Flex en stund og har dermed også vært nedi de fleste fallgruvene. Derfor tenkte jeg å dele noen av mine beste tips og triks som jeg har lært meg til å bruke for å ennå raskere levere Flex applikasjoner.

• Ha alltid en modell i bunnen også når du lager mockups og prototyper.
• Data Driven Application Design: sørg for at det alltid er dataene som driver applikasjonen din ved hjelp av data binding
• Les dokumentasjonen om klassen Binding Utils og sørg for å laste ned koden til Observere og ObervereValue.
• Logging: lag deg en logger som gjør det mulig for andre brukere og sende deg logg når det oppstår feil situasjoner. Et slikt eksempel er en logger som bruke Firebug.
• Evolutionary Application Architecture: ikke bygge rammeverk og komponenter i tilfelle du trenger de. Flex rammeverket gjør det veldig enkelt å gradvis bygge ut en prototype til en ferdig applikasjon. Lag for eksempel aldri en gjenbrukbar komponent før du faktisk skal bruke den for andre gang.

Mange av disse tingene vil du kanskje si at er vanlige regler for god systemutvikling, og det er selvsagt helt riktig. Likevel er det viktig å påpeke at disse tingene selvsagt også gjelder når man jobber med Flex. Det er veldig lett å tro at fordi det er en ny teknologi så gjør man ting anderledes. Å følge prinsippene i objekt orientert programmering (OOP) gjør det enklere å utvikler og vedlikeholde Flex applikasjoner også.

Test drevet Flex utvikling

Mange spør meg om hvordan kan man drive testdervet utvikling når man jobber med Flex. Svaret ligger i tipsene ovenfor, nemlig å ha en data drevet applikasjon hvor hendelser i grensesnittet gjøres gjennom å manipulere en modell klasse. Hvis du gjør dette gjennom å implementere presentation model mønsteret vil du merke at å jobbe test drevet ikke er noe problem i Flex.

Gjennom å ha en modell klasse som brukes til å manipulere data (og dermed også grensesnittet) kan du veldig enkelt skrive enhetstester for modell klassen. Dermed får du dokumentert oppførselen i applikasjonen gjennom testene samtidig som kvaliteten på koden din øker. Min gode venn Børre Wessel har holdt en presentasjon på Scotch On The Rock hvor han snakker om hvordan du implementerer presentation model mønsteret i Action Script.
Anbefalt lesning om testing av grensesnitt er artikkelserien til Adobe Consulting’s Paul Williams som tar for seg en lang rekke mønster som gjør testing av Flex applikasjoner enklere.

Per Otto Bergum Christensen har laget et meget spennende åpen kildekode verktøy, BDoc, som jeg har veldig tro på kan bli veldig nyttig fremover. Jeg så lyntalen om BDoc på Smidig 2008 og det gjorde meg enda mer nyskjerrig på hvordan BDoc kunne hjelpe meg.
BDoc hjelper utvikler team til å holde bruker historier (eller user stories på norsk) synkronisert med test koden på en bedre måte enn tidligere. BDoc genrerer rapporter på et naturlig språk utifra testkoden til utviklerne. Dette gjør at hvem som helst kan lese hvilke krav som er implementert av utvikleren. Rapportene er lenket opp mot bruker historier og dette gjør at man unngår det klassiske problemet med at disse to viktige delene ikke stemmer over ens og at man bruker mye tid på å samkjøre disse.

BDoc er i første versjon og det er et par åpenbare ting som vil gjøre det enda bedre, likevel er fordelene såpass store slik at det er bare å begynne bruke det umiddelbart også eventuelt bidra selv med kode til å tilpasse BDoc slikat det passer dine behov. Jeg kunne blant annet tenkt meg muligheten til å referere til bruker historiene med en link, slik at man kan ha disse i en Wiki eller lignende. Da kan man bruke mange ulike link sjekk programmer til å unngå døde linker og slike ting.

BDoc har begynt å få en del oppmerksomhet i utvikler kretser og denne uken ble det publisert en artikkel på The Server Side som gir en grundig innføring i BDoc og hvordan det fungerer.

Den absolutt beste konferansen for smidige metoder, Smidig 2008, går av stabelen 9. – 10. oktober i Oslo. Her vil du ha anledning til å dele erfaringer med de absolutt beste og mest erfarne menneskene i Norge når det gjelder smidige metoder.

Jeg skal holde en lyntale som heter Agile sier du? Fragile sier jeg hvor jeg vil belyse det faktum at de aller fleste som heveder de benytter smidige metoder faktisk ikke gjør det fullt ut og dermed ender med en slags mellomløsning som tar det værste fra smidige metoder og kombinerer det med det værste fra tradisjonelle metoder.

Hvis du ikke har registrert deg til Smidig 2008 ennå så gå inn å gjør det nå!