Le contrôle de son code par un collègue permettrait d'en améliorer la qualité

Et de respecter les délais de livraison, d'après un consultant

Jonathan Hassel, consultant technique, estime qu’implémenter une méthode de contrôle de qualité de son code par des collègues constitue un excellent moyen d’en améliorer la qualité tout en minimisant le temps passé à la recherche et la correction de bugs et de rester dans les délais impartis.

Comment voit-il la chose ? Pour lui, un développeur pourrait s’associer à un collègue, et chacun d’entre eux scrutera le code de l’autre à la recherche de meilleures façon de faire, mais également pour éliminer les répétitions et des lignes de code superflues. Le développeur parcourt le code, explique sa logique, montre comment il a développé le concept sur lequel il a travaillé. Son confrère suggère où peuvent se trouver les erreurs, l’aide à résoudre quelques problèmes et, d’une façon plus générale, travaille à améliorer la qualité de son code.

Hassel reconnait que si l’examen fait par les paires constitue un élément essentiel dans le monde scientifique mais également dans l’académie de publication, ce n’est que récemment qu’il a connu un certain essor dans le développement logiciel ; dans un monde où même de modestes applications peuvent avoir des milliers de lignes de code (avec des possibilités d’erreur qui vont crescendo), il va sans dire que l’enthousiasme n’est pas forcément au rendez-vous.

Il estime que des examens par les pairs réussis sont des indicateurs significatifs de qualité. Il va même plus loin dans les éloges de cette méthode en avançant que, s’ils sont sollicités régulièrement, les contrôles de qualité par les pairs peuvent permettre d’économiser beaucoup de temps et d’argent. « Si les erreurs sont identifiées et corrigées avant qu’elles ne soient intégrées dans de nouvelles builds, il y aura moins de défauts et les projets seront livrés plus rapidement », estime-t-il. En guise d’illustration, il cite le livre CODE COMPLETE qui indique qu’après avoir instauré l’examen par les paires, « Aetna insurance Company a trouvé 82 pour cent des erreurs dans un programme en utilisant des inspections et a été en mesure de faire décroître ses ressources de développement de 20 pour cent ».

Bien sûr une méthode ne saurait faire l’unanimité. Aussi il a cité les cinq plaintes qui reviennent le plus souvent sur ce type de procédé ainsi que les solutions pouvant les rendre caduc :

• l’examen par les pairs est une perte de temps : malheureusement, certains des membres de votre équipe sont fatigués de la bureaucratie et vont d’abord repousser énergiquement ce procédé. Il y a de grandes chances que ce soient également les développeurs les plus faibles, ceux à qui les examens par les pairs profiteraient le plus. Pour lutter contre cela, Hassel recommande d’expliquer que beaucoup de paires d’yeux valent mieux qu'une, qu’en résultat vous obtiendrez une amélioration de la qualité du code permettra et de rappeler que les mesures de qualité sont importantes pour tout le monde en entreprise.
• je ne gère pas bien la critique : intrinsèquement, l’examen par les pairs signifie une critique du code et certains développeurs auront certainement du mal à faire une critique du code sans que cela ne devienne personnel. Pour rendre ces sessions plus productives, envisager de commencer l’examen par les pairs plus tôt dans le processus afin que le code actuel ne soit pas le seul élément qui soit examiné pour permettre à vos équipes de développer un certain niveau de confort.
• je ne suis pas assez bon pour faire un examen par les pairs avec une autre personne dans mon équipe : il est vrai que, tandis que l’examen par les pairs débute, certaines personnes n’y mettront pas vraiment du leur tandis que d’autres feront un excès de zèle. Ce déséquilibre pourrait même durer plus d’un an et apportera une facilitation des rapports de performance comme bonus. Le travail du manager qui identifie les meilleurs et les plus brillants en sera plus facile dans la mesure où il sera beaucoup plus aisé de repérer qui est capable d’apporter un plus à votre équipe et qui pourrait avoir besoin d'être réaffecté ou mis à la porte.
• je n’ai pas de temps pour un examen par les pairs - nous avons un calendrier serré à respecter et nos délais ne nous donnent pas le temps de faire ce genre de revue systématique : une partie de votre culture doit vous souffler que des délais serrés ne sont pas une raison de ne pas procéder à des examens. Techniquement, il y aura toujours un examen – mais qui pourrait être effectué à un moment inopportun. Les meilleurs moments sont le plus tôt et le plus souvent possible, et en général, si les examens de code par les pairs sont effectués de cette façon, les projets sont souvent livrés plus tôt.
• je ne sais pas avec qui m’associer : ceci est un type de problème que vos rapports directs devraient sans aucun doute résoudre, mais laisse la porte ouverte aux développeurs pour qu’ils puissent régler directement la question entre eux. En cas de doute, constituez des équipes de professionnels chevronnés et de débutants … pour des raisons évidentes.

Hassel reconnaît que cette méthode prendra du temps mais souligne clairement que cela pourrait profiter à tous : « vos meilleurs développeurs vont apprécier le fait qu'un code de bonne qualité soit l’objectif de l’exercice. Vos développeurs juniors vont se parfaire et améliorer leurs compétences en regardant comment s’y prennent des développeurs plus expérimentés. Vous pourrez épargner du temps et de l’argent ».

Source : CIO

Et vous ?

Partagez-vous son point de vue ? Pour quelles raisons ?

Votre entreprise a-t-elle déjà adopté cette culture (de façon implicite ou explicite) ?