Pour fournir un logiciel de qualité, il est nécessaire de produire un code source de qualité. Je vous ai déjà présenté des outils pour mesurer des indicateurs de qualité du code source et pour vérifier le respect des conventions de codage. Cependant, ces outils ont leurs limites. Ils tendent à améliorer le code source en contrôlant le respect des normes de codage ou en identifiant les défauts de conception. Par contre, ils ne permettent pas d’identifier les anomalies fonctionnelles.

Cédric Beust présente son point de vue sur l’intérêt de la revue de code. La revue de code permet d’identifier des bugs avant de les rencontrer au moyen d’une relecture du code source par un développeur expérimenté.

La mise en place d’une revue de code systématique pendant la phase de développement et de correction, les développeurs se responsabilisent encore plus[1]. Car ils savent que leur travail sera automatiquement évalué[2]. Ce système permet d’améliorer la qualité du code source écrit. De plus, le relecteur pourra identifier des bugs ou des axes d’amélioration[3].

Trois processus de revue de code existent :

  • Revue de code bloquante : tout développement doit être relu avant d’être commité dans le référentiel du code source. Ce mode est un frein au développement car certains développement peuvent se retrouver en attente d’une relecture de développement dont ils dépendent.
  • Revue de code non-bloquante : tout code source commité dans le référentiel du source source doit être relu. Cette méthode permet au développeur de continuer son travail sans attendre la relecture. De même, le relecteur n’est pas obligé de se précipiter pour relire le code.
  • Revue de code avec le développement par binôme : c’est une conséquence de l’extrême programming. Cependant le travail en binôme influence le jugement du relecteur direct.

La revue de code non-bloquante semble être la meilleure solution. Des produits permettent de mettre en place ce système. Certains sont même disponibles sous la forme de plugins pour les IDEs tel que Jupiter pour Eclipse.

La revue de code augmente les charges de développement d’un projet. En revanche, cette première passe permet d’éviter de nombreux retours lors de la phase de recette. La charge de recette et de correction sont alors réduites. Le produit livré sera mieux perçu par les premiers utilisateurs.

A vos relectures ! 😉

Notes

[1] Plus attentif aux potentielles erreurs, documentation du code, …

[2] Attention, l’évaluation doit être respectueuse du travail initial fourni.

[3] Optimisation du code source, documentation, …

https://blog.lecacheur.com/wp-content/uploads/2006/06/tumblr_9e0289a12bbdc42e4f6db208f7220a70_200f5696_1280-1024x819.jpghttps://blog.lecacheur.com/wp-content/uploads/2006/06/tumblr_9e0289a12bbdc42e4f6db208f7220a70_200f5696_1280-150x150.jpgSeBDéveloppementdéveloppementPour fournir un logiciel de qualité, il est nécessaire de produire un code source de qualité. Je vous ai déjà présenté des outils pour mesurer des indicateurs de qualité du code source et pour vérifier le respect des conventions de codage. Cependant, ces outils ont leurs limites. Ils tendent...Un blog, c'est un blog !