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.

Ofte er det slik at du og kunden hadde forskjellig forståelse av hva som skulle lages. Denne forståelsen var sannsynligvis ganske identisk i begynnelsen, men manglende kommunikasjon underveis førte til antakelser som viste seg å være feil.

Kunden: “Hvordan går det?”
Du: “Det går kjempe bra! Er allerede i Sandefjord!”
Kunden: “Hva mener du med at du er i Sandefjord??”

Du satte deg i bilen din og kjørte til Kristiansand, mens kunden står og venter i Kristiansund. Hvorfor står dere på hver deres side av landet? Det som tilsynelatende var krystallklart for både deg og kunden i begynnelsen, resulterte i en skivebom av dimensjoner (ca 887 km). Hadde dere hatt en dialog underveis, ville dere mest sannsynlig kunne oppklart misforståelsen på et tidligere tidspunkt.

Selv om dette eksemplet kan virke banalt, så illustrerer det noe veldig viktig. Dersom man ikke får kontinuerlig feedback på det man driver på med, kan man fort ende opp med å kjøre i feil retning.

Veien til suksess handler om kommunikasjon med kunden. Kontinuerlig feedback sikrer at dere har felles forståelse for hvor dere skal. Det beste hadde selvfølgelig vært å ha kunden med i passasjersetet hele veien. Dette er ikke alltid mulig, men vi har noen gode erfaringer med hvordan man kan oppnå lignende nivå av kommunikasjon likevel.

Fem gode tips for å sikre at brukerhistorien blir levert som kunden forventer

1. Bruk et felles språk som både kunde og utviklere forstår.
Utviklere generelt har en tendens til å bruke veldig mye tekniske uttrykk og forkortelser. Dette er et språk kunden ikke forstår og finner frustrerende. Få vil innrømme at de ikke forstår meningen av redsel for å fremstå som mindre smarte. Språk av slik art kan også fort bli tatt for god fisk, fordi det høres “fancy” ut og kan fort føre til misforståelser. Lytt til hvordan kunden beskriver og referer til ting og forsøk å tilpasse deg språket deres. I denne sammenheng er det alltid utviklerene som må tilpasse seg domenespråket til kunden, og ikke motsatt. Likevel er det vikitig å introdusere kunden for nye konsepter som for eksempel en “hendelse”, uten å beskrive dette på et teknisk nivå. Språket er noe som du utvikler sammen med kunden over tid. Sørg for å danne basisen for dette språket allerede fra starten av prosjektet.

2. Start arbeidet ditt sammen med kunden før du begynner å skrive en eneste linje med kode.
Med dette oppnår du flere ting. For det første må du sette deg inn i problemstillingen for å i det hele tatt kunne føre en fornuftig dialog med kunden. Allerede nå får du bedre forståelse av hva som skal lages, både fordi du har tenkt over det på egenhånd, og du kanskje får svar på flere sentrale spørsmål gjennom dialog med kunden før du starter. For det andre så involverer du kunden fra starten av. Kunden vil føle det betryggende at han er involvert i prosessen. De er da i mye bedre stand til å gi deg løpende tilbakemeldinger.

3. Lag et førsteutkast med akseptansekriterier
Akseptansekriteriene definerer hva som skal til for at brukerhistorien er ferdigutviklet. Dette bør være skrevet på det felles språket som dere sammen har kommet frem til. Kriteriene bør kun inneholde den funksjonaliteten som er innenfor denne brukerhistorien. Ikke inkluder kriterier for eksisterende funksjonalitet eller funksjonalitet som er utenfor scope.

En idé kan være å formulere akseptansekriteriene dine på dette formatet:
Gitt at jeg har kr 100,-på visakortet mitt
Når jeg kjøper en øl til kr 60,- med visakortet mitt
Så skal jeg ha kr 40,- igjen på visakortet

Dette er et format fra Behavior driven development (BDD)-evangelistene som vi ikke kommer til å gå nærmere inn på i denne artikkelen.

Utviklere jobber best med konkrete eksempler, dette krever at du er presis. Når du utarbeider førsteutkastet med akseptansekriterier kommer det fort opp nye problemstillinger som man først ser når man graver seg dypere ned i detaljene. Utkastet er et godt utgangspunkt for videre diskusjon med kunden. Gjennom akseptansekriteriene dine skinner det igjennom hvordan du har oppfattet kundens behov.

4. Kall inn kunden til et møte, med utgangspunkt i førsteutkastet av akseptansekriteriene.
Selv om du forhåpentligvis har hatt kontinuerlig kommunikasjon med kunden underveis, så blir et slikt møte en “reality check”. I dette møtet vil du få kjapp tilbakemelding på hvordan “din verden” stemmer overens med “kundens verden”. Du har allerede nå satt deg godt inn i problemstillingen, og har noe konkret å diskutere med kunden. Dette gjør deg i stand til å diskutere utfordringer som er på et mer detaljert nivå enn tidligere. Kunden vil som oftest stille spørsmål rundt flere av formuleringene i akseptansekriteriene dine. Slike spørsmål tyder på at du har uttrykt noe uklart, som ofte kan føre til misforståelser. Da er det helt nødvendig å stoppe opp, tenke seg om , og omformulere. Grav deg ned i hva uklarheten dreier seg om, og omformuler akseptansekriteriet sammen. På denne måten sikrer du at kunden får det han ber om, og du får en bedre forståelse av hva som skal lages og hvilken verdi dette gir til kunden.

5. Ha en kontinuerlig feedback-loop med kunden.
Utviklerene har nå noe konkret å ta tak i. Det er fortsatt en del ting som ikke er avklart, men hovedessensen er på plass. Det dukker alltid opp nye problemstillinger etter at utviklingen har startet. Avklaringsprosessen er noe som går igjennom hele utviklingsløpet til brukerhistorien, men du har nå et godt grunnlag for å håndtere nye utfordringer som måtte oppstå. Du har dannet kommunikasjonskanalen, kunden er involvert fra starten av, og utviklerene har et klart definert sett av kriterier som de kan forholde seg til.

For å si det kort; involvér kunden så tidlig som mulig, kommunisér på et språk som dere har blitt enige om, og sørg for å få kontinuerlig feedback. Da vil man unngå mange unødvendige misforståelser og dere vil begge føle et felles eierskap til det som skal leveres. En bonuseffekt er at man kan etterprøve akseptansekriteriene når brukerhistorien er levert. Dette er mye enklere å gjøre ettersom kriteriene er noe dere har blitt enige om sammen, helt fra starten.

Dette er noen av våre erfaringer fra et av Norges største smidige prosjekter.
Hva er dine erfaringer?

Øyvind Norstein Øvregård
Finn-Robert Kristensen

Nå skal det selvsagt sies at man helst bør følge de maler og bruke de rammeverk som arkitekten eller teamet sammen har tenkt at prosjektet skal bruke.  Sånn sett finnes det regler for hva som er rett og galt.  Men når det finnes slike maler og rammeverk, da stiller vi oss ikke dette spørsmålet. Det er når vi beveger oss utenfor de etablerte malene at spørsmålet gjerne dukker opp: Er dette riktig? Og det er litt trist når det skjer. For det er tegn på at vi ikke stoler på oss selv til å kunne komme med gode nok løsninger. Og det synes jeg vi skal gjøre. Det har vi all grunn til å gjøre, flinke som vi er

Vi bør absolutt fortsette med å stille spørsmål om hvorvidt koden vår kan forbedres. Men spørsmålet bør heller være “Hva synes du?” Vi bør fortsette med å involvere flest mulig. Men det bør gjøres som en diskusjon blant proffesjonelle utviklere der alle har gode poenger å komme med, og ingen sitter med fasiten. Det er da det er morro å jobbe som et team.

Programmering burde ikke bare oppleves som å fargelegge inni ferdig-opptegnede figurer. Det burde være litt frihånds-arbeide også. Det er når du føler at du er med på å skape løsningen at det er gøy å programmere. Og det er når man har det gøy at man jobber best og utvikler seg mest.

En code kata er en enkel øvelse for å skjerpe programmeringsferdighetene dine. Det vil si – du trener bare problemløsning den første gangen du utfører øvelsen. Så gjentar du øvelsen, om og om igjen, til det sitter i fingerspissene. Og hver gang prøver du å gjøre det litt kjappere. Hensikten er å trene hastighet, teknikk og verktøy.

I klippet under lager jeg en variant av Minesweeper kataen i JavaScript.

(Kjør den i fullscreen for å se koden mer tydelig)

Merk: Jeg bruker testdrevet utvikling gjennom det meste av prosessen. På slutten dropper jeg TDD når jeg gjør det visuelle og selve spillmekanikken. Dette kunne også testes fra kode, men jeg droppet det for å gjøre den mer artig å se på.

Du kan se på koden i github-kontoen min. Hver commit er en separat gjennomkjøring av øvelsen fra scratch.

Jeg brukte følgende libraries og verktøy:

• Underscore.js
• jQuery
• Grid.js
• clAutotest
• TextMate

Et scriptspråk kan være et kraftig verktøy for å konfigurere java-applikasjonen din. Det tillater endringer på en kjørende applikasjon. Det gir deg frihet til å endre på kjørende javakode som du velger å eksponere. Det er kjent og kjær teknologi og derfor enklere å få tak i ansatte med riktig kompetanse enn om du velger mindre kjente teknologier. Og kanskje det viktigst av alt, et argument som burde veie tyngre enn det ofte gjør i avgjørelser; det er enkelt.

Min spontane reaksjon på forslaget var “er du gal!”. Målet var å kunne endre regler for automatisk saksbehandling mens systemet kjørte. Ideen var å eksponere disse reglene via jRuby. Min kollega, Trond Pedersen, som hadde kommet med forslaget lo litt og viftet det vekk som et forslag fremmet bare for å vise at det er lov å tenke kreativt. Jeg lot ideen ligge resten av dagen. Først da jeg kom hjem lot jeg den få en rettferdig sjanse. Den var egentlig ganske tiltalende. Dersom vi valgte å gjøre konfigurasjon via filer som inneholdt tekst og verdier ville vi kunne slå av og på regler og sende inn verdier til reglene. Men hva om vi eksponerte et java-API via et scriptspråk istedet? Det åpner for å endre på hva man måtte ønske å eksponere. “Tør vi det” tenkte jeg.

Jeg bestemte meg for å se nærmere på ideen. Før jeg forelår noe sånt vil jeg gjerne se hvordan vi kan løse det i praksis tenkte jeg. 30 minutter med litt leiting på verdensveven og litt lek og moro i eclipse hadde jeg et kjørende eksempel med en java-applikasjon som eksekverte jruby-kode. Et javaobjekt ble sendt som parameter til jrubyscriptet. Scriptet kalte metoder på javaobjektet og returnerte en verdi tilbake til java-applikasjonen. Det finnes masse eksempler om man leter litt på verdensveven men for at du skal slippe å lete så viser jeg mitt her.

Først litt javakode:

import java.io.File;
import java.io.FileReader;
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;

public class RunRuby {

public static void main(String[] args) throws Exception {

  ScriptEngineManager factory = new ScriptEngineManager();
  // Create a JRuby engine.
  ScriptEngine engine = factory.getEngineByName("ruby");

  // Evaluate JRuby code.
  engine.eval(new FileReader(new File("src/rubyscript.rb")));
  engine.put("object", new Object());

  // Run the ruby-method reverseToString
  String value = (String) engine.eval("reverseToString($object)");

  //java.lang.Object@something is printed backwards
  System.out.println(value);
  }
}

Javakoden tolker en scriptfil, rubyscript.rb, og kjører metoden evaluate. Se eksempelkoden til rubyscript.rb:

require 'java'
def reverseToString(javaObject)

  # returns the reverse of the objects tostring method
  return javaObject.toString().reverse()

end

Når passer det å bruke dette vektøyet til konfigurasjon? Når du vil gjøre endringer uten å måtte kompilere en ny applikasjon og starte den opp i produksjonsmiljøet ditt. Er det enkelt å forutse disse endringene kan du trolig like gjerne gjøre det i en tekstfil med forhåndsdefinerte verdier som leses inn av applikasjonen din. Når du derimot synes det er vanskelig å forutse hvilke endringer du har lyst til å gjøre har du nå et kraftig verktøy. Bruk et scriptspråk. Velg gjerne ditt eget favorittscriptspråk. Om det er jRuby, JavaScript, Scala, Clojure eller et annet scriptspråk er opp til deg. Finn din favoritt som er kjørbar på JVM og du er igang på 1-2-3.

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!

I den intensive godkjenningsperioden vi har vært gjennom, ble rollen ”Loggvakt” opprettet. Rollen har holdt løpende oppsyn med serverlogger, gjort logganalyse og ytt bistand til Delprosjekt Test for preanalyse av feil som rapporteres. Bemanning av rollen har gått på rundgang i prosjektet.

Intet kunne ha gledet meg mer! Jeg selv var så heldig å få sitte loggvakt ”hjemme hos” Delprosjekt Test – og det to dager på rad attpåtil! Og det var da refleksjonene kom… Vi tar’n like godt på engelsk

During test intensive periods – engage your project members on “log surveillance duty”!

The person on duty has the chance of becoming a real detective! He or she should tail essential server logs continuously, analyse them and initiate proper action when e.g. specific stacktraces, log statements, log sequences or log-patterns appear. The log surveillance duty role should also take part in early analysis of important bug reports so that they can be handed over to relevant teams as fast as possible.

Using the log surveillance duty as one of several “bug hunt approaches”, the project may experience that bugs are caught earlier. In addition, without the log surveillance duty role, some of these bugs would not have been reported at all. You’ll see the effect of this during free testing in particular.

Imagine this “happy day situation” in your project:

“ALERT – we have a situation! Log statement GOOD_STUFF in the jBoss log”!

“Ta-ta-raaaa! Who did a search for GOOD_STUFF just a couple of minutes ago and got an error message? Ah-so you were the one! Grrrreat! Oh.. so – you’re – used to ignoring this error message- are you – ok…Please tell us when such messages appear, will you? It’s of great value! But now … What was your scenario again? And the five steps preceeding your scenario? Can you rerun it, please…..? Thanks! …..Bingoooo!! The GOOD_STUFF_BUG has been reproduced, it has been trapped! Juppie!! My hero tester! Could you report that bug for me, please?”

When assigning resources to the log surveillance duty role, people with different interests, orientations and skills should be motivated to take part! Experience the incredible opportunities just waiting to be used – to increase the over time quality of the system being built!

• One day – call a JEE architect, a senior developer for duty -
• The day after that – a user scenario oriented person –
• The next day a developer with DB-expertise -
• A junior developer –
• A technically oriented senior tester -
• And then a “usability minded” one –

Keep on rolling – keep on changing – keep on building system quality mind set – keep on spreading system understanding – keep on….

Don’t wait! Just do it! Market the log surveillance duty role and motivate your project members to take part! Prepare yourself to be called!

… I’ll bet you’ll take on new habits after you organized your first round – or the first time you participated – I’m sure!

So, get on with it! Good luck! 

P.S:

Hvis du har lest min blogg fra 04/10/2010 og du allerede er på god vei til å bli en Buglock Holmes i prosjektet ditt, ser du nok at på loggvakta får du brukt alt det du har blitt vant til å gjøre som Buglock!

D.S.

• Ha en grov oversikt over områder de ulike teamene i prosjektet jobber med…
• Kjenn rimelig godt til hva produktkøen for prosjektleveransen inneholder…
• Vit hva teamet ditt og hva andre team i prosjektet har levert …
• Husk at det er nyttig å ha god oversikt over hvilke deler av produktkøen som ikke inngår i leveransen …
• Sørg for at ørene dine vokser seg store og sterke! Vær nysgjerrig! Snus rundt!
• Prøv å snappe opp ting som foregår hos naboteamet, ved kaffeautomaten…
• Hold øye med serverloggene i integrasjonstestmiljøet for prosjektet…
• Hold en rimelig god og helst løpende oversikt over hvilke feil som meldes inn i feilrapporteringssystemet i testintensive perioder …
• Lær deg å huske nøkkelord og nøkkelsituasjoner, designdiskusjoner ved tavla og møter eller samtaler der viktige forståelser eller avklaringer ble skapt…
• Husk situasjoner der folk var svært uenige om deler av løsningen…
• Lær deg å huske situasjoner der man faktisk kom til enighet…
• Bli pådriver for at viktige avklaringer og omforente tolkninger styres inn i klare krav, testbetingelser, skjermskisser, flytskjemaer, figurer etc. …
• Bli pådriver for at de klare kravene etc. forstås på samme måte – spesielt av de som var uenige / ikke forstod hverandre…
• Innse selv og hjelp ulike interessenter til å forstå at ikke alle uenigheter kan forenes…
• Erkjenn at uansett hvor godt vi dokumenterer avklaringer, kan vi forvente at der ulike interessenter var uenige, vil diskusjoner dukke opp igjen senere i prosjektets liv, f.eks. når systemet leveres til test eller til produksjon…

Tren deg noen av disse teknikkene! Da vil du etter hvert bygge en god oversikt over hele systemet dere leverer! Du kan ta aktive grep i forhold til vanskelige feilfloker og du vil forstå hvordan de ulike feilene/manglene henger sammen med hverandre.

Lykke til, Buglock!

Jeg har fått dilla på dynamiske programmeringsspråk (JavaScript, Ruby, Lisp, med flere) i det siste. Et av fellestrekkene ved slike språk er at de lar deg programmere interaktivt. Vet du ikke hva interaktiv programmering er? Flott, da har du kommet til riktig artikkel!

Ideen bak er ganske enkel, men jeg tror det er enklere å vise hva det er først, istedet for å skrive masse forklarende tekst. Her er et eksempel, demonstrert med IRB (Interactive Ruby):

Hva skjer her?

Vel, jeg skriver ekstremt grunnleggende Ruby-kode. Men se hva som skjer underveis. Hver Ruby-setning jeg skriver inn blir evaluert og kjørt av systemet. Resultatet spyttes tilbake på kommandolinja. Systemet husker hva jeg gjør. Jeg definerer variabler og funksjoner. Jeg kan bruke og bygge videre på dem, og jeg får umiddelbar feedback på alt jeg gjør. Og jeg slipper å kompilere eller restarte koden min hver gang jeg prøver noe nytt.

Den vanlige prosessen vår for systemutvikling er som et stålverk. Vi lager en støpeform (skriver kode i en IDE). Så støper vi en klump stål (kompilering/restart). Dersom stålklumpen ikke har riktig form, så er det tilbake til tegnebordet for å justere støpeformen. Denne feedback-løkka er mye raskere enn før takket være raskere kompilering, bedre maskiner og enhetstesting – men vi kaster likevel bort en del tid når vi løper frem og tilbake på denne måten.

Interaktiv programmering derimot er mer som å jobbe med leire. Vi arbeider med samme stykke materiale kontinuerlig. Vi klatter på litt kode, ser hvordan det ser ut. Tar vekk ting, bytter ut, former, eksperimenterer.

Dette er ikke en erstatning for hvordan vi vanligvis arbeider, men mer et nyttig tilbehør. Du bygger ikke en produksjonsbil med leire, men det er mye lettere å lage f.eks en design-prototype med leire enn med stål. På samme måte kan interaktiv programmering være et bra hjelpemiddel og supplement for seriøs systemutvikling.

Helt konkret: hvorfor er interaktiv programmering nyttig?

• Du arbeider raskere, fordi feedback-løkka er kortere.
• Du slipper unna med mindre kode, fordi du bruker mindre tid på å bygge infrastruktur og “boilerplate”.

Mer komplisert er det ikke. Jeg mistenker imidlertid at det ene bruksområdet ovenfor ikke overbeviser helt. Jeg skal derfor vise flere eksempler, og du kan tenke over hvordan disse teknikkene passer inn i din egen verktøykasse.

Jeg bruker jevnlig interaktiv programmering til følgende:

• Utforsking og læring
• Grensesnitt mot backend-system
• Frontend-utvikling og prototyping

Utforsking og læring har vi allerede sett via IRB-klippet over. Neste eksempel er et interaktiv programmering som grensesnitt mot et kjørende system – i dette tilfellet en Ruby on Rails-applikasjon.

I filmklippet som følger lenger ned starter jeg et interaktivt konsoll på en lokal testserver. Der har jeg tilgang til det samme api’et, databasekoblinger etc som forretningslogikken i backenden av systemet mitt. Dette lar meg gå inn i en kjørende applikasjon og prøve ut nye ting, trekke ut informasjon eller gjøre små oppdateringer - mens systemet fremdeles kjører.

Man kan bruke dette konsollet til system-administrasjon i et produksjonssystem: istedet for å bygge tidkrevende web-admin-funksjonalitet i systemet ditt, så kan du la døra stå åpen for å ta de mer sjeldne oppgavene direkte i det interaktive konsollet. Bygg eventuelt web-UI for manglende ting dersom du ender med å gjøre samme oppgave om og om igjen på kommandolinja.

Dette shellet kan også brukes under utviklingsløpet for å se “hvordan ting arter seg” før man velger å forfølge noen bestemt løsningsretning med unit-tester, web-grensesnitt osv osv.

La oss flytte oss opp til frontend-utvikling. Når vi utvikler web-grensesnitt så har vi et annet interaktivt miljø vi kan bruke: Firebug-konsollet. Her er en liten demonstrasjon.

Dette var et veldig enkelt eksempel. Jeg bruker imidlertid samme teknikker når jeg jobber med mer komplekse webapplikasjoner: da bruker jeg hyppig konsollet for å prøve ut ting “live”. Metodikker som f.eks testdrevet utvikling er flott for backend-utvikling, men i visuell/frontend-utvikling er det ofte vanskelig å lage programmatiske tester siden man ikke helt vet hvordan ting kommer til å se ut og oppføre seg i nettleseren. Kanskje vet du ikke engang helt “hva du leter etter” på forhånd? Da er det fint å kunne prøve seg fram litt før man skriver for mye kode.

Nå vet jeg hva du tenker. “Men Thomas, jeg har ikke lyst å sitte og skrive kode rett inn i disse kommandolinje-greiene. Jeg liker editoren min mye bedre!” Jeg forstår den innvendingen. Du kan eventuelt skrive koden i editoren og manuelt lime den inn på kommandolinja, men det er blir fort litt knotete. Vi har mer lyst til å arbeide i en skikkelig IDE, og sende kode derfra til det interaktive miljøet. Vi skal se på et eksempel på slik arbeidsflyt i et språk som heter Clojure.

Clojure er et ungt, lovende programmeringsspråk. Det er bare noen år gammelt, men er bygget på moden teknologi. Clojure er implementert i Java, snakker pent med Java-biblioteker, og basert på LISP (en over 50 år gammel dialekt av programmeringsspråk). Det vi hittil har kalt “interaktive konsoller” blir ofte kalt Read-Eval-Print-Loops (REPL). Dette utrykket kommer opprinnelig fra LISP, som har hatt slike verktøy (og kultur for å bruke dem aktivt) i mange år.

La oss se på et eksempel i Clojure. Jeg holder meg i editoren min, og sender funksjoner og kommandoer til REPL-prosessen rett fra editoren min. I dette tilfellet bruker jeg dette til å jobbe smidig med 3d-grafikk (jeg er veldig uerfaren på dette området, og trenger derfor umiddelbar feedback på alt jeg gjør). Klippet under starter med å demonstrere helt grunnleggende ting, så tar vi steget opp til grafikk-arbeid. Mot slutten implementerer jeg rendering av et veldig enkelt  Tetris-spill.

Hva har vi sett så langt?

Interaktiv programmering gir deg rask feedback. Det lar deg jobbe hurtigere, skrive mindre kode, lære og utforske, snakke direkte med kjørende systemer, og gjøre effektiv prototyping og visuell utvikling.

Nå tenker du kanskje: “jeg arbeider med Java til daglig, hvordan kan jeg bruke disse greiene til noe nyttig?” Vel, alle disse teknikkene kan brukes sammen med Java-kode. Ruby kan kjøres på Java: JRuby er en moden platform som snakker pent sammen med Java-komponenter. JavaScript likeså: du kan enkelt kjøre JavaScript på serversiden som et interaktivt skall rundt applikasjonen din. Clojure er allerede bygd i, og beregnet for bruk sammen med, vanlig Java (3D-eksemplet ovenfor bruker allerede et Java-API for OpenGL-grafikk).

Det er derfor ikke mye som skal til for å få slike interaktive skall rundt din egen applikasjon. Kan du lukte mulighetene her?

Til slutt vil jeg gjerne at du tar en kikk på filmklippene under. De er eksempler på s.k. Livecoding, en aktivitet som ligger i skjæringspunktet mellom programmering og performance-kunst. Det som skjer i klippene under er at utvikleren koder opp improviserte algoritmer for lyd og musikk live foran publikum. Kanskje ikke nyttig umiddelbart nyttig for deg og meg, men det er et interessant eksempel på interaktiv programmering tatt til sin ytterste konsekvens.

Referanser:

A list of REPL environments

Demystifying IRB commands (interactive Ruby)

Secrets of the Rails Console Ninjas

The Firebug Console Panel

Clojure.org: ‘Getting started’

in which are found tricks of the trade concerning clojure authorship

Penumbra OpenGL framework: ‘Getting started’

Impromptu livecoding environment introduction

Andrew Sorenson livecoding videos

Jeg skal fortelle deg hvorfor du bør lære deg et s.k. scriptspråk. Scriptspråk har andre styrker enn Java og C#, og tilfører allsidighet og produktivitet til verktøyskuffen din. En kompetent håndtverker bruker mer enn hammer på jobb: skrutrekker, meisel og knipetang må også med.

Steve Yegge skrev for noen år siden en glimrende artikkel om hvordan han skiller gode utviklere fra svakere kandidater under jobbintervjuer ^[1]. Et av poengene hans er at mange utviklere har en akilles-hel: det ene språket de mestrer er ikke ideellt til alle situasjoner. De er “one trick ponies”.

Her er et intervjuspørsmål som Yegge bruker til å teste kandidater:

Last year my team had to remove all the phone numbers from 50,000
Amazon web page templates, since many of the numbers were no longer in
service, and we also wanted to route all customer contacts through a
single page.

Let’s say you’re on my team, and we have to identify the pages having
probable U.S. phone numbers in them. To simplify the problem slightly,
assume we have 50,000 HTML files in a Unix directory tree, under a
directory called “/website”. We have 2 days to get a list of file
paths to the editorial staff. You need to give me a list of the .html
files in this directory tree that appear to contain phone numbers in
the following two formats: (xxx) xxx-xxxx and xxx-xxx-xxxx.

Hvordan ville du løse dette problemet? Hint: Java og C# er ikke førstevalget til Steve, ei heller mitt. Du KAN løse dette og mange lignende problemer i Java eller C#, men et scriptspråk lar deg løse problemet raskere og mer elegant.

Så hva er scriptspråk og hvorfor er de så nyttige? Jeg definerer kort og godt disse til å være Ruby, Python, og Perl. Alle tre er modne, populære språk. Det betyr ikke så mye hvilket av dem du lærer først: alle sammen deler de fleste av følgende styrker:

• Førsteklasses støtte for å manipulere tekster og filer.
• Fungerer bra sammen med kommandolinje-verktøy og shellscripting, spesielt på unix-systemer.
• Enkle å komme igang med. Vanligvis preinstallert på Unix, Linux og OS X-systemer.
• Gode til proof of concepts og prototyper. Passer bra til å rask iterere frem og demonstrere konsepter.
• Ypperlige til å automatisere oppgaver (f.eks scripting av operativsystemer, applikasjoner, byggeprosesser).
• Er gjerne dynamisk typede språk, noe som lar deg bruke mindre tid på syntax og mer tid på selve oppgaven du skal løse. ^[2]
• Kan kjøre oppå, eller sammen med, de tyngre platformspråkene (se JRuby, IronRuby). Best of both worlds!
• Gir deg et nytt perspektiv på platformer og språk du allerede mestrer. Det er alltid nyttig å utvide horisontene sine! ^[3]

Høres dette nyttig ut? Har du lyst til å lære mer? En god måte å komme igang på kan være å lese denne boka:

eller denne:

Sett deg så ned med et konkret prosjekt. Finn f.eks en “tidstyv” i hverdagen din – en rutine som kan automatiseres. Lag et script som løser problemet ditt.

Vips: fremtidig tid spart, og du har begynt å legge et nytt, kraftig verktøy i reportoaret ditt!

Referanser:

1) Yegges artikkel om intervju-spørsmål
2) Yegge om styrkene til scriptspråk/dynamiske språk (video)
3) Robert “Uncle Bob” Martin om hvorfor du bør lære nye språk (video)

Hvorfor gjør vi IT-investeringer? Det handler om å redusere komplekse problemer til meningsfylte oppgaver som mennesker kan fullføre.

Jeg ønsker å fokusere på utvikling av programvare (løsninger, pakkeprodukter, osv) og hvilken verdi programvare har for våre brukere. Å bygge programvare er en av flere viktige funksjoner som vi gjør hos Steria, og det er tusenvis av andre som også bygger programvare for å løse utfordringer.

Undersøkelser har vist at vi ikke har hatt særlig forbedring i suksessraten i utviklingsprosjekter. Bransjen har ca. 30% suksess i prosjekter som starter opp, og slik har det vært siden 1996 i følge Standard Group (CHAOS Report). Hvorvidt dette er representativt for det norske markedet er ukjent, men egne erfaringer fra Norge tilsier at det er en betraktelig høyere andel prosjekter med suksess her i landet, mye takket være smidige teknikker og prosesser.

Programvarens lov

I henhold til David S. Platts 3 lover om programvare, har programvaren vi bygger i seg selv ingen verdi. Det har liten betydning hvor teknisk bra kildekoden til et program er, det er kun vår egen mor som bryr seg om slikt.

Platts 3 lover sier:

1. Programvare har ingen verdi i seg selv. Den eneste verdien programvare har er gleden den gir til brukeren.
2. Programvaren kan øke brukerens glede på en av to måter. Den kan hjelpe brukeren å fullføre en ønsket oppgave, eller den kan gi en god opplevelse. Eksempelvis hjelper Outlook med å lese og skrive epost, mens HALO på Xbox 360 gir deg en god opplevelse som er underholdende.
3. Brukeren skal ikke tenke på programvaren. Det viktigste er innholdet og oppgaven, ikke programvaren i seg selv.

Målet med programvare bør alltid være å redusere komplekse problemer til enkle oppgaver. Enkle oppgaver som mennesker kan utføre, uten at det krever mye tankearbeid. Desto mindre en bruker må tenke, desto mer glad og produktiv vil han bli.

Tenke enkelt

Når vi har et komplekst problem vi ønsker å løse, hvilke mekanismer pleier vi å benytte for å løse dem? Når vi ser på programvaren som har blitt utviklet opp igjennom årene, er det ganske klart at vi ikke tenker på å gjøre ting enkelt.

Vår forståelse av komplekse problemer øker desto mer vi jobber med dem. Men vi har problemer med å komme opp med enkle løsninger. Altfor ofte lager vi kompliserte løsninger for komplekse problemer. Dette må vi forsøke å unngå, for det er hovedårsaken til at utviklingsprosjekter feiler.

Vi må sammen begynne å tenke enklere. Vi må sammen utforske hvordan vi kan redusere komplekse detaljer i et løsningsdesign, helt til vi sitter igjen med et design som er så enkelt som overhodet mulig og fortsatt gir verdi til brukerne.

Vårt mål bør være: Lage en enklest mulig arkitektur.

Det er selvsagt mange årsaker hvorfor noe som starter enkelt, fort blir komplisert. En viktig faktor er mengden av funksjonalitet i en løsning. Robert L. Glass  skriver i boka “Facts and Fallacies of Software Engineering” at 25% økt funksjonalitet øker kompleksiteten med 100%.

Neste gang du står ovenfor et problem som noen ønsker løst ved hjelp av programvare, start med å tenke over brukerne og hvordan du kan øke deres glede. Deretter reduserer kompleksiteten i løsningsdesignet til du oppnår det enkleste designet som er mulig som fortsatt oppnår målet: Gjøre brukerne glade!

(Se mitt innlegg om løsningsarkitektur på MSDN Live for mer detaljer om dette emnet)

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!

Min erfaring er at det er ved produksjonssetting de virkelige utfordringene begynner, og da din prosjektgruppe trenger fokus. Nettopp da må styringsgruppen og involverte beslutnignstagere forstå at prosjektet trenger arbeidsro og gode rutiner, ikke nedleggelse, nye rapporteringsforpliktelser, bli gjenstand for budsjettkutt eller lignende. Utsagnet et system som ikke endres er et dødt system er virkelig sant i denne perioden. Husk det når du budsjetterer prosjektet og når du setter dine forventninger.

Det er alltid forbundet med risiko å ta en beslutning om konvertering og produksjonssetting, ofte resulterer det, i at man ikke klarer å skru av det gamle systemet likevel, eller at svært mange interessenter blir misfornøyde og skaper mye støy for prosjektet – den gamle løsningen fungerte jo bedre. Man kan teste så mye man orker før produksjonssetting, men Murphy’s lov slår til og ting går galt. Brukeren kan det ikke – da fungerer det ikke. Noe av det testteamet trodde var i orden viser seg kanskje også å skape en nedtur i begynnelsen. Opplevelsen trenger altså ikke bare være basert på reell mangel på funksjonalitet, men opplevd funksjonalitet. Fenomenet kan illustreres med en blodbadkurve, der man opplever at det nye systemet fungerer vesentlig dårligere enn det gamle systemet i en periode etter produksjonssetting.

Ved å gjøre de rette grepene kan imidlertid blodbad-perioden reduseres og gjøres minst mulig smertefull. Her er fire tips.

1. Styr forventningene i forkant – Blodbad-perioden er ofte den samme tidsperioden der styringsgruppen forventer at gevinstene skal realiseres, gjerne nokså umiddelbart. Dette er en umulighet hvis man ser på kurven over. Prosjektet er travelt opptatt med å prioritere feil, lære seg å drifte det nye systemet, lære brukerne å bruke det nye systemet og løse de mest kritiske tingene som mangler i systemet, ofte ved hjelp av tidkrevende workarounds inntil gode nok løsninger er på plass.

2. Gi prosjektet økonomisk handlingsrom – Det sikreste man kan gjøre for å sikre absolutt fiakso er å legge ned prosjektet i denne fasen. Likevel er ofte “pengene brukt opp”, man hadde jo ikke regnet med at man måtte jobbe når man hadde levert til produksjon og nedleggelse blir realiteten. Det å ikke ha penger til endringer og videreutvikling i denne perioden er den sikreste måten å redusere levetiden på det nye systemet dramatisk. Det kan også tenkes at de som har fått det nye systemet trenger litt tid på å lære det, så regn med noen vikarer.

3. Vær flink til å prioritere og operer med åpne prioriteringslister – Styringsgruppen ønsker rask realisering av visjonen og at prosjektet skal makte å følge den stiplede grønne utviklingsbanen. Svaret er ja, det skal dere få, men først må prosjektet få hodet over vannet i form av å løse de mest kritiske feilene. Deretter kan man prioritere forbedringer og nyutvikling. Et sikkert tegn på at man har med en umoden styringsgruppe å gjøre er dersom de i denne perioden forventer at prosjektet skal prioritere nye forretningskrav som plutselig har kommet opp når de ser det nye systemet. Prosjektgruppen bør prioritere utestående områder slik at det som er mest kritisk (eller lønnsomt) kommer først.

4. Avklar ansvar og organisasjonsmodell for vedlikehold tidlig – Etter produksjonssetting kan det være uklare ansvarsforhold knyttet til vedlikehold. Innse det med en gang – et system uten endring er et dødt system. Da må man vite hvordan endringene skal gjennomføres, testes og produksjonssettes også etter oppstart. Ofte “fryses” kanskje systemet for å unngå store endringer rett før oppstart, med den konsekvens at utviklerne som kunne løst feil raskt forsvinner over til andre oppgaver eller mister fokus. Realiteten er at det er i produksjonssettingsfasen at endringstakten, eller i hvert fall feilrettingstakten, bør være desidert størst. I hvert fall dersom man mener alvor med å snu blodbadet og realisere visjonen for prosjektet.

Legg merke til at jeg ikke foreslår å utsette produksjonssettingen. Dette er åpenbart eneste alternativ dersom man ser at selv de mest basale behov systemet er tenkt å løse ikke fungerer, men i så tilfelle har prosjektet et større problem og burde ha lært seg metoder som Scrum og EVO for lenge siden.

Legg også merke til at prosjektet endrer karakter den dagen man produksjonssetter. Det er ikke lenger et erstatningsprosjekt. Det er et smidig forbedringsprosjekt og må behandles som det!

Les mer på sterkbladning.no:

• Johannes om erstatningsprosjekter
• Ole-Vidar om driftsrammeverk (ITIL) vs utviklingsrammeverk (Scrum)

• 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!

Fokus på “hvorfor”, ikke “hvordan”

Hva forsøker denne testen å uttrykke:

Når en bruker registrerer en betaling med beløp “-1234567890″, så skal brukeren se en feilmelding

Hva med denne:

Når en bruker registrerer en betaling med et negativt beløp så skal brukeren få en passende feilmelding

Magiske tall, tekster og verdier i tester skjuler hva vi forsøker å spesifisere. Noen flere eksempler: “når en bruker utelater et eller flere påkrevde felter, så skal brukeren få en feilmelding knyttet til de manglende feltene”, “gitt at brukeren leverer en lottorekke med for få tall”.

Å koble slike tester mot systemet krever mer arbeid, spesielt de første gangene, men testene blir mye klarere etterpå. Og hovedformålet med en akseptansetest er at den er en spesifikasjon som kan diskuteres mellom prosjektet og omverdenen. Og da er det viktig å være klar. Noen ganger vil det virke svært vanskelig å automatisere forståelige spesifikasjoner. Da bør du huske at en god beskrivelse er mer verdifull enn en dårlig test.

Given-when-then

Noe av det første du lærer med tester er “bruk formen ‘gitt X, når Y, så Z’”. Men det er ikke alltid så klart hva X, Y og Z skal være. Tester består av tre typer steg:

• Arrange (oppsett, “given”): Beskriver tilstanden til systemet før testen starter. Typiske eksempler er “gitt at det eksisterer en bruker med utestående betalinger“, “gitt at tjenesten levert fra vår partner har registrert et varenummer” eller kanskje “gitt at det er en fredag” (du får vente til freddan). Avhengig av systemet og tilstanden vi beskriver, kan testen benytte disse stegene på forskjellige måter: Vi kan sette opp brukeren og betalingene i systemet, vi kan se på steget som en forutsetning som vi sjekker om er oppfylt, for eksempel ved å gjøre et søk mot tjenesten fra vår partner, vi kan forutsette, eller endog håpe at det er oppfylt og vi kan la steget kun være dokumentasjon, slik at når testen feiler, så vet vi noen ting vi kan verifisere manuelt, eller det kan være en ren løgn. Kanskje systemet er satt opp på en spesiell måte slik at det ikke er avhengig av ukedagen. Men vi har lyst til å dokumentere hvordan det hadde sett ut om det hadde vært “på ordentlig.”
• Act (utfør, “when”): Beskriver stimuli inn fra omverden. “Når brukeren registrerer en ny betaling,” “når klientsystemet sender en betalingsforespørsel med manglende kundeinformasjon”. Disse kan implementeres på flere måter i de fleste systemer: Et test av et web-grensesnitt kan simulere en klient med for eksempel webdriver, den kan gjøre et http-kall og direkte, eller testen kan bruke klassene som implementerer tjenesten direkte. For funksjonelle tester foretrekker jeg nesten alltid det siste. Det gjør at testene vil kjøre hundre ganger raskere, og vil som regel innebære mindre jobb. Husk: Det er ikke nødvendig å teste brukergrensesnittet på nytt for hver valideringsregel eller spesialtilfelle i applikasjonen din.
• Assert (sjekk, “then”): Beskriver hvordan systemet skal reagere på stimuli og hva tilstanden til systemet skal være etterpå. For eksempel “så skal brukeren få en feilmelding om at alle betalinger må være utført før en ny betaling kan registreres”, “så skal den nye betalingen ikke lagres i systemet.”

Veien fra testscript til spesifikasjoner

Når prosjekter først tar i bruk FitNesse er det veldig vanlig å se tester som ser cirka slik ut:

• Putt inn en kjempeliste med rader med en bråte kolonner inn i tabell A.
• Putt inn en ny kjempelist med rader etc i tabell B
• Send inn et kjempemessig XML dokument
• Sjekk at svaret matcher et nytt XML dokument

Dette er ikke en spesifikasjon – det er et testscript. Og det er ikke slike tester som gir verdi til et prosjekt. Men det er et sted å starte, for det krever ikke så veldig mye kreativitet. Og vi kan gjenbruke lærdommen fra slike tester. Men før det blir en hel skog av tester som dytter XML-dokumenter hit og dit, kan det være lurt å løfte testene opp på et mer logisk nivå:

• Gitt at det ikke eksisterer noen betalingsforespørsler
• Og en bruker er registrert
• Når brukeren sender inn en betalingsforespørsel med ett gitt problem
• Så skal brukeren få feilmeldingen en gitt feilmelding

I FitNesse-terminologi kan en slik test implementeres som en ColumnFixture. Det vil si: Hvert par av “problem” og “feilmelding” er en rad i en tabell. Slik kan vi uttrykke mange regler ved systemet klart og konsist.

Dersom du har startet å gå veien med testscript, er det ikke vanskelig å snu: For hver rad i den nye spesifikasjonen din skal du utføre alt det testscriptet ditt gjorde.

Jeg vil bruke jobben med akseptansetester til ikke bare å gjøre automatiske kjøringer av systemet mitt, men til å spesifisere og diskutere de egentlige kravene brukerne mine bryr seg om. Og dersom jeg må velge mellom tester som lar seg automatisere og spesifikasjoner som beskriver kravet, vil jeg alltid velge det siste.

Lykke til med ditt testbare prosjekt!

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.