Att börja arbeta med kod

Det här är en fortsättning på Att arbeta i projekt. Du har nu en backlog, tidsskattningar och en identifierad risklista. Vecka 4 är veckan där kod börjar landa i repot. Den här sidan handlar om det som kommer före de första raderna produktionskod: projektskelettet, linter och kodstandard, en tydlig Definition of Done, och verktyget som heter spike.

Du arbetar ensam i ditt projekt, men använder arbetsformer som skalar till ett team. Tanken är att du övar på samma arbetssätt du kommer möta i en professionell miljö.

Projektets skelett

Innan du skriver din första egentliga funktion, sätt upp strukturen i repot:

  • Initiera projektet för din teknikstack (t.ex. npm init för Node.js, poetry init för Python).
  • Lägg in en .gitignore anpassad för ditt språk. GitLab har färdiga mallar.
  • Lägg in en .editorconfig så att alla filer har samma indentering och radslut.
  • Bestäm en grov mappstruktur: src/, test/, public/ eller motsvarande för din stack.
  • Skapa en README.md med minst en mening om vad applikationen gör och hur den startas.

Den första commiten ska vara projektskelettet, inte "första feature". Det gör det lätt att se när själva affärslogiken börjar landa.

Kodstandard och linter från dag ett

Sätt upp en linter och en autoformatterare innan koden växer. Det är mycket billigare än att införa det i vecka 6 när kodbasen är spretig.

För Node.js-projekt: ESLint + Prettier. För andra miljöer: motsvarande verktyg (Pylint + Black, Rubocop, etc.).

Commit:a in konfigurationen (.eslintrc.json, .prettierrc, .editorconfig) och kör lintern som del av din lokala arbetsloop. Samma konfiguration kommer användas i CI/CD-pipelinen i vecka 7, så ju tidigare den är stabil desto mindre friktion senare.

Din Definition of Done

Definition of Done (DoD) är en personlig kvalitetsnivå för vad "klar" betyder, oavsett vilken issue det handlar om. Det är inte samma sak som acceptanskriterier. Acceptanskriterier är per krav ("systemet ska acceptera lösenord med minst 8 tecken"). DoD är per arbete ("jag har rapporterat tid, lintern är grön, Wikin är uppdaterad").

Utan en DoD börjar "klar" glida. En vecka betyder det att koden kompilerar. Nästa vecka betyder det att något är mergat. I slutet av iterationen inser du att halva listan fortfarande kräver arbete, och att dina tidsrapporter inte går att jämföra.

Formulera din egen DoD redan nu och lägg den som en sida i din Wiki. En rimlig utgångspunkt:

Min Definition of Done

En issue är klar när:

  • Koden är pushad och mergad till main
  • Minst ett manuellt testfall är skrivet, kopplat till kravet, och passerar
  • Lintern är grön
  • Merge request är kopplad till issuen med Closes #...
  • Faktisk tid är rapporterad med /spend
  • Wikin är uppdaterad om ändringen påverkar arkitektur eller användning

Bullet-punkterna är inte heliga. Din DoD beror på ditt projekt. Revidera den i iterationsreflektionen när du märker att saker slinker igenom.

Commit ofta, commit tydligt

Små, självförklarande commits är grunden för det arbetsflöde som byggs ut i vecka 5. Två enkla vanor att ta med sig redan nu:

  • En commit ska göra en sak. Om du inte kan sammanfatta den på en rad utan ordet "och" är det sannolikt två commits.
  • Skriv commit-meddelandet så att du själv kan förstå det om tre veckor. "Fixade buggen" är värdelöst. "fix: handle empty username in login form" berättar något.

Spike: när implementationen är till för att lära sig

Veckans to-do-lista säger att du ska "jobba bort tidigare identifierade risker genom initial implementation". Verktyget för det heter spike.

En spike är en tidsbegränsad undersökning, oftast en halv eller en hel dag, där målet inte är att leverera fungerande kod utan att svara på en fråga. "Klarar mitt val av bibliotek OAuth-inloggning?" "Hur känsligt är MongoDB-schemat för tusen poster?" Du bygger en liten proof-of-concept, du svarar på frågan, och sedan slänger du koden eller skriver om den ordentligt.

Poängen är att minska risken att något visar sig vara omöjligt, långsamt eller dyrt, innan du hunnit investera i riktig implementation. Rapportera utfallet av spiken i din iterationsreflektion.

Nästa steg

När skelettet är på plats och DoD är skriven är det dags för den dagliga loopen: hur du går från en issue i iterationen till mergad kod. Det flödet finns i Jobba med Git (vecka 5).