Code Review

Principes

Chaque MR doit etre reviewee par au moins un autre membre de l'equipe avant le merge.

Checklist de revue

Architecture

• [ ] Le code respecte la Clean Architecture (pas d'acces direct au repository depuis le controller)
• [ ] Les couches sont respectees : controller → use-case → repository → entity
• [ ] Pas de logique metier dans les controllers

Qualite du code

• [ ] TypeScript strict — pas de any sans justification
• [ ] Pas de code duplique (verifier si un utilitaire existe deja dans @nex/shared-utils)
• [ ] Les imports sont coherents (pas de mix old/new design system dans un meme fichier)
• [ ] Les constantes CEMAC (devises, pays) utilisent @nex/shared-utils

Securite

• [ ] Pas de secrets en dur dans le code
• [ ] Les inputs utilisateur sont valides
• [ ] Pas de faille d'injection (SQL, XSS, command injection)

Tests

• [ ] Les use-cases critiques sont couverts par des tests unitaires
• [ ] Les tests passent localement (pnpm --filter "./services/<name>" run test)

Conventions

• [ ] Les commits suivent la convention
• [ ] Le nom de branche commence par le ticket Jira
• [ ] Une branche = un ticket = une MR

Processus

1. Le dev cree la MR et assigne un reviewer
2. Le reviewer parcourt le code et laisse des commentaires
3. Le dev corrige et repousse
4. Le reviewer approuve → merge dans develop