次の方法で共有

Har du höga krav på kvalitet?

  • [アーティクル]

Med de senare versionerna av Visual Studio (2005 och 2008) så finns ett stort fokus inte bara på produktivitet utan också på kvalitet av det som utvecklas. Några saker som jag tänker speciellt på är enhetstestning, täckningsgrad och "code-metrics".

Om jag vore kund av ett it-projekt, ett behov av en utvecklad applikation som löser ett speciellt problem för mig så skulle jag absolut börja fundera på att ställa krav inte bara på slutresultatet (det som en eventuell användare ser, eller mer specifikt de funktionella kraven) utan också på kvaliten.

Jag skulle kunna tänka mig att begära att lösningen som utvecklas ska ha en täckningsgrad ("code coverage") på över 75-80% samt ett "maintainability index" på över 80-85% för att känna mig bekväm med det som utvecklats och säkerställa en potentiell vidareutveckling.

Nu har jag tagit mätetalen ovan lite från luften, men faktum kvarstår, dessa krav skulle ställa högre krav på kvalitet på resultatet, att utvecklarna som bygger lösningen har en hög kompetens i design och mjukvaru-utveckling samt att jag enklare än utan dessa krav kan vidarutveckla lösningen.

Vad tycker du?

Comments

  • Anonymous
    June 17, 2008
    The comment has been removed

  • Anonymous
    June 17, 2008
    Jag menar att det är kontra produktivt att ställa upp denna typ av krav. Mary och Tom Poppendieck skriver i sin bok Implementing Lean Software Development From Concept to Cash att: "Det man mäter det får man" (min fria översättning) En av grundpelarna i Lean Software Development är: Optimize the Whole Kombinerar man ihop dessa så menar jag att det man skall mäta istället för "code coverage" och "maintainability index" så bör man mäta levererad kundnytta/affärsvärde. Mättal som "code coverage", "maintainability index", "cyclomatic complexity" kan man dock följa upp under projektets gång och använda som ett diskussionsunderlag för att driva utvecklingen mot en bättre design och bättre coverage av koden för unit-, integration- och acceptans-tester. Problemet är dock att bara för att man t.ex. har en hög coverage så innebär det inte att man har unit tester som testar tänkta funktionaliteten. När jag kör kodanalys på delar av vår kod så kan kod som är två skiktad och som är mycket svår att testa få ett högre "maintainability index" än vår vältestade och välstrukturerade kod. Är man då som kund inte insatt i att detta kan uppstå så är det lätt att man får en felaktig uppfattning om vad som är bra och dålig kod. Min slutsats: Skall man mäta så är det levererat affärsvärde per iteration som är intressant.

  • Anonymous
    June 17, 2008
    Kanske en aningens krass inställning, men helt allvarligt... hur många kunder fattar vad det innebär? Klart de kan ställa krav på vissa mätetal, men risken är nog stor att fokus vid leverans inte hamnar på funktionalitet, användvänlighet mm utan istället om man avviker en enhet från uppsatta krav på mätetalen. Lite som att ställa krav på viss dokumentation men ingen kollar innehållet i dokumentet, bara det finns med vid leverans. Däremot tror jag att verktygen och resulterande mättetal är mycket användbara för utvecklare, teknisk projektledare, scrum master m.fl., men det är roller som i min erfarenhet inte finns hos kunden.

  • Anonymous
    June 17, 2008
    Code coverage i sig säger inget, det är avsaknaden av coverage som säger något. det betyder att den kod som inte täcks av enhetstester är antaligen inte byggd för att testas. Det är väll ok vid första anblick. Men när man arbetar med regresionner, dvs bugger som återkommer så att skapa ett test som verifierar buggen innan man löser den gör att miljön säger till om man råkat "återskapa" en tidigare bug. Det är ju testbarheten som codecoverage mäter, inte att koden gör det den skall. Men däremot är Code-metrics värdelösa i 2008, eftersom det går inte att få ut dem på annat sätt än att köra visual studio. Det går inte att varje natt köra en byggning som dessutom redovisar code-metrics. Det gör att man manuellt måste bygga sin analysdata innan det går att använda.

  • Anonymous
    June 18, 2008
    Mycket bra att definiera mätetal som man kan komma överens om innan projektstart.  När jag lägger ut jobb i framtiden kommer jag att överväga detta. Avvikelser kan man alltid diskutera efterhand, men uppfyller det redan kontraktet är det ju toppen.   Utgå inte från att kunden inte fattar vad du pratar om.  Men många beställare fattar inte att de kan och måste ställa krav numera och det här är ett enkelt sätt att få någonsorts kontroll.

  • Anonymous
    June 18, 2008
    Jag har fortfarande inte mött någon kund som vet vad code coverage är eller liknande. Men jag hoppas på att möta någon som faktiskt ställer krav på kodens kvalité och hur lätt den är att sätta in sig i. Men jag saknar ett annat krav: Robusthet. Kod testad med unittester är i min mening inte samma sak som en robust applikation. Robusthet är inte heller samma sak som uptime tycker jag. De senaste beställarna som vi hade till vårt projekt var mer intresserade av att få in ny funktionalitet snabbt (som det visar sig att de inte kommer att använda i år), än att rätta viktiga buggar som inträffar 3-4 gånger i veckan. Så att gå från det scenariot till att beställaren vill ha code coverage är ganska långt. Dock måste vi väl sikta dit så att vi når dit. Det var mina tankar. /Jonas

  • Anonymous
    June 25, 2008
    Som många andra skriver i sina kommentarer så tror jag inte heller att en "vanlig" kund vet så mycket om cyclomatic complexity och code coverage, men det beror lite på vem kunden är faktiskt. Jag var tidigare lösningsarkitekt på ett större företag och vi anlitade ofta konsulter för våra utvecklingsuppdrag där jag själv hade rollen som arkitekt. Då hade ju faktiskt jag rollen som kund och kunde ställa krav runt just dessa saker. Själv har jag använt dessa verktyg för att få en pejl på hur koden mår i lite större utvecklingsprojekt, som en del i kodgranskning. Genom dessa verktyg och värden kan man upptäcka delar som sticker ut och som kan behöva "refactoras". nDepend är ett ganska ballt (och avancerat) verktyg som verkligen kan hjälpa till med sånt. Code coverage är lite speciellt och som en del säger så kan det ge en indikation på att man har kod-stycken som kanske inte används och kan tas bort. Sen är det ju också så att vissa applikationstyper (som exempelvis ASP.NET) inte är helt lätt att enhetstesta. Det finns ju en hel del kritik mot .NET ramverket att det inte erbjuder så många interface som det borde och därför gör det svårt att testa. Kul att se ändringarna som införs i och med ASP.NET MVC som gör mycket stora delar av applikationen testbar. /Johan