Vad tänka på vid flerpersons hobbyprojekt

Hej där!
Jag läser Kandidatprogrammet i Datavetenskap där jag är inne på mitt andra år.
Tillsammans med 3 andra i klassen så har vi planer på att skapa ett lite större projekt,
antingen en app eller något program. Vad har vi inte kommit fram till ännu.

Men vi har ännu inte riktigt lärt oss hur det fungerar i arbetslivet, eller hur man gör när man skall blanda in flertalet
personer. Hittills har vi varit antingen själva eller i par. På två personer så kan man ju dela upp så en sköter det
grafiska och en logiken t.ex. Men hur kan man dela upp någonting i 4? Hur skall vi dela med oss av alla kod mer än
att man använder sig av github? Skapar man projekt där på något särskilt sätt när man är många personer t.ex?

Ge gärna så mycket tips som du bara kan komma på!

Ni behöver definitivt använda versionshantering; jag föreslår Git. Ni kommer vinna mycket på att använda Git "på riktigt" (till skillnad från git add .; git commit -m "Moar changez"; git push); jag rekommenderar git diff, git add -p, git show och att generellt ha en "whitelistapproach" när ni checkar in ändringar.

Ni lär vilja ha ert repo på en molntjänst (GitHub, GitLab, Bitbucket, …) – hur de skiljer sig från varandra och om det spelar någon roll för er vet jag inte riktigt. Jag har egentligen bara erfarenhet av GitHub och Azure DevOps, och för mig funkar det utmärkt att ha mina projekt på GitHub. Att arbeta tillsammans där är inte svårare än att skapa ett repo som man ger alla i gruppen rättigheter att pusha till.

Jag rekommenderar att ha någon typ av policy som hindrar er från att merge:a in åtminstone uppenbart dåliga ändringar (tänk syntaxfel, statiska typfel etc) i master, annars kommer ni garanterat råka göra det förr eller senare. Detta har GitHub utmärkt stöd för genom GitHub Actions – till exempel ser den här filen, tillsammans med en policy jag har satt i GitHubs GUI, till att all kod måste lintas, testas och byggas innan den kan merge:as. Rent praktiskt måste man – även jag! – skapa en branch, pusha den, skapa en PR baserad på den och vänta tills valideringsbygget gått igenom. Först därefter kan PR:en accepteras och merge:as.

Det kan även vara lämpligt att kräva att minst en annan person i gruppen godkänner varje ändring innan den kan merge:as. Att granska varandras ändringsförslag noggrant och seriöst tenderar att minska mängden dåliga ändringar som slinker in på master avsevärt.

Vad som inte ännu rörts av svaren ovan är hur ni ska dela upp arbetet - det är inte svårt alls.

För att nämna hur vi jobbar på vårt jobb så kör vi sprintar (2 veckor). Inför varje sprint planeras in vad som ska göras och dessa delas upp i rimligt stora tasks. Sedan plockar man bara det man känner för att göra (om det inte finns vissa tasks man måste börja med för att "låsa upp" andra tasks).

Det är också bra om ni skapar upp en board med tasks och krav på vad ni ska bygga. Det ger en tydligare bild på er vision och vad som faktiskt behövs för att nå dit. Kolla upp lite om Scrum, sen behöver man inte köra processen fullt ut då man labbar på hobbynivå. Men det är ett vanligt arbetssätt ute i arbetslivet, så lika bra att börja bli bekväm med det.

Jag förklarade det bara inte djupgående utan hänvisade till att läsa på om scrum.