À retenir
- Détecte les erreurs et les bugs avant qu'ils n'arrivent en production.
- Améliore la lisibilité et la maintenance du logiciel sur le long terme.
- Sert de formation continue pour les développeurs débutants.
La relecture par les pairs est une étape où un développeur soumet son code à ses collègues pour qu'ils l'examinent avant qu'il ne soit intégré au projet final. C'est comme demander à un second lecteur de vérifier un texte pour s'assurer qu'il n'y a pas d'erreurs oubliées et que tout le monde peut le comprendre.
Étymologie
Traduction de l'anglais peer review. Le terme « pair » désigne ici des individus de même statut professionnel (collègues développeurs). Ce concept provient du milieu scientifique, où les chercheurs valident les travaux de leurs confrères avant publication.
Exemples d'usage
- Une Pull Request sur GitHub ou GitLab, où les modifications sont commentées par l'équipe avant fusion.
- Une session de Pair Programming, où deux développeurs vérifient le code en temps réel au fur et à mesure de son écriture.
- Une inspection formelle d'un algorithme sensible pour garantir sa sécurité.
Cas d'usage
Ce concept est utilisé systématiquement dans les entreprises de développement logiciel (Agile, DevOps) pour garantir la qualité, partager les connaissances techniques entre les membres d'une équipe et uniformiser la façon d'écrire le code.
Bonnes pratiques
Il est recommandé de rester bienveillant et constructif : l'objectif est d'améliorer le code, pas de critiquer la personne. Il vaut mieux relire de petites portions de code régulièrement (moins de 200 lignes) plutôt que de gros blocs indigestes en une seule fois.
Synonymes
Antonymes
Conseil
Pour bien débuter, utilisez des outils automatisés (linters) pour corriger les fautes de syntaxe avant la relecture humaine. Cela permet aux relecteurs de se concentrer sur la logique et la conception du programme plutôt que sur des détails de ponctuation.
Questions fréquentes
La relecture fait-elle perdre du temps ?
Au contraire, elle en fait gagner en évitant de futurs bugs coûteux à réparer.
Qui doit faire la relecture ?
Idéalement un ou deux collègues qui connaissent le projet mais n'ont pas écrit cette portion de code.
Doit-on tout corriger ?
On priorise les erreurs logiques et de sécurité avant les simples préférences de style.