Deze Code Standaarden en Definition of Done is geschreven door @DevanStrife

Inleiding

In dit document worden de code standaarden en de definition of done voor ons project beschreven. Dit is bedoeld om ervoor te zorgen dat we consistent en kwalitatief hoogwaardig werk leveren. In dit project gebruiken we GitHub met drie branches: Front-end, Back-end en Operations. Elke branch heeft een eigen pull request reviewer die verantwoordelijk is voor het testen en goedkeuren van de pull requests. Er is ook een persoon verantwoordelijk voor alle branches. Ons team gebruikt SCRUM en taskboards om onze workflow te beheren.

Code Standaarden

Algemene Richtlijnen

• Code moet duidelijk en leesbaar zijn.
• Gebruik betekenisvolle namen voor variabelen, functies en bestanden
• Vermijd duplicatie van code (DRY - Don't Repeat Yourself)
• Schrijf unit tests voor nieuwe functionaliteiten.
• Documenteer complexe stukken code en gebruik commentaar waar nodig. (Dit kan in eigen woorden zolang de functie van de code duidelijk is in Algemeen Nederlands)

Specifieke Richtlijnen per Branch

Front-end

• Volg de gekozen front-end framework conventies.
• Zorg ervoor dat de UI responsief en toegankelijk is.

Back-end

• Volg de gekozen back-end framework conventies.
• Zorg voor goede error handling en logging.
• Optimaliseer database queries en gebruik migraties.

Operations (IaC)

• Zorg voor duidelijke en herhaalbare deployment scripts.
• Gebruik configuratiebestanden voor omgevingsspecifieke instellingen.
• Monitor en log cruciale systeemprocessen en applicaties.

Definition of Done

Algemene Criteria

• Alle geaccepteerde user stories moeten volledig geïmplementeerd zijn.
• Code is gereviewed en goedgekeurd door de verantwoordelijke reviewer.
• Alle unit tests zijn geschreven en geslaagd.
• Er zijn geen openstaande bugs of problemen.
• Documentatie is bijgewerkt waar nodig.

Specifieke Criteria per Branch

Front-End

• De UI is getest in de meest voorkomende browsers en apparaten.
• Er zijn geen styling- of lay-out fouten.
• De code voldoet aan de accessibility standards.

Back-end

• API endpoints zijn getest met unit en integratie tests.
• Database schema wijzigingen zijn doorgevoerd en getest.
• Er is een rollback plan voor database wijzigingen.

Operations

• Deployment scripts zijn getest in een staging omgeving.
• Monitoring en logging zijn ingesteld en getest.
• Back-ups zijn gemaakt en getest.

Pull Request Proces

Aanmaken en Goedkeuren van Pull Requests

• Maak een pull request aan zodra een taak klaar is om te worden gereviewed.
• Voeg een beschrijving toe van de uitgevoerde wijzigingen en link naar relevante issues.
• Wijs de pull request toe aan de verantwoordelijke reviewer.
• De reviewer test en beoordeelt de code, en geeft feedback indien nodig.
• Pas wijzigingen aan indien nodig en vraag om een herbeoordeling.
• Zodra de pull request is goedgekeurd, kan deze worden gemerged.

Rollen en Verantwoordelijkheden

• Branch Reviewers: Verantwoordelijk voor het testen en goedkeuren van pull requests in hun toegewezen branch.

Front end Branch	Vigo Luthjens
Back end Branch	Lotte Soudant
Operations Branch	-

• Github Manager: Zorgt ervoor dat alle branches consistent blijven en overziet de integratie van de verschillende onderdelen.

Github Manager: Dèvano Fout

SCRUM en Taskboards

SCRUM

• We gebruiken SCRUM om ons werk te organiseren en iteratief voortgang te boeken.
• Elke sprint begint met een sprint planning en eindigt met een sprint review en retrospective.

Taskboards

• Taken worden aangemaakt en bijgehouden op een taskboard.
• Taken worden toegewezen aan teamleden en geüpdatet tijdens de dagelijkse stand-ups.
• De voortgang van taken wordt gevolgd en zichtbaar gemaakt voor het hele team.