Ville du ha brukt notepad til å skrive kode ?
Selvsagt (forhåpentligvis) ikke. Vi bruker IDE til programmering fordi det gir en sikrere og raskere prosess. Moderne IDE-er inneholder et arsenal av verktøy. En av disse er code templates. Jeg skal her gå igjennom hvordan man kan bruke de innebygde code templatene eller endre disse slik at de passer perfekt. Man kan også lage nye selv. Jeg vil her bruke Eclipse og Java som et eksempel. Code templates finnes derimot i flere IDE-er (som for eksempel InteliJ og Netbeans) og kan også benyttes på samme måte i andre programeringsspråk enn java.

Bruk de innebygde code templatene

Eclipse kommer med mange innebygde templates. Disse listes opp under Preferences-Java-Editor-Templates. For å aktivere templaten i koden trykker du “Ctrl-Space-Space”.

Skal du opprette en junit-test (og det gjør du vel en del ganger?) finnes det en template for å dette. Denne ser slik ut:

Her lages det en metode annotert med test. org.junit.Assert importeres statisk. Og cursoren settes inne i metoden. Det opprettes også en variabel (testname). Dette gjør at brukeren skriver rett etter genereringen fylles inn der.

Det er fullt mulig å editere på templatene hvis de ikke passer helt. Dersom man for eksempel bruker fest assert så trenger man ikke statisk import av org.junit.Assert. Det er bare å slette den delen.

Ta deg tid til å ta en titt på de innebygde templatene. Det er antgelig flere ting du gjør ofte som det finnes templates som gjør denne jobben lettere.

Lag dine egne templates

Man kan også lage sine egne templates. Her skal vi ta for oss to eksempler.

Template for equals metode

Vi skal her se på en template for en eguals metode (Jada, det finnes mange andre måter for å enkelt lage en equalsmetode, men dette er et eksempel)

Minst 99% av alle equalsmetoder starter med å sjekke at objektet er av riktig type. Siden klassenavnet varierer fra klasse til klasse (duh), bruker vi en variabel “enclosing_type”. Denne erstates med navnet på klassen vi er i. I tillegg caster vi deretter objektet til den aktuelle typen. Det er i tillegg lagt på en nullsafe equalsmetode som kan brukes til å sjekke de aktuelle atributtene. Vi har også tatt med en gyldig (men ikke veldig bra) implementasjon av hashCode slik at man oppfyller kontrakten mellom equals og hashcode.

Template for å generere en factory metode

Mange ganger er det nyttig å opprette en klasse med en statisk metode. Følgende template hjelper deg på vei her :

Som vi ser brukes det mye av de samme teknikkene som i equals templaten. Det som er nytt er bruken av variable. Variable er felt som brukeren kan editere på umiddelbart etter å ha kjørt templaten. Her bruker vi dette til å redigere på variabelnavnet (som jo varierer mye fra klasse til klasse). Feltnavnet brukeren skriver inn oppdateres tre steder:

1. I feltnavnet
2. I parameteren til metoden
3. I tilordningen på begge sider av likhetstegnet.

Disse templatene er bare eksempeler. I et hvert domene finnes det noe som gjøres mange ganger og er nesten likt. Tenk deg om. Antagelig finnes det noe code templates kan hjelpe deg med. Hvis du vil kopiere noen av templatene fra eksemplene finner du dem og noen til her.

Systemutviklere er både heldige og uheldige. Vi kan tilegne oss kunnskap og ferdigheter helt på eget initiativ, men vi tvinges også til å gjøre det for å holde oss relevante, ettersom teknologi endrer seg raskt.

Selv synes jeg at det er topp å plukke opp nye ting – her er noen metoder for å lære…

Bredde eller dybde?

Tenk på kunnskap som personøkonomi. Ikke invester alt i en aksje (“Jeg kan bare Java!”). Spre eggene dine over flere kurver. For all del: legg ned tid i mainstream-teknologi som er populær idag. C# og Java f.eks er lavrisiko med grei avkastning. Men se også på nisje-teknologi (la oss si F# eller Scala, for eksempel) Disse er mer høyrisiko fordi det absolutt ikke er sikkert de blir populære i fremtiden. Smale temaer gir til gjengjeld langt høyere avkastning hvis de slår an: du får et fortrinn fordi du var tidlig ute.

Balanse mellom generelle og spesialiserte emner. Brede, eviggrønne felt (f.eks OO-design, regular expressions, statistikk) hjelper deg i mange år, uavhengig av domener og platformer. Men ikke overse domenekunnskap og platformspesifikke verktøy (Oracle og Microsoft) som gjør deg mer ettertraktet i prosjekter her og nå.

Kultiver personlige styrker. Hvis du bare kan “litt om alt” så er det vanskelig å utmerke seg. Finn en eller to ting som er dine hovedpillarer, som du stadig forbedrer og behersker bedre enn andre. Hva gjør at du skiller deg ut? Hva er ditt “Unique Selling Point”?

Studieteknikk-kungfu

Du har et enormt arsenal av studieteknikker. Min erfaring: jeg lærer meg ting langt mer effektivt nå enn da jeg var i skoleverket eller på universitetet. Dels fordi jeg har blitt flinkere til å lære, men mest fordi vi har fått flere måter å tilegne oss kunnskap. Her er en liten godtepose av muligheter:

• Universiteter verden over legger ut åpen “courseware”: videoforelesninger, notater, pensum, oppgaver, fritt tilgjengelig på nett.
• Screencasts er en fin blanding av foredrag og praktiske demonstrasjoner. Noen av dem må du betale for. De er derfor ofte optimalisert for å levere lærdom og verdi, mer enn en umotivert foreleser på Blindern noengang blir…
• “So You’d Like To…”-guidene hos Amazon.com er i noen tilfeller knallbra utvalg av faglitteratur og fungerer bra som utgangspunkt for selvstudium.
• Online nyhetsblogger og foredrag fra konferanser gjør deg oppdatert på tilstanden i fagfeltet ditt.
• Podcasts og lydbøker gjør iPoden din til en forelesningssal – kanskje mens du tar oppvasken?
• Møt andre engasjerte i meetups, brukergrupper, code camps og online studiegrupper. Få feedback fra likesinnede, ikke gjem deg bort!
• Open source lar deg kikke bak kulissene og se hvordan andre utviklere jobber og tenker.
• Mindmapping er en sterk måte å ta gode, raske notater mens du studerer.

Og dette var bare en tilfeldig utvalg. Med andre ord: dersom du begrenser deg til å kun lese en papirbok i ny og ne så handicapper du deg selv. Du har mange muligheter!

Absorber som en svamp. Hvis jeg har en ekstrem “læredag” så hører jeg på en podcast når jeg går til stasjonen på morran, leser litt i en relatert bok mens jeg sitter på toget, plugger inn iPoden igjen når jeg bytter over til tbanen til jobben, samme opplegg på veien hjem på ettermiddagen, og setter meg ned og koder en prototyp etter at ungene har lagt seg. Teknikkene nevnt i forrige avsnitt gjør det stadig enklere å presse inn læring flere steder i hverdagen enn man kunne før.

Jevn progresjon. Store skippertak kan fungere, men det er i lengden bedre å lære litt hver dag istedet. Når man er student så fungerer sånne “overdoser” til en viss grad, men det blir vanskeligere når du har jobb og familie. Tenk bærekraftig tempo…

Bruk det du lærer

Jobb med relevante prosjekter i arbeidstida. Dette er idealsituasjonen, men lar seg ikke alltid gjøre. Prosjekter krever vanligvis at vi leverer det vi allerede behersker, ikke det vi ønsker å lære mer om. Derfor kan det bli nødvendig å…

Lage ting på fritida. Bruk det du har lært til å gjøre sideprosjekter på egenhånd. Ambisjon og omfang trenger ikke være all verden, bare du lager noe konkret og nyttig. Du kan lage et verktøy eller en tjeneste som bare du selv trenger, eller slippe det som open source eller en kommersiell tjeneste for hele verden. Poenget er at du anvender kunnskapen til noe konstruktivt. Det kan være slitsomt å bruke fritida til dette – til gjengjeld eier du selv det du lager. Og du får en “portfolio” å vise til.

Lær det bort til andre! Når du formidler til andre (f.eks via kurs, blogging, foredrag) så tvinges du selv til å få bedre grep på stoffet ditt. Du trenger ikke være guru for å lære bort ting – det holder at du har noenlunde grep om temaet og evner å formidle det godt.

Robert “Uncle Bob” Martin sa på et av foredragene sine at en profesjonell utvikler må bruke tjue timer hver uke på å forbedre seg som håndtverker. Dette er kanskje ekstremt – men hvor mye gjør du selv? Og hvordan lærer du nye ting? Del gjerne av egen erfaring i kommentarene under!

Bedre kommunikasjon

• Inkluder produkteier på morgenmøtene: Daglig kommunikasjon mellom kunde og leverandør har en dokumentert enorm effekt på hvor vellykket et prosjekt blir. Teamets fokus blir mye bedre dersom det er noen på de daglige standup møtene som er interessert i å prøve ut det som har blitt laget i går, som er interessert i å komme med innspill på det som lages i dag og som har myndighet til svare på avklaringer angående dagens oppgaver.
• Programmér sammen: Utviklere på prosjekter innehar enorm kunnskap, både om de delene av systemet man lager og om programmering generelt. Når man programmerer i par og roterer hvem som jobber sammen hyppig, blir denne kunnskapen spredt til alle. Spe også gjerne på med seanser der hele teamet går gjennom deler av koden på storskjerm.
• Bruk en Scrum-tavle: For å hjelpe alle å huske på hva som er målet med sprinten, er det lurt om teamet holder standup møtene rundt en tavle med lapper for alle aktiviteter teamet har planlagt i iterasjonen. Lappene henger i kolonner “venter”, “under arbeid” og “ferdig”. Hver lapp bør ha et så lite omfang at teamet flytter flere lapper til “ferdig” hver dag.

Bedre kvalitet

• Verifiser krav med funksjonelle tester: Når teamet skal jobbe med en oppgave i en iterasjon, er det viktig at alle har konkret forståelse av oppgaven. Produkteier bør beskrive eksempler for å gjøre oppgavene konkrete. Om mulig, bør produkteier uttrykke eksemplene i et verktøy for automatisert funksjonell testing (for eksempel FitNesse eller Cucumber). Teamet kan da kjøre testene og automatisk sjekke at de oppfyller produkteiers forventning
• Skriv enhetstester før koden den tester: For å kunne utvikle funksjonalitet inkrementelt, må man kunne endre på kode som allerede har vært ferdigstilt, samtidig som man er (rimelig) sikker på at endringen ikke ødelegger noe som har virket før. De funksjonelle testene kan gi et sikkerhetsnett, men det tar typisk lang tid å kjøre dem og de gir ofte ikke en eksakt indikasjon av hva som er feil når noe ikke virker. Derfor bør teamet skrive raske tester som verifiser at klassene i systemet fungerer, gjerne før man skriver koden.
• Integrer endringer kontinuerlig og automatisk: Automatiske tester er kun verdifulle dersom de kjøres! Sett derfor opp en Continuous Integration server som sjekker ut og tester alle endringer hver gang en utvikler har sjekket inn en endring til kildekodekontroll. Om mulig bør dette systemet også automatisk installere den siste versjonen av programvaren til et egnet testmiljø, slik at produkteier alltid kan se hva som er siste versjon av systemet.

Bedre forretningsfokus

• Inkluder alle oppgaver i en prioritert produktkø: Mange team lurer på hvilke oppgaver som skal puttes på produktkøen. Dersom noe gir forretningsverdi og tar betydelig tid å utføre, bør produkteier inkludere oppgaven på produktkøen. Ikke-funksjonelle krav må som regel testes. Det tar tid å sette opp testene og rette opp eventuelle mangler. Ikke-funksjonelle krav skal på produktkøen. Brukerdokumentasjon må skrives og kvalitetsikres. Det tar tid å skrive god brukerdokumentasjon. Brukerdokumentasjon skal på produktkøen.
• Bli helt ferdig med funksjonalitet: Teamet får kun “poeng” for helt dønn ferdig utført arbeid. Etter en iterasjon bør alt som tilhører en oppgave være så ferdig at det er greit dersom man aldri mer bruker tid på koden. Koden, tester og dokumentasjon må være i en akseptabel tilstand. Det betyr ikke at koden er frosset. Dersom man for eksempel utfører en oppgave for å verifisere responstid, må teamet oppdatere eksisterende kode slik at den støtter tidsmålinger og at man korrigerer eventuelle ytelsesproblemer man oppdager. Dette arbeidet tilhører det å implementere responstidskravet – den originale funksjonen er ferdig.
• Ta med brukere på demo: Dersom du lager et system som interesserer dine (fremtidige) brukere, bør teamet ha noe spennende å vise dem på demo etter hver iterasjon. Bruk demo-møtet til å involvere brukerne. Sørg for at input fra brukerne blir tatt hensyn til, og at de får beskjed om innspill som har blitt implementert, slik at de fortsetter å interessere seg.

Gjort riktig kan et smidig prosjekt levere ferdig funksjonalitet for hver iterasjon. Men det krever fortløpende kommunikasjon, kvalitet og fokus på forretningsverdi. Dét er hvordan du lykkes med smidige prosjekter.

Jeg planlegger å publisere en Steria 3-minuttersguide basert på denne artikkelen. Innspill til forbedringer mottas med stor takk!

Noen av oss kjører strikt, metodisk testdrevet utvikling. Andre bruker bare automatiserte tester nå og da som sikkerhetsnett for å unngå regress-feil. Hvor ofte fyrer du selv av testene dine? Kjører du testsuiten din en gang i ny og ne, eller strikt for hver metode du implementerer?

Jeg liker å kjøre testene mine ofte mens jeg arbeider. Det jeg liker enda bedre er å la utviklingsmiljøet mitt kjøre dem for meg, automatisk. Poenget med yrket vårt er jo nettopp å automatisere og effektivisere arbeidsprosesser – dette forsøker jeg å gjøre også med mine egne rutiner og verktøy. La oss se hvordan vi kan få til dette.

Mange av oss bruker allerede Continuous Integration for å oppdage feil i den felles kodebasen. Personlig autotesting er det neste, logiske steget: enhetstestene våre burde kjøre i bakgrunnen hver gang vi endrer noe, og gi oss umiddelbar tilbakemelding når vi knekker funksjonalitet. På denne måten oppdager vi våre egne feil før resten av teamet blir påvirket av dem.

Det finnes flere verktøy som gjør dette for deg:

• Infinitest (Java)
• Autotest / ZenTest (Ruby)
• Nosyd (Python)

Det er imidlertid ikke vanskelig å lage et enkelt autotest-verktøy på egen hånd. Jeg synes at det er en god ide å bruke litt tid her og der på å forbedre sitt eget utviklingsmiljø. Vi har jo muligheten til å lage våre egne verktøy (smeden er en av få håndverkere som kan si det samme). Som utvikler bør man iallfall klare å slipe sine egne kniver, for å si det sånn. Og dette er en god anledning!

Et naivt script for autotesting implementerer du på en ettermiddag. Alt du trenger er et lite program som reagerer på endringer i prosjektfilene dine, og kjører testene etter behov.

Algoritmen er enkel: La scriptet kjøre regelmessig, f.eks hvert sekund. Kontroller “forrige endring”-klokkeslettet for alle filene i prosjektet. Dersom klokkeslettet på en eller flere filer har endret seg siden forrige kontroll, så kjør enhetstestene til prosjektet. Analyser output fra testkjøringen, og se hvorvidt noen tester feilet eller kode knakk helt (exceptions). Gi så klar tilbakemelding om testene er ok eller feilet.

Tilbakemeldingen kan være litt grafikk og lyd på desktopen (for eksempel med Growl eller Snarl), en lavalampe på pulten, blinkende LED-lamper på laptopen… vær kreativ! Bare sørg for er at du får en tydelig tilbakemelding på hvorvidt testene feiler eller ikke.

Filmklippet under viser hvordan mitt eget autotest-miljø fungerer. Koden er i dette tilfellet skrevet i et språk som heter Clojure og ser derfor kanskje litt pussig ut, men ikke heng deg opp i det: det som demonstreres er at jeg knekker og fikser tester, og får automatisk godt synlig feedback på dette underveis.

Ikke spesielt komplisert.

“Dette ser jo genialt ut! Hvorfor bruker ikke alle autotest-verktøy allerede?”

Vel, det finnes dessverre noen utfordringer.

Dersom autotesting skal fungere hensiktsmessig må testsuiten som kjøres kun bestå av raske enhetstester, ikke tunge integrasjonstester. Og enhetstestene må gå kjapt! En test-run må ta sekunder, ikke minutter, ellers mister du gevinsten ved den umiddelbare feedbacken.

Problemet med trege tester er betydelig. Det finnes workarounds: man kan analysere avhengigheter mellom tester og kode, kun kjøre de berørte testene, kjøre raske tester først, feilende tester først, nylig feilende tester først… Men mange av oss har dessverre erfart at det er vanskelig å få til et godt fungerende opplegg for dette i et vanlig moderat stort utviklingsprosjekt.

Så er ikke autotesting nyttig likevel, da? Jo! Autotesting fungerer knallbra i små prosjekter (som ikke har samlet på seg så mye kode ennå) og egenopplæring (når du lærer nye verktøy og språk og ønsker å ta små steg med kjapp feedback). Det kan kanskje også fungere i større prosjekter dersom du har muligheten til å segmentere koden og testene dine i mindre moduler på en hensiktsmessig måte.

I bunnen av denne artikkelen har jeg vedlagt et eksempel på hvordan et enkelt autotest-script kan se ut, implementert i Ruby. Scriptet er skrevet for OS X-miljø, men koden bør være relativt lesbar og enkel å porte til ditt eget favorittspråk og utviklingsmiljø.

Happy testing!

Eksempel:

# Command line command which launches all unit tests
RUN_TESTS_CMD = "mvn clean test"

# Pick up any changes in files matching this filepath
FILES_TO_MONITOR = "**/*.java"

# Determine test outcome by scraping test output for #telltale signs of failure or exceptions

def test_failed?(test_output)
  return (test_output["FAIL in"] != nil) # Any 'FAIL in' strings in test result indicates failure
end

def exception_occurred?(test_output)
  return (test_output["EXCEPTION in"] != nil)
end

# Indicate test state by turning the background color of the test terminal
# a different color - yellow red og green. Currently uses Mac AppleScripts, but could be
# an audible signal, lava lamp, or anything else instead.

def indicate_tests_running
  `osascript bin/autotest/make-term-yellow`
  puts "\n\n\n----------------------------------"
  puts "TESTRUN STARTED #{Time.now}"
  puts "----------------------------------\n\n\n"
end  

def indicate_test_success(description)
  `osascript bin/autotest/make-term-green`
  puts description
end  

def indicate_test_errors(description)
  `osascript bin/autotest/make-term-red`
  puts description
end  

$monitored_files = {} # Stores the last changed time of each file    

def files_changed? # Check if any files have been touched/saved since last check
  file_changed = false;  

  Dir[FILES_TO_MONITOR].each do |filepath|
    if(!File.new(filepath).ctime.eql?($monitored_files[filepath]))
      file_changed = true;
      $monitored_files[filepath] = File.new(filepath).ctime
    end
  end  

  return file_changed
end  

def run_test
  indicate_tests_running
  result = `#{RUN_TESTS_CMD}`  #Run the tests, pipe resulting console output back
  display_results(result)
end    

def display_results(testOutput)
  if test_failed?(testOutput)
    indicate_test_errors("SOME TEST(S) FAILED\n"+testOutput)
  elsif exception_occurred?(testOutput)
    indicate_test_errors("EXCEPTIONS OCCURRED\n"+testOutput)
  else
    indicate_test_success("ALL TESTS SUCCEED\n"+testOutput)
  end
end  

def test_loop
  while true
    if files_changed?
      run_test
    end
    sleep(1) #seconds between each poll for file changes
  end
end  

test_loop # Start testing!

• Bug rapport: “Administrative kostnader” skal fjernes: Når vi beregner totalkostnaden til et veiprosjekt, inkluderer vi kostnaden av nyanlegg, ombygging, bruer og administrative kostnader. Når vi demonstrerte applikasjonen til brukerne våre, husket de plutselig at administrative kostnader er sjelden i bruk og burde egentlig fjernes fra applikasjonen. Endringen var enkel og det er usannsynlig at en bedre analyse på forhånd hadde kommet fram til samme konklusjon. Dette er den type feilrapport vi liker å få.
• Bug rapport: Ikke-effektuerte utbetalinger skal telle mot totalt tilgjengelige midler: Når vi sjekket om det var tilstrekkelige midler for å utføre en utbetaling, glemte vi å ta med de utbetalingene som var registrert, men ikke utført enda. Tilstandsovergangen av utbetalinger fra registrert til godkjent til utført var litt mer kompleks enn vi hadde forventet, og enhetstestene sjekket ikke tilstrekkelig med varianter. Vi burde ha funnet denne feilen med enhetstestene våre, men dersom vi aldri får feil av denne typen, kan det være en indikasjon på at vi er for nøye med testingen vår. Så feilen er helt grei. Spesielt ettersom konsekvensene for brukeren ikke var spesielt store
• Bug rapport: Perioder som starter i desember rapporterer IllegalArgumentException: Når vi beregnet neste måned, glemte vi å ta hensyn til at du kan ikke bare legge til én på månedsnummer. Neste måned etter desember er ikke måned 13! Dette var en slurvete feil og jeg tror den ble introdusert en gang når vi ikke parprogrammerte (fordi koden var så triviell, liksom!). Brukerne våre forstår at slike type feil kan skje, men vi må se nøyere på prosessen vår for å unngå slike feil i fremtiden.
• Bug rapport: Layout ser rotete ut i Internet Explorer: For å unngå noen tekniske problemer når vi skrev enhetstester for HTML’en vi produserte, fjernet vi midlertidig doctype-definisjonen fra webside-malene våre. Så glemte vi å putte definisjonen inn igjen (jada, et nytt eksempel der vi ikke parprogrammerte). Sidene så fortsatt fine ut i Chrome og Firefox, som utviklerne brukte for manuell verifisering. Men i Internet Explorer så websidene direkte kaotiske ut. Den tekniske konsekvensen av feilen var triviell, men feilen kunne lett ha vært unngått, dersom vi vi hadde testet med samme nettleser som brukerne våre. Noen av brukerne våre fikk dette håpløse førsteinntrykket av applikasjonen mens de hjalp oss å teste. Det var skikkelig flaut. Dette vil vi ikke at skjer igjen!

Det er litt vanskelig å definere hvilke bugs som gjør meg mest flau. Noen viktige faktorer er hvor vanskelig ville det vært for oss å unngå feilen og hvor stor konsekvens feilen har. Men andre faktorer påvirker også hvordan vi oppfatter en bug. Av feilene på lista over, så er den jeg er mest flau over kun en kosmetisk feil. Men siden dette var noen brukeres førsteinntrykk av applikasjonen, var det mye mer problematisk enn de særtilfellene vi ikke helt støttet.

Hva synes du gjør en feil mer eller mindre akseptabel?

Språket blir dessverre behandlet som den stygge andungen av mange utviklere fordi det tradisjonelt oppleves som knotete, skjørt og lite vedlikeholdbart. Slik trenger det ikke være!

Vi i Steria har utviklet et gratis, nedlastbart kurs som oppdaterer deg på dette området. Denne workshopen introduserer ferdighetene, teknikkene og verktøyene som gjør JavaScript-utvikling langt mer overkommelig enn tidligere. Alt materiale i kurset er fritt tilgjengelig til din egen bruk.

Du kan bruke foilene, forelesningsnotatene og øvelsene som personlig studiemateriell. Du kan også holde kurset som en formell workshop sammen med kollegaer eller kunder. Workshopen tar omtrent en halv dag (3-4 timer) når det gjøres skikkelig – beregn halvannen time forelesning, minst halvannen time praktiske øvelser.

LAST NED HER

(Inneholder slides, forelesningsnotater, øvelser, løsninger, eksempler, verktøy. Utgitt under en Creative Commons Attribution 3.0 lisens. Du kan bruke, endre og dele det fritt, så lenge du krediterer opphavsmannen.)

Hvis du ikke har kapasitet til å kjøre kurset selv kan du ta kontakt med Steria; vi kan holde kurset i dine lokaler, i og rundt Oslo.

La oss avslutte med en smakebit. Filmklippet under illustrerer et av temaene som workshopen tar for seg, nemlig testdrevet utvikling i JavaScript. Enjoy!

Uten mer om og men, poster jeg en video her av hvordan jeg liker å jobbe med tester for å drive fram “kravene” til en applikasjon og refactoring for å forme designet til applikasjonen. Se spesielt rundt 11:30 minutter inn i videoen hvor jeg refactorer inn et regelmotordesign i en fungerende løsning.

Oppgaven kalles “Fizz buzz kataen”. Den går ut på å generere en sekvens av nummer der hvert tall som er delelig på 3 erstattes med “fizz” og alle tall som er delelig på 5 erstattes med “buzz”. Så starten blir “1, 2, fizz, 4, buzz, fizz, 7, 8, fizz, buzz, 11, etc.” Seks minutter inn i kataen endres kravet (og musikken!): Nå skal man kunne programmere inn hvilke erstatningsregler som gjelder. Som eksempel bruker jeg at “tall delelig med 2 skal erstattes med ‘coconut’ og tall delelig med 7 skal erstattes med ‘banana’”.

Takk til Emily Bache for inspirasjon til oppgaven.

Fizz buzz code kata av Johannes Brodwall på Vimeo.

Jeg bruker IntelliJ IDEA Community Edition på Windows Vista (!) til å løse oppgaven. Videoen er filmet med BB FlashBack Express (som er gratis), konvertert til AVI med Windows Media 1 codec og lastet opp til Vimeo.

Denne blogposten var originalt publisert på engelsk på min personlige blog.