NDC2014 er nu officielt startet. Det er en forholdsvis lille konferencen sammenlignet med fx Tech-Ed og Build, men det gør at konferencen faktisk er meget hyggelig og intim. Dagen startede med en keynote, som var meget inspirerende i forhold til design af applikationer som mobile first, og hvilke patterns man burde benytte, når man som udvikler skal pakke sin flotte store, desktop/web app ned på et meget mindre mobilt device.
Keynoten
Første talk på NDC Oslo 2014 var keynoten af Luke Wroblewski, som bl.a. har skrevet bogen Mobile First (2011, A Book Apart). Helt overordnet peger Wroblewski på, at væksten inden for mobile devices inden for de seneste år har været nærmest eksplosiv. Alligevel hænger mange mobilapplikationer ifølge ham fast i ”gamle” designprincipper, hvilket gør dem nærmest ubrugelige på mobile devices.
Wroblewski har flere ganske underholdende eksempler på mobilapplikationer fra selv nogle af de helt store virksomheder, som mildest talt kommer til at fremstå komplicerede og på ingen måde brugervenlige. Simpelthen fordi de ikke har været i stand til at omstille deres forretning til den mobile tankegang – nemt og enkelt. Lange formularer og en masse tekstinput dur ikke for en mobilbruger.
The Mobile Moment
Til at underbygge sine påstande havde han flere statistikker med, hvor denne herunder virkelig understregede virkeligheden. Facebook, som en af de mest populære tjenester i verdenen, har ramt punktet hvor de nu ser flere brugerbesøg på deres mobileapplikationer end på deres websider. Eller som han kalder det – The Mobile Moment.
Wroblewskis pointe er, at man i dag på den anden side af “The Mobile Moment” i højere grad bør tænke ”mobile first”, når man laver applikationer, og man bør teste og udfordre sit design hele tiden – for man kan altid gøre det mere simpelt, og dermed brugervenligt.
Wroblewski fortæller det hele med et glimt i øjet, og viser også et eksempel på en mobil hotel booking app, som faktisk endte med at være blevet for simpel, og hvor man derfor fik problemer med at folks børn og katte (!) bookede værelser. Det endte med, at man måtte indbygge en lille gesture kontrol, hvor man med fingeren skulle følge Hotellets logo for at bekræfte bestillingen.
Overskriften på hans foredrag var “It’s a Write/Read (Mobile) Web”, men senere i sit foredrag siger han, at det i virkeligheden handler om at det er et “multi device web”. Vi bruger ikke længere kun én slags enhed til at tilgå nettet, og Lukes input til debatten omkring Native apps vs Mobile Web (html) er derfor også, at det ikke er et enten eller – det gælder om at udnytte hver platform bedst.
Alt i alt et underholdende og aktuelt oplæg på en god start på NDC. Du kan også se en tidligere udgave af Luke Wroblewskis oplæg (både video og pdf’er):
Skrevet af Stefan og Allan
Seven inffective coding habits of many programmers
Talk af Kevlin Henney
Hvilke patterns benytter vi som udviklere i vores kode, udelukkende fordi det er noget man lærte for 10 år siden, hvor det blev besluttet af årsager der var relevante den gang? Kevlin’s talk drejede sig om at stille os selv spørgsmålet: “Do you do a habit out of habit?”
It turns out that style matters in programming for the same reason it matters in writing. It makes for better reading.
Doug Crockford
Hvis man sammenligner amerikanske og danske bøger, opdager man at oftest vil de amerikanske være en del længere. Årsagen er selvfølgelig at man i USA bliver betalt pr. ord, og indtjeningen på en længere bog, derfor er højere end en lille novelle. På samme måde kan man overveje om mere kode er bedre.
Husk et lavt signal/støj forhold
Kevlin argumenterer for at signal/støj forholdet i ens kode generelt kan blive bedre. Et typisk krav til en udvikler er, at skrive mange kommentarer, ofte er det endda påkrævet via statisk analyse (FxCop, checkin politikker i source control). Argumentet kan være at man skal kunne læse hvad koden gør, særligt i komplekse dele af den. I virkeligheden skal koden være selvdokumenterene (!) Hvis udvikleren ikke er i stand til at lave læsbar kode hvorfor tror vi så han/hun kan skrive læsbare kommentarer! Pointen var ikke at vi aldrig skal skrive kommentarer, men vi skal kun skrive de kommentarer som koden ikke kan forklare – og først efter vi har gjort koden læsbar.
God læsbarhed af koden
Visual spacing should have a context with what the code is doing
Kevlin Henney
Læsbarheden afhænger også i høj grad af indenteringen, som jo typisk kan starte flamewars blandt selv de mest nedtonede udviklere. Nu om dage sidder vi alle med 1920×1080 skærme, så de 80 karakterer er ikke længere en begrænsning. Men det ændrer jo ikke på menneskets synsfelt og hvor lange sætninger vi er i stand til at overskue. Samtidig er det vigtigt at strukturere din kode så den er strukturelt ærlig, metodeparametre skal være alignet og altid alignet på samme måde.
En anden interessant observation som Kevlin nævnte er Agglutination, den måde vi sammensætter ord til at beskrive metoder eller klasser. Hvis man kigger på nedenstående eksempel
Ovenstående eksempel har vi alle set, men hvorfor beskriver vi hvad koden skal gøre, og ikke hvad vi egentlig vil. Igen er vi ovre i paradigmer fra funktionelle programmeringssprog the what, not the how. Samme situation med exceptions, hvorfor skal de partout slutte på “…Exception” (udover language guidelines typisk definerer at det skal de)? Der er jo ikke så meget andet der kan throwes…
For os giver disse pointer god mening og mange af dem kræver kun, at vi er i stand til at ændre vores vaner, som fx hvordan vi bruger spacing og hvor lange linier vi skriver. Andre af vanerne vil nok give anledning til mere debat i et udviklerteam, som fx at gå mod de etablerede kode guidelines. Lige dét kan være svært at indføre i større teams. Trods alt er den vigtigste vane, at koden fremstår ensartet, selvom teamet eller forretningen er stor.
Selvom intention er god, er vaner svære at ændre især i en travl hverdag. Hvilke successer har I haft i at ændre kodevaner i jeres organisation?
Skrevet af Helle og Anders
Leave a Reply