Laboration 2 — Skriv en modul, inte en app

Deadline:Onsdag 30 september 2026 kl. 17.00

Välkommen till laboration 2! Här skriver du en modul — kod som är tänkt att återanvändas av andra programmerare, till skillnad från en app med egna slutanvändare. Från och med den här laborationen är GitHub obligatoriskt för din kod (se Verktyg och plattformar); din inlämning sker precis som tidigare via en Merge Request i ditt privata GitLab-repo, med fem reflektioner om kodkvalitet och en testrapport som pushas tillsammans med koden på GitHub (se Redovisning för alla detaljer).

Syfte

Skriva kod för en modul, och därmed börja skifta fokus från att bara “lösa ett problem” till att också “kommunicera din lösning som kod”. Att effektivt kommunicera sin lösning underlättar både lösandet av problemet och samarbetet med andra.
Skriva kod som ska återanvändas av dig själv och andra programmerare.
Arbeta med din kodkvalitet och använda innehållet i kursboken som reflektionsunderlag.

Under laborationen kommer du arbeta med kapitel 2 och 3 (2:a upplagan: kapitel 4 samt 7–11) i boken Clean Code.

En “modul”

Du har tidigare skrivit appar som driftsatts för att användas av slutanvändare. Då är kvalitet i funktionalitet viktigt, att appen fungerar som den ska.

I den här laborationen ska du istället skriva kod som ska användas av andra programmerare, en “modul”, och då är kvalitet i själva koden viktigt.

Moduler kan ibland kallas bibliotek (eng. libraries), alltså kod som används för att skriva appar men i sig inte är en egen app. Du har tidigare importerat paket för att få tillgång till funktioner och klasser som löst olika problem åt dig.

import { Jpeg } from 'jpeg-lib'

// Loads image into a Picture instance
const jpeg = new Jpeg()
const picture = jpeg.load('funnycat.jpg')

const height = picture.getHeight()
const width = picture.getWidth()

// Extracts the center pixel as a Pixel instance
const centerPixel = picture.getPixelAt(width / 2, height / 2)

// Print RGB to console
console.log(centerPixel.r, centerPixel.g, centerPixel.b)

Exempelkod för hur jpeg-lib’s gränssnitt skulle kunna se ut. Paketet ger möjlighet att läsa bildfiler och få ut värden ur dessa.

Som du ser ovan exporterar jpeg-lib klassen Jpeg. En instans av den, jpeg, har metoder som skapar och returnerar picture- och pixel-objekt. Dessa har i sin tur egna metoder som användaren av biblioteket kan använda. Olika programmerare kan använda jpeg-lib för att få funktionalitet till exempelvis bildbehandlingsappar eller spel. Skillnaden mellan ett bibliotek och en app är alltså att målgruppen för en modul är andra programmerare, inte slutanvändaren av en app.

Fler exempel finns att hitta på internet. Tänk på att flera av dessa är för omfattande och komplicerade för den här laborationen. Du behöver hitta en lagom nivå på din modul utan att återanvända någons kod. Mer om storleken på ditt bibliotek kommer längre ner.

För exempel på existerande JavaScript-bibliotek, se kinsta.com/blog/javascript-libraries.

För exempel på Java-bibliotek, se wearedevelopers.com/magazine/best-java-libraries.

Laboration 3 bygger vidare på laboration 2

Laborationen 2 och nästföljande laboration 3 hör ihop, se figur 1 nedan. Din modul från den här laborationen (grön i figur 1) ska vara till nytta för dig i nästa laboration. Där skriver du en enkel app som riktar sig till slutanvändare och som använder din modul.

Figur 1. Grön ruta är modulen du skriver i den här laborationen. Den testar du den här iterationen med en Test-App. Under laboration 3 använder du din modul för att bygga en app, samtidigt som andra studenter använder din modul för att bygga sina egna test-appar.

Du skulle till exempel kunna skriva en modul i den här laborationen som skapar olika typer av diagram utifrån data (t.ex. stapeldiagram, boxplots). För att veta att modulen fungerar skriver du en liten test-app som ritar ut diagram med testdata.

I det exemplet skulle du sedan i nästa laboration kunna skapa en app som hämtar temperaturdata från ett API och använder modulen för att visa diagram för olika orter som användaren väljer.

Du kommer även prova på att använda andra studenters moduler.

Mål med din modul

Eftersom det är stor frihet att välja vilken typ av funktionalitet din modul ska innefatta, följer här några mål som hjälper dig hitta rätt nivå och fokusera på rätt saker. Sammanfattningsvis ska du uppfylla följande mål:

Skriva en modul och inte en app.
Den ska ha lagom storlek och komplexitet.
Den ska vara väl testad.
Den ska följa kodkvalitetskraven (se Kodkvalitetskrav nedan).
Ett reflektionsdokument, REFLECTION.md, ska finnas (se Redovisning nedan).

Skriva en modul och inte en app

Målgruppen för modulen är andra programmerare. Se till att hitta något som är till nytta för någon. Fundera på vad din USP (Unique Selling Point) är och beskriv med några meningar vad ditt bibliotek gör och inte gör. Detta kan behöva justeras något under arbetets gång, så att modulen blir tillräckligt stor för att uppfylla laborationens krav men tillräckligt liten för att du ska hinna både lösa uppgiften och kommunicera och reflektera över lösningen.

Driftsättning ska ske så att andra programmerare kan använda ditt bibliotek — publikt på github.com eller npmjs.com.

Fundera över hur din kommunikation med de programmerare som ska använda din modul ska ske. Titta gärna på andras bibliotek för inspiration, och diskutera gärna i Zulip.

Några saker som är bra om de finns:

Dokumentation (README.md)
Kodexempel
Installationsbeskrivning
Kommunikation om beroenden, språk och versioner
Testrapporter
Buggrapporter/issues
Information om licens för öppen källkod
Versionsnumrering och releaser
Kommunikation om hur användare kan bidra till projektet

Fundera över vilka metoder och klasser som är tänkta att användaren ska använda. Försök förenkla för denne så att modulen blir lätt att använda och lätt att lära sig. Fundera också på vilka klasser/metoder/filer som användaren (programmeraren) inte ska behöva röra, titta på eller ändra i, och hur du döljer det som användaren helst inte ska behöva se.

Lagom storlek och komplexitet

Undvik för enkla eller för komplexa problem. Vad som är “lagom” är dock individuellt. Du måste tro att du själv kan klara av hela uppgiften utan att generera, skriva av eller kopiera kod från någon annan.

Räkna med ungefär 40 timmars arbete med koden — det kan förstås skilja sig mellan olika studenter. Undvik något där du lockas att kopiera kod från en existerande lösning (även dina egna tidigare lösningar). Förlita dig inte på andra moduler (dvs. andra bibliotek) utan försök hitta ett problem som främst hanteras av din egen kod. Bygger din kod till exempel på ett API, bör du inte bara göra ett nytt interface till API:et utan tillföra någon typ av egen funktionalitet.

En ungefärlig storleksangivelse för din modul (Test-App ingår ej i detta):

Minst fem meningsfulla klasser/metoder i det publika interfacet
Minst tio kontrollsatser (if, for, while) som används för att lösa huvudproblemet
Minst 200 rader egen kod som används för att lösa huvudproblemet
Undvik att mappa eller översätta existerande bibliotek
Tillräckligt för att uppfylla kodkvalitetskraven, se egna rubriker

Använd ett språk och en programmeringsmiljö som du har erfarenhet av, så att du kan fokusera på kodkvalitet och inte andra saker.

Verifiering och validering av din modul

För att nå samförstånd om kodens funktion behöver den testas. HUR detta sker är mindre viktigt än ATT det sker. Det finns tre huvudalternativ (fler varianter kan finnas). Oavsett val redovisar du detta med en testrapport i markdown-format där det tydligt framgår vad som är testat, hur det är testat och vilket utfall det fick.

Du testar din kod genom att skapa ett användargränssnitt (webb, konsol, ui) i en separat Test-App. Du skapar manuella testfall, går igenom varje testfall, matar in indata och observerar utdata manuellt, och jämför med förväntat utdata. Du dokumenterar din testning i en testrapport i markdown-format.
Du skapar en testapplikation som automatiskt kör varje test för sig, och observerar testernas utfall antingen med kod eller manuellt. Antingen låter du testerna i testapplikationen vara dokumentationen, eller så skapar du en testrapport i markdown-format.
Du skapar automatiska enhetstester för din modul med hjälp av ett testramverk. Du kör dessa och redovisar resultatet med en testrapport i markdown-format. Du kan länka in eventuella testrapporter från testramverket eller ta screenshots och inkludera i din testrapport.

Skriv en kort summering om hur modulen testats — tillräckligt tydligt för att någon annan ska kunna utföra samma test. För testresultaten, skapa en tabell i markdown-format med tre kolumner. Varje rad blir ett test:

Vad som testats (t.ex. metodnamn eller krav)
Hur det testats
Testresultat

Kodkvalitetskrav

Eftersom laborationen påbörjas innan många av föreläsningarna har hunnit ske, begränsas mängden kodkvalitetskrav i den här inlämningen till det som tas upp i kapitel 2 och 3 (2:a upplagan: kapitel 4 samt 7–11). Det är viktigare att reflektera och återkoppla till boken än att din kod är perfekt. Det krävs alltså inte att du justerar din kod, men väl att din reflektion visar förståelse för kursmaterialet. Du får antingen ändra din kod eller leva vidare med den — bristen ska då anges i din reflektion.

Namngivning (kapitel 2 / 2:a upplagan: kapitel 4)

Läs kapitel 2 i Clean Code. Skapa en tabell över fem namn på identifierare (t.ex. namn på klasser, metoder och variabler) som finns i ditt publika interface. Det publika interfacet är alltså den kod som andra programmerare ska använda. Utgå från kapitel 2s titlar och ange de viktigaste “reglerna” som applicerats eller skulle kunna appliceras på just ditt namn. Försök variera vilka regler du analyserar mellan namnen, så att inte alla har samma regel-titlar applicerade. Visa att du förstår flera regler, inte bara ett par.

Skriv även en kort reflektion kring innehållet i kapitel 2. Du kanske upptäcker en brist hos din tidigare namngivning, eller håller inte med om någon av “reglerna” från kursboken. Det är bättre att du hittar och reflekterar över dina brister än att du döljer dem.

Exempel

Namn	Förklaring	Reflektion och regler från Clean Code
Tokenizer2000	Klassnamn på huvudklassen i modulen	Avoid Disinformation: 2000 betyder inget speciellt och tillför därför inget till namnet. Don’t Be Cute: Namnet kan verka sött men är vilseledande. De som inte är millennium-romantiker kan missa det roliga. Bara “Tokenizer” är ett tydligare namn. Jag väljer dock att behålla Tokenizer2000 eftersom användare redan använder min modul
boolean TokenMatch.isBetter(other)	Metodnamn på metod som avgör om en tokenmatchning är bättre än en annan baserat på maximal munch.	Method Names: Is hintar att returvärdet är boolskt. Argumentet och metodnamnet är tänkt att läsas som “is this better (than) other”. Use Problem Domain names: Better är oklart i kontexten och borde bytas ut mot namnet “Maximal munch” som problemdomänen använder MEN detta är inte säkert att programmeraren som ska läsa är insatt i detta, därför bör vi istället använda “Solution Domain”. Use Solution Domain names: hasMoreMatchedCharacters är ett tydligare namn och kräver inte att läsaren vet om Maximal munch.

Funktioner (kapitel 3 / 2:a upplagan: kapitel 7–11)

Läs kapitel 3. Skapa en tabell över dina fem längsta metoder/funktioner. Utgå från kapitel 3s titlar och ange de viktigaste reglerna (som följs/bryts). Föreslå förändringar.

Skriv även en kort reflektion kring innehållet i kapitel 3. Du kanske upptäcker en brist hos din tidigare skrivning av funktionerna, eller håller inte med om någon av “reglerna” från kursboken. Det är bättre att du hittar och reflekterar över dina brister än att du döljer dem.

Metodnamn	Länk eller kod	Antal rader (ej ws)	Reflektion
boolean TokenMatch.isBetter(other)	Se kodexempel nedan	4	Do one thing: Metoden gör en sak — avgör vilken av de två matchningarna som ska vinna vid maximal munch — även om det sker i två steg (längd, sedan prioritet som tie-break). Function Argument: Metoden har bara ett argument (monadic). Eftersom jag har skrivit i javascript vore det bra att typen på argumentet other framgår via exempelvis en metodkommentar. Common Monadic Form: Vi ställer en fråga om argumentet, är this bättre än other, och metoden gör endast då en “query” (Command Query Separation) och ändrar inte värdet på objektet eller argumentet. Båda grenarna returnerar själva jämförelseuttrycket direkt istället för att förgrena med if/else och returnera true/false.

isBetter(other) {
  if (this.#length !== other.#length) {
    return this.#length > other.#length
  }

  return this.#priority < other.#priority
}

Exempelkod för TokenMatch.isBetter.

Reflektion

Skriv en kortare reflektion (cirka 250 ord) där du beskriver dina erfarenheter från din egen kodkvalitet. Använd begrepp från boken.

Totalt är det 5 reflektioner som ska skrivas:

Tabellreflektion för namngivning
Kapitelreflektion kap 2
Tabellreflektion för funktioner/metoder
Kapitelreflektion kap 3
Reflektion över egen kodkvalitet

Du vet att du är klar när du…

…skrivit en modul som uppfyller storlekskraven och är väl testad, med en testrapport i TEST_REPORT.md på ditt GitHub-repo.
…fyllt i båda kodkvalitetstabellerna (namngivning och funktioner) med reflektioner för varje rad.
…skrivit alla fem reflektioner ovan i REFLECTION.md.
…pushat din modul till ett publikt GitHub-repo, med en commit-historik som visar ditt arbete över tid.
…skapat en MR i ditt laboration-2-repo på GitLab, med länk till GitHub-repot i beskrivningen.

Redovisning

Se Verktyg och plattformar för en genomgång av GitLab, GitHub och Zulip och hur de används i kursen.

Din modulkod och testrapport (TEST_REPORT.md) ska vara publika på GitHub — det är obligatoriskt från och med den här laborationen. En mall för TEST_REPORT.md finns förifylld i ditt privata laboration-2-repo på GitLab; flytta den till ditt GitHub-repo innan du pushar koden. Reflektionerna (REFLECTION.md) lämnas däremot in på samma sätt som tidigare, via en Merge Request i ditt privata GitLab-repo.

Redovisningen sker i tre steg innan deadline:

Koda, committa och pusha till GitHub. Skriv din modul och versionshantera den med Git mot ett publikt repo på GitHub. Flytta TEST_REPORT.md från ditt GitLab-repo till roten av GitHub-repot, komplettera den där enligt ovan, och committa den tillsammans med koden. Se till att historiken visar ditt arbete över tid (räkna med minst daglig commit).
Skriv REFLECTION.md. Komplettera och committa filen i rotkatalogen på main i ditt privata laboration-2-repo på GitLab. Den innehåller kodkvalitetstabellerna och samtliga fem reflektioner.
Skapa en MR. Skapa en MR från main till lnu/submit i ditt laboration-2-repo på GitLab. Fyll i inlämningsrapporten i MR-beskrivningen, inklusive länken till ditt GitHub-repo. Det är via MR:en som kursledningen granskar och bedömer din inlämning.

Bedömning

Kursledningen bedömer din inlämning via din MR, utifrån hur väl du uppfyller kraven ovan samt kodkvalitet. Se Betygskriterier för poängskalan och hur laborationsbetyget vägs in i slutbetyget.

För godkänd nivå “E”

Funktionell kod. All kod ska vara testad. De flesta testfall ska fungera — något enstaka testfall får misslyckas eller en känd bugg får finnas. Modulen måste dock fungera i stort. Det finns en testrapport som visar vad som fungerar och hur det är testat.
Koden är tillräckligt stor/komplex för att räknas.
Koden är förberedd för att återanvändas.
Det finns en läsbar dokumentation på GitHub.
All kod finns med historik på GitHub (räkna med minst daglig commit).
Tabellerna med kodkvalitetskrav är ifyllda, baserade på kursboken.
En reflektion är skriven baserad på vad du har lärt dig.
Du uppfyller reglerna nedan.

För högre betyg “A–D”

Samtliga punkter för godkänd nivå.
Testningen är övertygande och noggrann. De viktigaste kraven fungerar.
Koden överträffar kraven på storlek och komplexitet.
Det är mycket tydligt utifrån GitHub-repot hur modulen ska återanvändas — exempel, dokumentation och installationsanvisningar.
Det finns en tydlig separation mellan modulen som ska återanvändas och sättet den har använts för att testas — exempelvis kan test-appen ligga i en separat katalog.
Kodkvalitetskraven är varierade i vilka regler de använder. Det är tydligt hur regler, kodnamn och metoder hänger ihop.
En välskriven reflektion är skriven, baserad på erfarenheter och lärdomar från laborationen samt bokens kapitel 2 och 3 (2:a upplagan: kapitel 4 samt 7–11).

Regler

Allt du lämnar in ska du fullt ut förstå och kunna förklara — även de delar som tagits fram tillsammans med AI-assistenter (t.ex. ChatGPT, GitHub Copilot eller Claude). Sådant samarbete är tillåtet, men ska redovisas kort i REFLECTION.md (se Akademisk integritet för kursens fullständiga AI-policy).
Committa och pusha kontinuerligt under arbetets gång, så att din utvecklingsprocess går att följa på GitHub.
Kopiera inte kod från någon annan. Skriv inte av kod.
Använd inte bibliotek eller färdiga metoder för att lösa huvudproblemet, dvs. din modul. Tänker du if-satser och for-loopar, tänker du rätt. Du får använda inbyggda typer och metoder i språkets standardbibliotek, men om du behöver “installera beroenden” bör du helst undvika det — diskutera med kursledningen om du är osäker. Det är dock helt okej att använda ramverk i Test-App för att testa din modul.
Koden ska kunna delas med klasskamrater under senare laborationer och workshop. Ange licens för öppen källkod och publicera publikt på GitHub.
Koden är skriven i ett programmeringsspråk som förekommit tidigare i utbildningen. En annan student på samma program ska kunna förstå din modul utan att läsa in sig på ett ramverk.
Fokusera på objektorienterad kod med klasser och metoder i klasser. Du kan ha kod utanför klasser, men bara om den behövs för att starta upp koden (t.ex. Node.js server.listen(port…)). Inga metoder i dina klasser bör vara statiska, mer än om det behövs för att starta upp koden (t.ex. Java public static void main(...)).