[DK] Red, Green, Customer Test, Refactor

De sidste fem års tid, har jeg arbejdet en del på opgaver med en del forskellige kunder. En af udfordringerne ved nogle kunder kan være, at de er svære at få krav ud af. Det kan endda være at de giver forkerte krav, hvor det senere viser sig at en anden I virksomheden, som har mere forstand på det område, siger at det er helt forkert. Jeg tror generelt det er en normal problemstilling i hele vores område - det er da det jeg hører rundt omkring.

Derfor, så undre det mig også, at meget af vores udviklingsprocessor er baseret på at vi laver det rigtige.
Vi starter med at lave diagrammer, hvor vi tager deres krav, og måske laver vi det til en super-sej datamodel. Så implementere vi det fint I vores one-size-fits-all arkitekturmodel, og bruger en masse tid på overengineering, fordi det giver nogle teoretiske fordele i fremtiden (N-tier f.eks.). Vi snakker performance, og blamer ham som kom til at lave en N+1 query. Vi arbejder på opgaven, som om, at vi aldrig kommer til at se den igen - så den skal bare være lige i skabet!

Vores scrum board ser jo også sådan ser ud, så vores seddel skal jo helst ikke tilbage:

Klar -> Udvikling -> Customer Test -> Deploy -> Done

Jeg gætter på at det er sådan mange virksomheder arbejder på. For en leder som ikke kender programmering, så giver dette god mening, da vi jo skal lave kvalitet til vores kunder, så ting bør ikke kommer tilbage fra test.

Med mindre vi her snakker om en meget lille ændring, så kunne jeg forestille mig at kunden i mange tilfælde, ville sende opgaven tilbage, med en kommentar omkring at den skal kunne dette, eller at de nu har fundet denne nye fede feature som de nu bare MÅ eje.

Problemet for dig er nu, at du har lagt dig selv ind i den tunge one-size-fits-all arkitektur - lavet perfekte SQL queries, med indekses og hele pivtøjet. Den nye feature - fy for helvede - hvor fik de den ide fra - den passer jo slet ikke ind!

Du står nu med det tunge arbejde at skrive det om, og tilføje features. Problemet er bare at din kode var optimeret til produktion, og ikke optimeret til tilpasninger og udviklerhastighed. De 2 lag mapping du har imellem din DB og din ViewModel, sløver dig virkelig ned. Opgaven går over estimat, og deadline, og du har nu travlt. Du ender med at lave en omgang hacks på din egen kode, og sender den i produktion.

Jeg har engang hørt, at en arkitekts opgave, er at udsætte sine beslutninger til det senest mulige tidspunkt. Det er nemlig der han ved mest, og kan lave den bedste beslutning. Så hvorfor bliver vi ved med at lave en vandfalds model inde i vores såkaldte "Agile" process? Hvorfor venter vi ikke med at lave det til super kode til efter at kunden har testet og accepteret det?

Jeg har aldrig lavet pæn kode, som ikke skulle refactores lidt, og jeg forestille mig heller ikke at du kan gøre det. Jeg ved også, at hvis der er en arkitektur model man gerne vil holde, som giver noget ensartethed på projektet så tilføjer den nok også noget vægt. Min erfaring har derfor været at det giver meget bedre mening, at give den uperfekte kode ud til kunde-test, så få deres erfaringer, og så gå tilbage og rette den, give dem den nye version af den uperfekte kode.

Når vi er færdige med den runde. Så har vi nu deres rettelser, plus den nye feature vi ikke havde forudset. Vi har nu, meget mere info til omkring hvordan dette skal refactores og sættes ind i arkitekturen. Når kunden har godkendt featuren, så laver vi vores refactoring, tilpasser og performanceoptimere, hvis det er nødvendigt.

Resultatet er at kunden får noget hurtigt, du får hurtig feedback - du kan teoretisk set deploye før (hvis du vil deploye før din refactoring), og du kan lave en pænere refaktoring, da du nu kender mere til problemstilingen, og nu ikke længere har deadlinen som ånder dig i nakken.

Dette kræver selvfølgelig at man har tid bagefter til at lave sin refactoring, og det kræver at man på en eller anden måde kan teste om den virker.

Så brug den sætning fra TDD som hedder Red, Green, Refactor, men gør det også bare for kunde test. Tænk over om det er tiden værd at sætte din kode ind i den fine arkitekturmodel, lave alt den performance optimering - eller om det bare handler om at lave en prototype, eller måske en silver bullet, og se om vi virkelig har forstået kundens krav.

Det kræver noget af organisationen og af dig at kunne udføre en opgave på denne måde. Men det er et kraftfuldt værktøj at have i sit toolbelt, at kunne "crap-kode" og få respons hurtigt. Min erfaring er bare, at hvis der ikke er helt styr på krav, så får alle parter et bedre resultat ud af at gøre det på denne måde. Det er bare vigtigt at du altid kan være tryg ved at refaktore din kode på et senere tidspunkt: Du kan være sikker på at du har tid, plus at du evt. har tests, eller manuelt kan teste om din refactoring virker. Jeg har prøvet scenarier, hvor vi efterfølgende ikke ture ændre koden, og så har du virkelig skudt dig selv i foden.

Read more

[DK] console.log og IE support

Tit når man udvikler javascript kode, så har man nogen gange behov for at logge noget til ens console.

Så man vil typisk skrive dette kode:

Ordenlige browsere understøtter alle sammen disse kommandoer idag - men Internet Explorer support er lidt speciel (den har vi ikke hørt før).

  • IE7 supportere ikke console.log, så den vil fejle.
  • IE8+9 der vil console.log kun virke, når dine developer tools er åbne, ellers vil de fejle - det betyder at alle kunderne oplever fejl, men når du sidder og leder efter den, så virker det hele fint. Snedig fejl.
  • >=IE10 den skulle være good to go, ligesom Chrome / Firefox / Safari.

Det korte råd er at du aldrig skal kalde console.log direkte. Brug istedet en wrapper, som er mere fail-safe:

Koden oven for bruger den mest simple form for feature detection i javascript, hvor vi bare ser på om console er defineret (undefined er 'lig' med false i javascript), og kun kalder log, hvis den findes.

Dette er en typisk fejl som folk støder på når man laver nyt javascript kode, hvor tingene virker fint i Chrome / Firefox / Safari men at den fejler i IE.

Read more

[DK] Mine erfaringer med produktivitet, og at være 'In The Zone'

Kender du dette scenarie:

"Du har fået den perfekte ide til hvordan du skal bygge det bedste software verden endnu har set. Du sætter dig foran dit udviklingsmiljø, og begynder at kode. Oh yea, du kommer i flow, og spytter kode ud til højre og venstre. Din code coverage er på 110%, og koden er så flot og smart, at alle kollegaerne får en åbenbaring når de læser det. Du sidder nu dybt i den vigtigste del af systemet og du skal lige til at lave det mest geniale EVE..r.... Jesper har du 5 minutter? Teknisk set, har du 5 minutter - der 288 stk. af dem i døgnet, for en rigtig programmør sover jo aldrig. Efter 30-45 minutter er du tilbage på din plads. Foran dig står der en blinkende markør, som venter spændt på, at den får lov til at skrive det mest GENIALLE KODE EVER færdig. Men du er blank, og ender med at holde pause, ved at læse dårlig journalistik på internettet."

Du har lige været i Flow eller 'In the Zone' som nogle kalder det. Den hellige gral for programmør produktivitet.

Da mennesker er forskellige, så kommer nogle mennesker let eller svært i flow, samt at der sikkert er nogen som aldrig gør det, og måske ikke har brug for det. Jeg er ingen ekspert og kender kun mine egne erfaringer. Joel Spolsky skriver i din artikel "The Joel Test: 12 Steps to Better Code (nr. 8)" at en programmør tager 15 minutter om at kommer tilbage i flow. Personligt er det alt for lidt for mig. Jeg har typisk kun et flow per dag. Det kommer på et eller andet random tidspunkt på dagen, og bliver jeg afbrudt i mit flow, så er der psykisk gået 7.5 time, min produktivitet falder 95% og jeg er klar til at tage hjem.

Det er selvfølgelig et problem. Både det at man bliver afbrudt (forbandede andre mennesker), samt at jeg personligt ikke kan finde tilbage til mit flow. Selvfølgelig er der afbrydelser i en programmørs hverdag, og vi skal kunne håndtere dem på en effektiv måde.

Jeg har fundet ud at disse punkter hjælper mig en del:

  1. Skriv ned hvad du skal lave. En kort todo, med ting som tager meget kort tid at lave. (Opgaver som måske maks tager en time at løse.)
  2. Hver opmærksom på om der kommer roadblocks længere fremme, hvor du skal snakke med andre. Prøv at se om du kan løse dem først. Tit er de personer med viden svære at få fat på, så det kan for alvor ødelægge dit flow, da alt arbejde må stoppe før du ved mere.
  3. Skriv hvad du er igang med at lave. Er du god til TDD, så gætter jeg på at det kan hælpe lidt, hvis du skriver tests med lidt kød på, og ikke bare "Calls the service method" - da det ikke hjælper dig i et større scope. Dette kan hjælpe dig med ikke at gå i stå, og gør måske at den genialle ide bliver færdig udviklet.
  4. Prøv at holde afbrydelser på et minimum. Bed dine kollegaer om at bruge asynkron kommunikation. Næsten altid, så ønsker de jo ikke at afbryde dig, hvis du ikke har lyst til at bruge de 5 minutter lige nu. Hvis muligt så kan man prøve at bygge sin organisation op på, at folk med problemmer, ikke spørger én bestemt person, men spørger ud i rummet. Ikke det virkelig rum, men f.eks. et chat-rum, som alle aktivt lige læser når de ikke selv er i flow. Medarbejdere hos GitHub skulle være gode til at gøre dette, men jeg kan ikke lige finde artiklen hvor jeg læste det :)
  5. Accepter, og håb at arbejdspladsen acceptere, at programmører ikke er robotter, og at mange programmører bare ikke virker fra 8-16 hver dag, og producere et stabilt antal genial kode. Tag hjem noget før, bliv lidt længere - eller se om du kan skifte til en anden opgave som mangler at blive lavet.

Jeg ville gerne høre om I havde nogle gode erfaringer med hvad I gør, men denne smarte selv-bygget blog, har ikke lige kommentarer p.t.
Så lad os tage snakken på Twitter, eller lav din egen blog-svar-post - så skal jeg nok linke ;)

Read more

Nice flowchart for choosing the right HTML5 element

This lille flowchart helps you choose what HTML5 element type to use. It is offcause overly simplistic, but it will help you, to not use DIV's all over the place :)

html5 Doctor's HTML5 Element Flowchart

Read more

Visual Studio 2012 Update 2 - released

New stuff! Go grab!

New stuff include:

  • Blue'ish theme is back
  • The latest web tools update is included, that provides new stuff for MVC and so.
  • Properbly something for windows developers as well :)

Download Visual Studio 2012 Update 2

Read more

Next page