Test-drevet utvikling er en hellig gral innen smidig utvikling og ofte hører man uttrykk som "TDD fører til bra design", "med TDD trenger man ikke tenke på arkitektur" og "TDD er meningen med livet" (okei, det siste der fant jeg muligens på selv). Men vil TDD automatisk føre til bra design? Eller er det noe de ikke har fortalt deg?
3. Red
GreenRefactor
TDD
1. Skriv test
2. Sjekk at testen feiler
3. Implementer
4. Sjekk at alle tester er OK
6. Sjekk at alle
tester er OK
5. Forbedring
KJETIL KLAUSSEN 3
32. "You can't do good design
without experience.
When less experienced people
do TDD they typically don't
refactor enough, leading to sub-
optimal designs"
- Martin Fowler
KJETIL KLAUSSEN 32
For de som ennå ikke har fått med seg hva TDD er – og det bør ikke være noen i dette rommet her – så tar vi en rask intro
TDD handler om å skrive en test for en funksjonalitet man ønsker, sjekke at testen feiler, implementer funksjonalitetet og sjekke at testen går gjennom. Man implementerer så lite som overhodet mulig for å få testen til å passere og når man er i grønn sone så tar man seg tid til å forbedre koden gjennom refaktorering. Når man er fornøyd sjekker man at alt fortsatt fungerer og skriver neste test.
Så vil TDD føre til bedre design? Håndsopprekking?
For de som vil bevare spenningen til slutt; vennligst lukk øyne og øre
Nei, TDD vil ikke gi deg et bedre design. Kanskje et litt annet design, men ikke nødvendigvis et bra design
Det første vi må spørre oss om da er; bedre enn hva?
Bedre enn vannfall?
Jeg har sett mange som mener at TDD er bedre enn vannfall, men vi må huske at TDD primært er en arbeidsflyt - ikke en prosess-metodikk
Da er det mer naturlig å sammenligne med denne arbeidsflyten. Og ja; jeg vil påstå at TDD er en bedre arbeidsflyt er dette.
Så hvis du vil endre ratioen til fordel for koding, så vil jeg absolutt anbefale TDD. Personlig synes jeg koding er langt morsommere enn debugging, så av den grunnen alene ville heller valgt TDD. Men hverken TDD eller Debug-driven development sier noe om design…
Spørsmålet vi trenger å stille oss er; hva er bra design?
Er dette et bra design?
Eller dette?
Dette?
Uansett om det handler om visuelt design…
… eller underliggende struktur og arkitektur, så må man vi vite hvilke design-muligheter man har og velge det som man tror passer best for den løsningen man bygger. Det å designe et system for hinsides skalerbarhet når systemet skal brukes av 14 brukere er et like dårlig valg som å designe et system uten skalerbarhet hvor man har millioner av brukere. Man må vite hva bra design er i den konteksten man er. Hvis ikke….
Hvis ikke ender man opp med dette.
… eller dette
… eller dette
… eller dette
TDD er ingen magisk trylledrikk.
Det å kunne trylle fram et godt design – om man bruker TDD eller ikke – handler om hardt arbeid. Kanskje ikke fysisk, men det krever mye innsats og det krever at du kjære seer prioriterer tid til å lære hva bra design i kontekst av software-utvikling er.
I vårt fagfelt er det primært 2 kilder til godt design: Prinsipper…
… og mønster – eller patterns på nynorsk.
Her er det 18 prinsipper listet opp. Hvor mange kan minst 3 av dem? Og med kan mener at hvis jeg spør deg så kan du forklare meg hva f.eks. Single Reponsibility Principle er.
Mer enn 5? 10? Alle 18?
Og 26 av de mest populære design patterns. Hvem kan 5 eller flere? 10? Alle 26?
Dette er verktøyene våre!
Dersom du ikke har tenkt å være en ufaglært grov-snekker resten av livet, så må du utvide verktøykassa di. Du må lære disse – og vite hvilke fordeler og ulemper de har, og i hvilken kontekst det ene eller andre prinsippet eller patternet bør velges.
Hvis alt du har er en hammer… Ja, okei – noen klarer seg kanskje godt med bare en hammer
…men for alle oss andre så er det viktig å kunne velge riktig verktøy til oppgaven
Som Martin Fowler sier det; Man kan ikke lage et godt design uten erfaring. Og det å lære prinsipper og patterns handler om å bygge erfaring. En vanlig nybegynner-feil i TDD er at man ikke refaktorerer nok, hvilket igjen fører til sub-optimalt design. Fowler er flink til å velge ord. Hadde de ordene kommet fra meg hadde nok ‘sub-optimalt’ vært byttet ut med ‘røtent’.
Refaktorerings-fasen i TDD er helt essensiell – og kanskje den viktigste fasen. Og for å kunne utnytte den fasen må man vite hvordan man refaktorerer og hva man skal refaktorere til
Så er det slik at man kan putte TDD inn i ene enden og så ramler det vakkert design og englemusikk ut i den andre enden?
Det er ikke TDD i seg selv som skaper designet – det er personen i andre enden av tastaturet som gjør det. Det finnes ikke det verktøy eller den metodikk i verden som automagisk kan gi deg det. Det er fortatt vi som utviklere som må tenke selv. Det er ikke antall kodelinjer pr time vi betales for – det er for å trøkke inn de riktige kodelinjene.
Og da er det prinsipper…
Og patterns som gjelder. Lær dem. Lær så mange du klarer. Og enda litt fler.
Har du det på plass, så vil TDD være til veldig stor nytte
