Revue de code, les bonnes pratiques

La qualité du code source produit est essentielle pour assurer la cohérence, la performance et la maintenabilité des applications. Cette qualité peut être obtenue en continu via des outils d’analyse mais ce n’est pas toujours suffisant.

Les bugs trouvés en production restent les plus coûteux, c’est pourquoi il est primordial de pouvoir les déceler à temps de façon à pouvoir les corriger au plus tôt.

Les sources du projet doivent être correctement organisées, aisément lisibles et respectant les normes de codage pour en assurer la maintenance et les évolutions possibles. Il est fort probable que ça ne sera pas la même équipe qui s’occupera de la maintenance ou des évolutions qui seront faites tout au long du cycle de vie du projet.

Nous utilisons principalement deux formats de revue de code dans nos projets : la revue collective, plutôt formelle et la revue par un pair, un format plus léger. Les deux présentent des avantages et des inconvénients : revenons ensemble sur ces formats et comment les mettre en place dans une équipe.

Dans la plupart des domaines impliquant l’écriture, on n’imagine pas que ce qui est écrit soit publié sans avoir été relu. Un article sera toujours relu avant publication (par exemple celui que vous êtes en train de lire), que ça soit pour une vérification sur le fond – le sujet de l’article est-il bien traité ? – ou sur la forme – orthographe, grammaire, structure et lisibilité du texte.
De la même manière, la pratique de la revue de code consiste à faire relire son code afin d’y trouver le maximum de défauts, que ça soit sur le fond – est-ce que ce code fonctionne, et matérialise bien la fonctionnalité prévue ? – ou sur la forme – clarté, lisibilité, respect des standards, etc.

Et chez vous, combien de lignes de code mettez vous en production sans qu’elles aient été relues ?

La revue de code est une pratique presque aussi ancienne que le développement de logiciel, et très répandue chez des entreprises comme Microsoft ou Google. Il y a une bonne raison à cela, c’est qu’elle permet de détecter les défauts plus tôt dans le processus de développement.

Pourtant cette pratique est relativement peu répandue dans les équipes que nous rencontrons. C’est parfois parce qu’elle est méconnue, mais c’est plus souvent pour de mauvaises raisons : “On n’a pas le temps, ça coûte trop cher.” “On a essayé mais ça a tourné au troll.” Ou encore “Je ne veux pas le faire, c’est du flicage.”

Il semble donc que ça ne soit pas une pratique si simple à mettre en place !


Je vous invites a lire les articles à la source original.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s