review 1

[PatNei]

https://github.com/ITU-BDSA2024-GROUP15

Notes during the session

• En branch til issue (nogle gange flere)
• merger i main
• sletter dem
• har project ikke offentligt
• Gruppe 15s url var taget

gruppe 15

Er alle til stede i dag?

• marho
• mofb
• mawc
• iast
• kwad (ikke til stede)

Introduktion

3 Reviews. De bliver meget casual, vi gemmer alt debugging af kode og problemer til TA sesh (medmindre vi har meget god tid)

Sessions vil køre sådan at jeg har kigget jeres repositories/projekt igennem efter nogle ting Helge har bedt os om at holde øje med.

Ser jeg noget der har brug for forbedring så vil jeg nævne det eller hvis jeg har nogle spørgsmål til nogle ting / processor.

Hvis jeg virker meget negativ så er det fordi vi kun har 20 minutter og jeg vil gerne nå at give jer så meget konstruktiv feedback som muligt. Det betyder at jeg vil gå meget hurtigt igennem eller skippe steder hvor det går godt.

Jeg har en dårlig vane med at blande engelsk og dansk sammen når jeg laver de her reviews så forvent at det er et mixture af begge ting medmindre i beder om at det skal være på engelsk.

Branching strategi

• Laver i små branches til hver feature?
• Sletter i dem efter?

Issues (altså github issues)

Laver i alle lige mange issues?

• Kassandra 2
• Mortfb 3
• Powsdaws 8
• Sukinekoo 1
• VernesNemo 5

En strategi er at man hver gang man får næste uges exercises, sidder i en gruppe og kigger på opgaverne for ugen, laver dem om til user stories(issues) og så går man derefter igang med at kode.

user stories

De issues jeg har set følger user story strukturen og har et klart defineret acceptance criteria.

fandt en enkelt som måske er meget god at snakke om https://github.com/ITU-BDSA2024-GROUP15/Chirp/issues/11

As a developer I want to convert our csv database to a singleton to ensure consistency

pas på med de her vage beskrivelser som ensure consistency.

Husk fra session 2.

Ask yourself if it…

- is something of value to customers.
- **avoids jargon or mumbo jumbo**. A non-expert should be able to understand it.
- “slices the cake,” which means it goes end-to-end to deliver something of value.
- is independent of other issues if possible. Dependent issues reduce the flexibility of scope.
- is negotiable, meaning there are usually several ways to get to the stated goal.
- is small and easily estimable in terms of time and resources required.
- **is measurable**; you can test for results.

Det kan være at der var en god grund til at skrive consistency til det her issue, men have det i mente når i skriver user stories :)

Intet projects eller måske intet offentlig projects?

• I skal gøre det offentlig så vi TA's / Helge kan følge med :)
• Bruger i noget automation til jeres github project?

Automation (Workflows)

Det ser ud til at i har workflows til

• test
• build and release

godt arbejde! I skal på et tidspunkt gerne have en til automatisering af github projects.

Testing

Unit testing

Hvordan går det med at teste? Kan se at det måske er lidt svært at teste en CLI applikation, især det at den printer til stdout.

Hvad med jeres databases metoder bliver de testet?

Integration testing

--

E2E testing

--

generelt testing

Jeres testing kunne godt bruge lidt kærlighed. Testene er jeres største hjælp med et bad release / deploy, de kan kun hjælpe jer hvis i tillader dem. Det er derfor de er med i workflows.

Projektet er lige startet der skal nok komme tid til at lave det men husk at få det gjort.

Det er noget Helge kigger på. Code coverage etc er ikke så vigtigt, det er vigtigt at får testet jeres core functionality.

Ingen DB web service endnu

Det fint! Vi forventer ikke at i færdige med det endnu, så hvordan går det med det?

Incremental steps

Generel feedback til alle grupper: Commits bør være små og lave en smule værdi og SKAL ikke være en stor mængde funktionalitet der bliver merget ind i slutningen af dagen.

commits

• Powsdaw har lavet 88 commits
• Sukinekoo har lavet 17 commits.

Laver i alle lige mange commits?

Hvis i har lavet noget sammen så brug co-author systemet på github og skriv hinanden på. Det er vigtigt! Kan se at i allerede bruger det, så det er godt!

Der kan være mange grunde til at fordelingen er sådan og bare rolig der ikke noget stress over det, men i bør tænke over det fremadrettet.

Det er noget Helge vil undre sig over til eksamen :)

Ai tools

lige så vigtigt er det at hvis i bruger nogle AI tools, co-pilot, chatgpt. w/e så skal de på som co-authors ellers kan det i værste tilfælde ses som plagiat.

Ved ikke om i bruger nogle, jeg kun umiddelbart ikke se nogen reference til det endnu. Dette er noget alle grupper får at vide :)

[PatNei]

The point is to make the GitHub issue well-defined for everyone involved: it identifies the audience (or user), the action (or task), and the outcome (or goal) as simply as possible.