process.md

Hvordan arbejder en udvikler med en opgave?

Formål

Formålet med dette dokument er at komme med et oplæg til, hvordan man som udvikler kan arbejde med en opgave.

En ny opgave ankommer

Ligegyldigt hvordan en ny opgave ankommer, er der nogle ting, der skal være på plads, inden man går i gang med opgaven.

Følgende spørgsmål bør man stille:

• Hvilke ubekendte er der i opgaven?
• Hvis der er UI, hvordan skal det se ud/opføre sig?
  • Skal der laves design på det?
• Går ønsket i opgaven i konflikt med eksisterende dele af systemet?
• Hvilke eksterne integrationer skal der bruges?
  • Er der nogle potentielle blokere ved integrationen?
• Er projektet let at gå til, eller skal jeg forhøre mig

Opgavebeskrivelsen

Når man har styr på opgaven skal man beskrive opgaven og komme med en løsningsbeskrivelse.

Skabelon

#### Opgavebeskrivelse

-- Beskriv hvad der skal løses --

#### Løsningsbeskrivelse

-- Beskriv hvordan opgaven skal løses --
-- Overvej hvilke trin, der skal til for at løse opgaven --

#### Opgaver

-- Split op i opgaver --

* Opgave 1: ...
* Opgave 2: ...

#### Krav

-- Er der nogle krav der skal opfyldes for at opgaven kan påbegyndes/løses? --

#### Risikofaktorer

-- Er der risikofaktorer ved opgaven og hvilke mulige konsekvenser har de? --

#### Hvordan skal det testes?

-- Beskriv hvordan man løsningen testes --

#### Dokumentation

-- Beskriv hvilke dokumentationsopgaver opgaven afstedkommer --

#### Estimat

-- Estimat på hver opgave og tilføj et samlet estimat --
-- Beskriv usikkerhed for hver opgave --

Når opgavebeskrivelsen er færdig skal den godkendes. Hvis der dukker spørgsmål op når opgaven beskrives, skal disse afklares før man går videre.

Opgavebeskrivelsen og estimatet afleveres til en projektleder.

Når opgaven skal løses

Opret feature branch og Draft Pull Request

Opret en feature branch ud fra develop branchen (feature/{ticket-id}-{feature-name}).

Opret et Draft Pull Request for feature branchen.

PRet skal indeholde Opgavebeskrivelsen.

Billet til tidsregistrering

Sørg for at have en billet til tidsregistrering.

Billetten skal have et link til Draft PRet.

Tilføj Opgavebeskrivelsen til billettens beskrivelsesfelt.

Tegn hvilket flow der skal laves

Lav en tegning af, hvordan du forestiller dig at løse opgaven.

Tilføj tegningen til Draft PRet.

Genbesøg opgavebeskrivelse og estimat

På dette tidspunkt, er der som regel gået noget tid siden opgaven blev beskrevet og estimeret. I denne periode kan der være kommet svar på nogle af de ubekendte og der kan være kommet nye spørgsmål til. Man skal derfor justere opgavebeskrivelse og estimere opgaven igen før man går i gang.

Skriv pseudokode

Når man man er klar til at kode, er det en god ide at skrive pseudokode i kommentarer i koden. Her kan man formulere det flow man har tænkt for løse opgaven.

Disse pseudokode-kommentarer kan efterfølgende efterlades i koden, som dokumentation for løsningen af opgaven.

Interfaces

Hvis koden indeholder integrationer til eksterne tjenester, skal der oprettes interfaces til disse tjenester. Interfaces skal dokumenteres både på klasseniveau (hvad bruges interfacet til?) og på metodeniveau (hvad gør de forskellige metoder og deres parametre?).

Tests af interfaces

Når der er formuleret interfaces er det oplagt at skrive tests til disse interfaces.

Tests kan efterfølgende bruges til at sikre, at man overholder kontrakten fra interfaces.

Hvis der skal kaldes eksterne tjenester skal disse mockes så al kode der testes ligger lokalt tilgængeligt.

Skriv koden fra en ende af

Start fra starten af pseudokoden og implementér planen.

Tilføj TODO: {beskrivelse} kommentarer i koden, når der dukker noget nyt op der skal håndteres.

Opdatér beskrivelsen i PRet

Når opgaver løses skal de streges ud i opgavelisten i PRet.

Når der dukker nye opgaver op skal de tilføjes til opgavelisten.

Hvis man rammer et problem

Hvis man sidder fast i et problem i mere end 1-2 timer, skal man række ud til kollegaer for at få perspektiver på problematikken.

Hvis man rammer et problem under implementeringen skal man overveje, hvilke konsekvenser det har for estimatet af opgaven. Hvis man er på vej mod en opgave der løber over estimat skal projektlederen underrettes.

Afslutning

Opdatér CHANGELOG.md

Tilføj en ny linje i CHANGELOG.md med beskrivelsen af opgaven og et link til PRet.

E.g.

- [#330](https://github.com/{organization}/{project}/pull/330)
  - Fixed bug with X in Y

Pull request og code review

Når featuren er færdig skal PRet gå ud af "Draft" tilstanden.

Sørg for at kigge alle kodeændringerne igennem før en anden udvikler skal gennemgå koden.

Ret eventuelle problemer med PRet.

Sørg for at have registreret tid

Al forbrugt tid skal være registreret på opgaven.

Test og release

Procedure

1. Merge feature branchen ind i develop branchen
2. Opret release branch ud fra develop branchen (release/{version})
3. Opdatér CHANGELOG.md med versionen.
4. Opret release PR fra release branch til main (Release x.y.z). Tag PRet med "release".
5. Læg release branch til test på staging.
6. Når releasen er godkendt merges release branchen til main.
7. Tag versionen i main branchen.
8. Deploy tag i produktion.

Upgrade log

Hvis en release introducerer breaking changes, så skal upgrade.md opdateres med instruktioner for, hvordan man opgraderer.

Tjekliste

• Ny opgave
  • Hvilke ubekendte er der?
  • Skal der laves UI?
  • Integrationer til eksterne systemer?
  • Sværhedsgrad
• Opgavebeskrivelse
  • Beskrivelse af opgave
  • Beskrivelse af løsning
  • Opgaver
  • Risikofaktorer
  • Hvordan skal det testes?
  • Dokumentation
  • Estimat
• Når opgaven skal løses
  • Opret feature branch og Draft Pull Request
  • Opret billet til tidsregistrering
  • Tegn hvilket flow der skal laves
  • Genbesøg opgavebeskrivelse og estimat
  • Skriv pseudokode
  • Tilføj interfaces
  • Tests af interfaces
  • Kod løsningen og evaluér løbende resterende opgaver
• Afslutning
  • Pull request og code review
  • Registrer tid
• Test og release
  • Procedure
  • Upgrade log