Hoe was de code review procedure georganiseerd in jouw team?

We hebben gezamenlijke ontwikkeling gebruikt met behulp van het versiebeheersysteem Git en platforms voor het beheer van repositories (bijvoorbeeld Bitbucket of GitLab). Het code review-proces werd als volgt georganiseerd:

1. Aanmaken van een branch: De ontwikkelaar maakt een aparte branch voor een nieuwe functie of bugfix (git checkout -b feature/my-new-feature).
2. Ontwikkeling en commits: Wijzigingen worden aangebracht in de branch en vastgelegd met commits (git add ., git commit -m "Initiële functiemplemteering").
3. Push naar de remote repository: De branch wordt naar de remote repository gepusht (git push origin feature/my-new-feature).
4. Aanmaken van Pull/Merge Request: De ontwikkelaar maakt een Pull Request (op Bitbucket) of Merge Request (op GitLab), waarbij de doelbranch wordt aangegeven (bijvoorbeeld develop of main). In de beschrijving wordt een korte samenvatting van de wijzigingen gegeven, links naar taken in de tracker (Jira, Trello, enz.) en bijgevoegde bestanden (screenshots, video's, diagrammen).
5. Toewijzen van reviewers: Eén of twee ontwikkelaars uit het team worden toegewezen om de review uit te voeren.
6. Reviewproces: De reviewers bekijken de wijzigingen in de Pull/Merge Request. Ze kunnen opmerkingen achterlaten, verbeteringen voorstellen, vragen stellen.

   // Voorbeeld van een opmerking tijdens de review
   function fetchData() {
     // Mogelijk moet hier foutafhandeling worden toegevoegd
     return fetch('/api/data');
   }
   

7. Aanpassingen na review: De ontwikkelaar brengt de benodigde wijzigingen aan op basis van de opmerkingen van de reviewers en maakt nieuwe commits.
8. Bijwerken van de Pull/Merge Request: De wijzigingen worden automatisch weergegeven in de Pull/Merge Request na het pushen naar de remote repository.
9. Herhaalde review: De reviewers bekijken de wijzigingen opnieuw en geven hun goedkeuring.
10. Samenvoegen van de branch: Na goedkeuring wordt de branch samengevoegd met de doelbranch (meestal automatisch door het platform na het doorlopen van de CI/CD-pipeline).

We gebruikten ook CI/CD-pipelines om automatisch unit-tests, statische code-analyse (ESLint, Prettier) en de build van het project uit te voeren voordat de merge plaatsvond, wat hielp om fouten in een vroeg stadium te detecteren.

De criteria voor een succesvolle review omvatten:

• Naleving van de taakvereisten.
• Volgen van de code-stijl van het team.
• Aanwezigheid van unit-tests voor kritische logica.
• Afwezigheid van duidelijke fouten en "workarounds".
• Leesbaarheid van de code voor andere teamleden.