Mål

Laborationens syfte är att undersöka kvalitet i källkod. Främst syftar laborationen till att förbättra kvaliteten på en låg nivå(inom en klass, textkvalitet och liknande) till skillnad mot nästa laboration som syftar till att förbättra kvaliteten på hög nivå(arkitekturell, mellan klasser och komponenter.)

Studenten skall efter avslutat laboration…

• …ha gjort code review på egen och andras kod
• …förbättrat kodkvalitet med utgångspunkt från code-review
• …utökat funktionaliteten i applikationen
• …testat och återtestat testfall efter förändring av källkod

Teori

Code reviews är vanligt använt för att förbättra kodkvalitet och hitta problem i källkod. Många företag tex google använder code reviews för att förbättra sin källkod.

Under laborationen har ni ett reviewformulär som innehåller en olika saker att granska i koden. Dessa är baserade på olika “best practices”.
En best practice kan t.ex. vara att inga rader i programmets källkod får vara mer än 80 tecken lång. Syftet är att öka programmets läsbarhet genom att hålla källkoden innanför skärmen. I många fall kan man argumentera mot regeln. Exempelvis har vi nu ofta widescreen-skärmar och jag får plats med 120 tecken med 16 punkters typsnitt. Men målet med Code-Reviews är också att likrikta kodens stil så att andra programmerare lätt kan läsa vår kod.

Under laborationen kommer vi dock vara benhårda. Vi försöker följa reglerna så noggrant som möjligt. I forumet låter vi taket vara högt och diskuterar för och nackdelar med olika best-practices.

Som Review-formuläret är upplagt består det av radioknappar och i varje fråga är det enligt mig mest önskvärda svarsalternativet överst. Om inget annat sägs i beskrivningarna gäller det att det räcker med att hitta ett enda “brott” mot regeln för att det ska räknas.

Till exempel på frågan: “Finns det rader längre än 80 tecken i koden?”, Så räcker det med en enda rad på 81 tecken i koden vi undersöker för att vi ska svara Ja på frågan.

Meningen är inte att ni under en review ska sitta och rätta koden utan detta gör ni under en senare uppgift. Under en verklig review kommenterar man ofta koden rad för rad. Eftersom källkod kan bli rätt stor brukar en review också bara göras på ändringar i koden. Dvs en commit.

Uppgift 1. Mät kvalitet på kod

Normalt sätt utförs en code-review inte bara av författaren till källkoden. Eftersom detta är en individuell uppgift kommer ni få öva på min kod innan ni gör en review på er egen kod.

Du skall mäta kvalitet på ett stycke kod jag har skrivit under stress(under lektion). Koden innehåller en hel del saker som kan förbättras. Som exempel kommer du se att jag har försökt följa ett antal best-practices men slarvat. Att använda Code-Reviews kan vara ett bra sätt att få bort slarvfel.

Ta en kopia av källkoden och markera felen så att du och laborationshandledaren kan diskutera eventuella oklarheter.

URL till källkod:

https://github.com/dntoll/1DV408CodeForReviewHT2013.git

Svara på enkäten

För att kunna svara på denna uppgift måste du vara inloggad.

Uppgift 2. Mät kvalitet i koden från laboration 1

Nu när du fått lite erfarenhet av att söka efter fel skall du göra samma sak med den kod du skrev för laboration 1.

Notera att du nu inte skall fixa problemen utan bara mäta kvaliteten hos koden genom att se vilka best practices du följer och inte följer. Du kommer få tid att ordna dina problem i nästa uppgift. I uppgift 2 gäller det att vara så hård som möjligt mot dig själv och verkligen hitta de problem som finns i koden.

Svara på enkäten

För att kunna svara på denna uppgift måste du vara inloggad.

Uppgift 3. Förbättra kvalitet i koden från Laboration 1

Det är nu dags att försöka förbättra kodkvaliteten baserat på de best-practices som din code-review visade att du inte följt.

Steg 1.

Innan du gör detta skall du se till att du har gjort en namngiven “commit” av koden i ditt versionshanterinssystem av kodbasen så att du och laborationsassistenten kan gå tillbaka och se vilka ändringar code-reviewn gav upphov till.

Steg 2.

Rätta nu de misstag och brott mot best-practices du hittat.

Steg 3.

Gör en ny commit och se till att kunna göra en diff mellan den tidigare koden och den nuvarande så du kan visa laborationshandledaren vilka ändringar du gjort.

Uppgift 4. Mer krav

Nu är det dags att lägga till nya krav till koden. Kraven till applikationen finns här (Krav) Nu gäller att samtliga 3 Use-cases skall implementeras och testas.

Uppgift 5. Testa krav

Fyll i en testrapport, Notera att detta är en individuell examinationsuppgift! Du får inte ta kod från andra. Notera också att det räknas som fusk att vilseleda vid examinationen. Exempelvis fylla i testrapporten att ett testfall uppfylls som inte är uppfyllt. Var därför extra noggrann när ni testar er applikation.

För godkänd ska alla testfall vara uppfyllda.

Notera att detta är en individuell examinationsuppgift!

Svara på enkäten

För att kunna svara på denna uppgift måste du vara inloggad.

Uppgift 6. Mät kvalitet

Mät sedan kvaliteten hos koden du skrivit. Du har möjlighet att förbättra kvaliteten i koden i nästa laboration så se till att vara hård i din mätning av kodkvaliteten.

Svara på enkäten

För att kunna svara på denna uppgift måste du vara inloggad.

Bedömningsmodell

Vi kommer titta på följande.

1. Mätvärden från Uppgift 1. Har du hittat alla brister i Daniels kod?
2. Uppgift 2. Har du hittat bristerna i din egen kod?
3. Uppgift 3. Granska diff mellan koden i laboration 1 och visa vilka ändringar du gjort för att förbättra koden. Eventuella avsteg från en best-practice måste kunna motiveras på ett sätt som övertygar laborationshandledaren(som bestämmer ifall han känner sig övertygad eller inte).
4. Uppgifterna 4,5,6 redovisas med följande
   • Testrapport som visar vilka testfall som är uppfyllda.
   • Kvalitetsrapport(code-review), som visar bristerna hos koden
   • Exekverande källkod på externt webbhotell.
   • Commit av källkod i versionshanteringssystem
   • Den egna koden laddas upp på http://demo.ticknik.com/portals/57