Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Stéphane le calme

23PARTAGES

2  0 
Que pensez-vous de l'idée de faire des examens de son code par des collègues ?
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) ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 23/06/2015 à 21:53
Mouais, je vois pas ce qu'il y a de très nouveau là-dedans... le concept de code review existe depuis longtemps et est déjà appliqué dans beaucoup d'entreprises.

L'utilité n'est plus à démontrer. Dans ma boite, on s'est mis depuis quelques mois à le faire de façon systématique, et il est rare qu'une code review ne permette pas de détecter quelques bugs ou améliorations possibles. Même quand ce n'est pas le relecteur qui voit le problème, le fait d'expliquer son code à un collègue permet souvent de détecter ses propres erreurs. Pour moi, l'impact positif sur la qualité du code ne fait aucun doute.
8  0 
Avatar de RyzenOC
Inactif https://www.developpez.com
Le 23/06/2015 à 22:45
malheureusement, certains des membres de votre équipe sont fatigués de la bureaucratie
Oui, j'ai horreur de remplire/signer des papiers, surtout pour des conne****

Cela dit, l'inspection du code par un compère, ne nécessite pas de paperasse, pas chez moi en tous cas . C'est en générale l'affaire de 15-30 minutes.

L'avantage aussi, c'est que l'autre personne a une façon de penser différente, ce qui permet de tester le logiciel sous un autre angle, et de détecter de potentiel bug, auquel ont aurais pas pensé.

Dans ma boite c'est même devenue un jeu, faire planter le logiciel/bout de code de l'autre. En utilisant des procédés parfois vicieux, (insertion de caractère bizarre dans un champ de texte...), depuis, nos logiciels n'ont jamais été aussi stable
8  2 
Avatar de MvK0610
Membre habitué https://www.developpez.com
Le 24/06/2015 à 12:10
Cette pratique, pour l'avoir expérimenté est nettement profitable à la qualité et stabilité d'une application.

Après comme dit plus haut reste encore à convaincre ses supérieurs,collègues et autres guignols du bénéfice de la chose.

Je me suis retrouvé dans un service info où nous étions deux développeurs qui s'entendaient pas trop mal.
J'ai soumis l'idée au DSI qui ma copieusement envoyer paître en me soutenant que si je ne savais pas faire mon travail correctement j'avais rien à faire ici.
J'ai donc soumis l'idée au 2eme développeur qui ma copieusement envoyer paître en me soutenant que si je me pensais meilleur que lui je n'avais qu'à faire son boulot à sa place.

Devant tant de bon sens et d'ouverture d'esprit je les ai copieusement envoyé paître également.
Un seul des 3 s'est vu infligé une sanction...

Je dois probablement manquer de diplomatie...
6  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 24/06/2015 à 14:11
Citation Envoyé par DonQuiche Voir le message
A vrai dire pour moi c'est le rôle du manager : gérer l'équipe, contrôler le travail accompli, vérifier la tenue des normes et pratiques mises en place. Et si un membre est faible on le fait travailler en binôme avec quelqu'un de plus doué.

Évidemment ça ne fonctionnera avec un petit chef incapable de faire la différence entre "moi j'aurais fait comme ça" et "ceci est une mauvaise pratique reconnue".
Je ne suis pas sûr que ça soit vraiment l'esprit du peer review. On ne cherche pas un système arborescent où la raison du plus haut placé l'emporte mais un graphe complet où chaque individu peut être force de proposition envers tous les autres et où la connaissance circule dans toutes les directions.

Maintenant, si le manager est bon techniquement, code régulièrement, qu'il se met en mode "simple collègue un peu plus expérimenté" lors de la code review et qu'il accepte que son propre code soit revu de la même manière, pourquoi pas.

Quand à savoir si "le contrôle de son code par un collègue permettrait d'en améliorer la qualité", ça me paraît presque une lapalissade.
5  0 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 23/06/2015 à 19:25
A vrai dire pour moi c'est le rôle du manager : gérer l'équipe, contrôler le travail accompli, vérifier la tenue des normes et pratiques mises en place. Et si un membre est faible on le fait travailler en binôme avec quelqu'un de plus doué.

Évidemment ça ne fonctionnera avec un petit chef incapable de faire la différence entre "moi j'aurais fait comme ça" et "ceci est une mauvaise pratique reconnue".
4  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 24/06/2015 à 14:21
Citation Envoyé par MvK0610 Voir le message
J'ai donc soumis l'idée au 2eme développeur qui ma copieusement envoyer paître en me soutenant que si je me pensais meilleur que lui je n'avais qu'à faire son boulot à sa place.
Réponse à chaque fois que le mec te demande de l'aide par la suite : "je ne suis pas meilleur que toi"
4  0 
Avatar de fenkys
Membre éprouvé https://www.developpez.com
Le 24/06/2015 à 9:17
Je ne crois pas qu'il parle ici du code review tel qu'on le pratique généralement, mais d'un échange de bons procédés entre deux développeurs : je relis ton code, tu relis le mien. C'est souvent fait de façon informelle et non systématique. Il préconise juste de le systématiser.

C'est une opération gagnant/gagnant, non seulement pour le rédacteur du programme que pour le relecteur qui pourrait aussi apprendre quelque chose de nouveau.
2  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 24/06/2015 à 15:20
Citation Envoyé par a028762 Voir le message
Eh bien, ce n'est pas gagné !
Ce n'est pas un élément des méthodes agiles ? Le code review ... ou c'est encore plus invasif, un jour sur deux, tu codes devant moi , le lendemain c'est l'inverse
Ol
Tu confonds avec le Pair Programming où en effet, tu développes à 2 (un au clavier, l'autre en relecture).
C'est 2 techniques différentes mais qui vont dans le même sens: avoir du code "juste" écris au plus tôt.
2  0 
Avatar de ustensile
Membre régulier https://www.developpez.com
Le 24/06/2015 à 9:15
Je pense que c'est une pratique qui vient naturellement avec la pratique, ça fait partie du métier de se remettre en question, on est tellement la tête dans le guidon qu'on perd en objectivité et on passe à côté de choses importantes, c'est là que le coup d'oeil extérieur intervient pour faire avancer une situation. Par contre, si on est tout seul ou si on a un manager qui brille par son incompétence et/ou sa connerie, c'est pas gagné...
1  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 24/06/2015 à 11:13
Citation Envoyé par sazearte Voir le message
(.../...)Dans ma boite c'est même devenue un jeu, faire planter le logiciel/bout de code de l'autre. En utilisant des procédés parfois vicieux, (insertion de caractère bizarre dans un champ de texte...), depuis, nos logiciels n'ont jamais été aussi stable
100% d'accord avec toi. Sauf que je n'ai jamais eu l'autorisation de le faire(à une exception près, un peu particulière, l'architecte qui vérifie tout systématiquement). Pourtant, je suis sur que c'est aussi un moyen de faire passer de bonnes pratiques, en plus de la chasse aux bugs. Et aussi de diffuser la connaissance(technique ou fonctionnelle) à travers l'équipe. Celui qui lit sera bien mieux à même de reprendre le code plus tard - ça lui sera familier.

Mais bon, le chef qui hurle en permanence "tu est en retard sur tes objectifs" n'aide pas - alors même que je sais très bien depuis plus d'un mois que je vais les louper et ne pas avoir de prime(forcément, j'ai chiffré pour 30 composants en ayant les specs pour 12... Et les cas les plus difficiles arrivaient à partir de numéro 15). Le truc, c'est que mon collègue(qui trouve que je me "complique la vie pour rien" quand je fais des fonctions - voire, Dieu nous préserve, des classes - pour encapsuler le code) n'ose pas rentrer dans mon code quand je suis absent et que ça plante. Et ça, à mon avis, ça coute beaucoup plus cher qu'une putain de revue de code par semaine.
2  1