Sandro Mancuso om testtäckning

Testtäckning är en siffra som mäter hur stor del av koden som täcks av test. Eller rättare - som det oftast används - hur stor del av kodbasen som provkörs med hjälp av kod i de skrivna testerna!

Man kan verkligen fråga sig om till vilken nytta det här måttet egentligen är. Meningen med alls investera i skrivna tester är ju att de ska ge ett konkret värde. Till exempel vara säker på att en viss funktion fungerar som förväntat, även om man genomför förändringar i kodbasen.

Sandro Mancuso, en av förgrundsgestalterna inom den brittiska delen av Software Craftsmanship-rörelsen har skrivit ett insiktsfullt blogginlägg om vikten av att fråga sig varför ett test finns. Vilket värde har vårt test för slutresultatet?

Testtäckningsmåttet är viktigt för att få upp ögonen för vilka delar av vår applikation som för närvarande saknar meningsfulla tester. Men att ha täckt en del av vår kod med tester är ingen garanti för att vi testar något viktigt. Som vanligt är det de reella kvaliteterna i vår mjukvara som spelar roll, inte att vi uppfyller det ena eller andra abstrakta måttet.

Sandro Mancuso är en av talarna på Software Passion Summit 2012. Se programmet här, och boka din biljett här.

SSWC Torsdag

Så sammanstrålade vi så äntligen på Tjärö, patchworkers, Dfinders, och alla andra. Härligt förväntansfull stämning i luften, människor nyfikna på varandra, många nya kontakter som knyts.

Sweden Social Webcamp är ett nördkollo och knytkonferens om nya media, nya arbetssätt, digitala livsstilar; och om att sätta GPS-sändare på får för att kunna se hur de rör sig på Tjärö.

Det som är så roligt med SSWC är blandningen. Här finns mediafolk, datafolk, folk som sysslar med opinionsbildning, och allt däremellan. Som lyssnar, konfererar, äter, minglar, badar, dricker öl, dansar, spelar och sjunger.

Vi är här för att lyssna och prata. Vi ska försöka hålla tre sessioner: En om Getting Things Done; en om hur man bär sig åt för att samarbeta i agila team när det skiljer ett världshav emellan folk; och en fishbowl om hur framtidens yrkesliv kommer att se ut, om nu gränserna mellan juridiska och fysiska personer håller på att omförhandlas.

Dessutom ska vi försöka sammanfatta de sessioner vi lyssnar till. Vi livetwittrar från sessionerna på vårt twitterkonto RedpatchSE. Följ oss där.

Java 7 7/7 !

Så. Snart släpps Java 7. För att fira har Oracle ett event idag, 7/7.

Ed Dumbill på O'Reilly spinner vidare och...

... listar Sju skäl till att använda Java och skriver avslutningsvis: "At a certain point you'll need performance, predictability and a ready supply of engineers. Scaling, deploying and programming to the cloud are places where Java excels."

...och listar även andra språk som kan köras på JVM:en: JRuby, Scala, Jython, Javaskript (via Rhino) etc.

...och ger exempel på sju Java-API:er som förändrat världen till exempel Eclipse som är den underliggande plattformen för många klientapplikationer, eller Lucene som erbjuder fritextsök i mängder av ramverk, eller varför inte Googles mobil-OS Android?

Läs mer om Javas olika versioner på Wikipedia.

Godmorgon, Java!

Det börjar röra sig på javafronten igen. Som man kunde se på Scandinavian Developer Conference här i Göteborg i våras, så händer det saker. Man kan verkligen hålla med Ben Evans när han i sin presentation gjorde den observationen att Java inte har dött utan bara gått i ide ett litet tag. Medan de stora drakarnas advokater gjorde upp om företagsförsäljningen av SUN till Oracle, så har utvecklingen faktiskt puttrat på.

Först och främst har det (som vanligt) skett mycket utveckling utanför SUN:s och Oracle's väggar. Det är som en fortsättning av de ramverk som utvecklades för Java under 2000-talets första år (tänk Apache och Spring). Ramverken visade i sin tur på behovet av att införa vissa modernare språkkonstruktioner i Java, som t ex möjlighet till mer dynamisk typning, mindre dynamiskt typade kollektioner, eller funktioner som första klassens objekt (lambda-funktioner / closures).

I väntan på att dessa konstruktioner skulle eller skulle inte införas i Java (minns den låååånga väntan utan några besked från SUN), så utvecklades ett antal språk som körs på JVM:en. Till exempel Groovy (dynamiskt typat, lambda-funktioner), Jython och JRuby (Python och Ruby för JVM:en), Clojure, eller Scala (statiskt typat, slick syntax, multiparadigm).

Det är ju en väldigt bra utveckling. Javas virtuella maskin är en väldigt spridd driftsplattform, och alla program som körs i JVM:en kan tack vare dess design hyfsat enkelt integreras med befintliga javaprogram. Med fler programmeringsspråk till JVM:en ökar chansen att man väljer ett språk som är rätt verktyg för jobbet, utan att man för den sakens skull behöver byta plattform.

Dessutom har samtliga dessa utmanarspråk en effektiv syntax. Det kan helt enkelt gå snabbare att utveckla i dem (även om den största delen av systemutvecklingstiden går åt till att tala med människor och inte med maskiner).

Men så händer det saker med själva språket Java också. Henrik Ståhl från Oracle pratade om alla nyheter som verkar (Oracle lovar inget) vara på gång i version 7 och 8. Bland annat pratade han om:

Invoke dynamic - en efterlängtad funktion. Det handlar om att JVM:en ska kunna göra metodanrop utan att kräva kunskap om vilken datatyp metoden returnerar. I alla dynamiskt typade språk kan man detta, så implementatörerna av Groovy och Jython och de övriga har helt enkelt fått fuska på olika sätt. Nu kommer de att kunna göra det mycket enklare, förutom att du som utvecklare kan utnyttja funktionen även i Java (åtminstone i Java 8).

Project Coin - en uppsättning syntaktiskt godis som kommer att göra språket mindre pladdrigt, mer konsist, och mindre irriterande. Bara en sån sak som att äntligen kunna få ange ett heltal med binär syntax i källkoden: 0b10010. Eller att slippa ange samma datatyp på två ställen när man skapar en typad kollektion. Eller att även typen Double får sitt maxvärde specificerat i en konstant.

Ett API-lager för filsystemen - Så att man kan skapa olika filsystemsimplementationer över samma API:er, t ex nätbaserade filsystem eller virtuella.

Dessutom har Oracle fått lite snits på hemsidan igen, så att man lätt och direkt får tillgång till allt javarelaterat. Så om de bara får Java 7 och 8 utanför dörren så blir det upp till oss kodare att använda allt detta och skapa stordåd igen. Eller åtminstone bra grejer.

Typkoll i Javaskript

Javaskript är ett dynamiskt typat språk. Det finns ingen kompilator som garanterar att funktionen:

 function add( x, y) {  
   return x + y;  
 }  

...alltid kommer att anropas med nummer. Alla sådana kontroller måste göras när programmet körs. Sådana kontroller utförs alltför sällan. Men javaskript har ändå fungerande sätt som man kan använda.

typeof

Det finns en unär operator som heter typeof. Den returnerar en sträng som berättar vilket sorts värde en variabel är:

   if (typeof a == "number"){  
     //... om a är ett tal så...  
   }  

Övriga värden som "typeof" returnerar kan vara: undefined, object, boolean, number, string, function, eller xml.

Så på det sättet skulle man kunna kasta ett undantag om x och y inte var tal:

 function add( x, y) {  
   if (typeof x != "number") throw "X must be a number!";  
   if (typeof y != "number") throw "Y must be a number!";  
   //...  
 }  

Number() och isNaN()

Nackdelen med att kasta ett undantag är att det är användaren som oftast får ta smällen då, inte programmeraren. Bättre att försöka konvertera inparametrarna:

 function add( x, y) {  
   x = new Number(x);  
   y = new Number(y);  
   //...  
 }  

Då skulle många värden bli konverterade till tal innan de användes vidare i funktionen. I de fall konverteringen misslyckats så kommer värdet att bli not-a-value-number ("NaN"), och då skulle man kanske kunna överväga att kasta ett undantag:

    if (isNaN(x)) throw "Argument must be number!";
    if (isNaN(y)) throw "Argument must be number!";

Försök lösa situationen åt användaren! Så skulle man kunna sammanfatta en bra felhanteringsstrategi i javaskript. Och typkolla om det går.

(Bilden av pareeerica)

Clean Code & Craftsmanship

En av de bästa trenderna inom mjukvarubranschen just nu är att kod och kodkvalitet börjar få det erkännande det förtjänar.

Vi har alla sett det: en trasslig kodbas, parat med en utvecklingsprocess som enbart betalar för nya funktioner. Ingen får alltså betalt för att göra koden lätt att underhålla, men kunden får betala mer och mer för allt simplare förbättringar, eftersom den tilltagande kodkomplexiteten gör varje förändring dyrare och dyrare. Till slut får vi en infarkt: enbart att hålla produkten/tjänsten/koden under armarna vid normal drift kostar exponentiellt mer och mer och mer.

Man kan i både matematiska och ekonomiska termer beskriva hur sådana infarkter uppstår. Kanske är det ett ämne för en annan bloggpost. Nu räcker det med att konstatera att vi faktiskt vet hur vi ska undvika dem. Och det är ju det viktigaste, eller hur?

För det första behöver vi en process som synliggör kodkomplexitet, teknisk skuld, och skillnaden mellan att ha refaktorerat koden och inte.

Man kan ju inte råda över det man inte ser, så synliggörande är nummer ett. Till exempel genom att bokföra den tekniska skulden på produktbackloggen när den införs, eller att automatiskt analysera förändringen i komplexitet i all kod som checkas in. På så sätt lyfter man frågan upp på bordet och ger sin kund/beställare möjlighet att ta ställning till hur problematiken ska tacklas.

Men för det andra behöver vi alltså konkreta strategier för att vidmakthålla kodens underhållbarhet, och det är här som till exempel "Clean Code" kommer in.

Clean Code handlar om att den kod vi skriver ska vara lätt att läsa och förstå för oss människor, så att vi enkelt kan utöka den med mer funktionalitet, eller enkelt lättare se bristerna. Boken "Clean Code" är en uppsättning tips och regler som sammantaget får oss att producera kod med denna egenskap. I boken får vi till exempel lära oss skriva vettiga kommentarer, hålla nere antalet parametrar, eller varför flaggargument till funktioner är en så usel idé. Bland annat.

Men utöver just den här specifika boken är "Clean code" som företeelse bara en del av en mycket rörelse att försöka bättra på vår gemensamma förmåga och hantverksskicklighet: "Software Craftsmanship".

I den här rörelsen ryms praktikerna inom XP och TDD, här ryms utbytet av diverse designmönster, och här finns diskussionen kring fler programmeringsparadigm än det imperativa och objektorienterade.

Inte minst utgör den här rörelsen en viktig pendang till den agila rörelsen på metodsidan. De agila metoderna försöker visa vad vi ska fokusera på, rörelsen kring "software craftsmanship" fokuserar på hur vi gör det. Alla dessa olika praktiker stöttar varandra och bidrar i slutändan till att vi lyckas göra fler kunder ännu mer nöjda trots att vi förbrukat färre mantimmar på vägen.

Därför tror jag vi kommer att återkomma till de här frågorna många många gånger.

(Bilden från Ell Brown. Some rights reserved!)