La Revue de Code : Types, Organisation et Bonnes Pratiques

1. Les Types de Revue de Code

Il existe plusieurs types de revue de code, chacun ayant des objectifs spécifiques. Voici les principaux :

a. La Revue de Code Ad Hoc

Cette revue est informelle et souvent réalisée sur des petites modifications. Le développeur peut demander à un ou deux collègues de jeter un œil à son code sans procédure stricte. Ce type de revue est rapide mais peut manquer de rigueur si les relecteurs sont peu attentifs.

b. La Revue de Code en Mode Pull Request (PR)

C’est la méthode la plus courante avec GitHub et GitLab. Une PR est soumise lorsqu’une nouvelle fonctionnalité, une correction de bug ou une amélioration est prête. Un ou plusieurs développeurs examinent la PR avant qu’elle ne soit fusionnée dans la branche principale. 

c. La Revue de code synchrone

Il s’agit d’une revue effectuée en temps réel, souvent via des outils de pair-programming ou de partage d’écran. Cette approche est utile pour les projets critiques ou urgents, mais elle nécessite la disponibilité simultanée des deux parties.

d. La Revue de code automatisée

Avec l’aide d’outils comme SonarQube ou les pipelines CI/CD de GitLab, certaines vérifications (tests, linting, analyse de sécurité) sont automatisées afin de détecter des problèmes élémentaires avant même qu’une relecture humaine n’intervienne.

De plus, des solutions d’intelligence artificielle (telles que GitHub Copilot, CodeRabbit ou AI Code Review Action) offrent désormais la possibilité d’automatiser partiellement la revue de code. Si elles peuvent accélérer l’identification de défauts ou de mauvaises pratiques, leurs recommandations doivent toutefois être interprétées avec prudence : elles ne remplacent pas l’expertise d’un développeur expérimenté. Enfin, il convient de rester attentif à la question de la souveraineté des données. Le recours à des services externes peut entraîner l’exposition du code source et soulever des enjeux de confidentialité ou de conformité réglementaire.

2. L’organisation d’une Revue de Code

Pour une revue de code efficace, il est crucial de suivre une organisation rigoureuse. Voici quelques conseils pour structurer ce processus sur GitLab et GitHub :

a. Définir un processus clair

Chaque équipe devrait avoir des règles claires sur le moment où une PR est prête pour la revue, qui doit la relire, et combien d’approbations sont nécessaires avant de fusionner. Par exemple, une règle pourrait être : « Chaque PR doit être relue par au moins deux membres de l’équipe et validée par les tests automatiques. »

b. Diviser les PR en petites portions

Des PR trop volumineuses peuvent être difficiles à réviser correctement. Il est recommandé de diviser les fonctionnalités ou correctifs en morceaux gérables, chacun étant associé à une PR distincte. Cela permet aux relecteurs de se concentrer sur des changements spécifiques et de fournir des retours de meilleure qualité.

c. Limiter les PR aux changements nécessaires

Seules les modifications directement liées à une tâche ou un ticket doivent figurer dans une PR. Ajouter des «nettoyages» de code ou d’autres améliorations peut compliquer la revue et rendre plus difficile la compréhension des intentions derrière les changements.

3. Comment utiliser des Templates pour les Pull-Requests

GitLab et GitHub permettent d’utiliser des templates pour standardiser les Pull Requests et rendre le processus de revue plus méthodique. Voici comment les mettre en place.

a. Création d’un Template Pull-Request sur GitHub

Tout d’abord, commencez par créer un fichier PULL_REQUEST_TEMPLATE.md dans le répertoire .github/ de votre dépôt. Ce fichier peut contenir des sections prédéfinies comme :

## Description
Veuillez fournir une brève description des modifications.

## Type de changement
- [ ] Correction de bug 
- [ ] Nouvelle fonctionnalité 
- [ ] Refactorisation 

## Tests
- [ ] Les tests unitaires sont-ils présents ? 
- [ ] La documentation est-elle mise à jour ?

b. Création d’un Template PR sur GitLab

Dans GitLab, les templates de PR sont placés dans le répertoire .gitlab/merge_request_templates/.2. Comme sur GitHub, vous pouvez y inclure une structure utile pour guider les contributeurs :

## Objectif de cette MR
Résumez les modifications et leur objectif.

## Liens associés
– Ticket JIRA ou GitLab : [Lien]

## Vérifications
– [ ] Tous les tests passent-ils ?
– [ ] Le code a-t-il été relu ?

Ces templates permettent d’assurer que les PR contiennent toutes les informations nécessaires pour une revue complète.

4. Mettre en place une Check-list

Une check-list est un excellent moyen d’assurer que chaque aspect du code a été pris en compte avant la fusion. Voici un exemple de check-list à inclure dans les templates de PR :

Exemples de points à vérifier dans une check-list :

• Le code suit les conventions de style de l’équipe.

• Tous les nouveaux fichiers incluent les bonnes en-têtes de licence.

• Les nouvelles fonctionnalités sont couvertes par des tests adaptés (tests unitaires ou fonctionnels selon le cas).

• Le code a été testé dans les environnements de développement et de production simulée.

• Aucune dépendance obsolète, non maintenue ou abandonnée n’a été introduite.

• Aucune syntaxe ou API dépréciée n’a été utilisée.

• La documentation technique a été mise à jour si nécessaire.

• L’impact des changements sur la performance a été évalué.

5. Automatiser certaines étapes avec GitLab CI/CD

GitLab permet d’intégrer des pipelines CI/CD pour automatiser certaines étapes de validation des PR. Cela permet d’exécuter des tests, des vérifications de qualité de code ou des analyses de sécurité avant que la revue humaine ne commence. Par exemple, vous pouvez configurer un pipeline pour :

• Exécuter des tests unitaires et fonctionnels.

• Lancer des outils de linting pour vérifier les conventions de style.

• Utiliser des outils comme SonarQube pour détecter les vulnérabilités ou code smells.

Conclusion

La revue de code est une pratique clé pour garantir un code de qualité. GitHub et GitLab offrent des outils et des fonctionnalités qui, bien utilisés, permettent d’organiser ce processus de manière efficace et rigoureuse. En utilisant des templates de PR, en créant des check-lists et en automatisant certaines étapes avec des pipelines CI/CD, votre équipe peut améliorer la productivité, réduire les erreurs et favoriser un partage des connaissances qui profite à tous.

Pour réussir une revue de code, l’organisation et la communication sont les maîtres mots. Utiliser les bonnes pratiques sur ces plateformes contribue à des processus de développement plus robustes et un code de meilleure qualité.