Discussion :

[Stéphane le calme]

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'un projet, 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) ?

[DonQuiche]

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".

[tomlev]

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.

[RyzenOC]

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

[ustensile]

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é...

[fenkys]

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.

[el_slapper]

(.../...)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.

[MvK0610]

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...

[Luckyluke34]

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.

[Luckyluke34]

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"

[MvK0610]

Réponse à chaque fois que le mec te demande de l'aide par la suite : "je ne suis pas meilleur que toi"

Encore faut-il que la fille, en l'occurence et je n'ai rien contre, en question ait assez de recul et de jugeote pour demander de l'aide avant de foncer dans le mur avec la vélocité d'un angry bird sous amphet.

Ce qui n'était malheureusement pas le cas à l'époque et je ne suis fort heureusement plus là-bas pour le constater à l'heure actuelle

[CodeurPlusPlus]

(...) 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.(...)

Ca c'est la théorie, et c'est peut-être le discours qu'on t'a vendu ou que tu vends toi-même...

Mais la réalité c'est que, comme dans n'importe quelle équipe de plus d'une personne, les plus grandes gueules imposent leurs points de vue aux autres.

Une des raisons pour lesquelles je ne travaille que seul ; et pour lesquelles celui qui prétendra m'apprendre à coder prendra directement ma main dans la figure.

[RyzenOC]

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.

Dans ma boite actuel, c'est tout l'inverse !

On est 4 ingénieurs dans l'équipe ou je travail, y'a pas vraiment de chef, tant qu'on fournie du code stable et performant, on a limite carte blanche sur nos méthodes de travail, la DSI nous laisse tranquille.

Pour le dev on utilise la méthode Scrum, ou chaque matin, on se prend 1H max, pour discuter d’éventuel problème rencontrer, et pour tester nos sprint de la vielle.

Comme le client c'est la boite ou je travail, on est directement en contacte avec le client. On a presque crée une communauté avec les salariés, chaque jour, on publie une build "instable" de notre logiciel, a disposition de tous les salariés de la boite, qui peuvent la tester et nous remonter les bugs, et proposé des améliorations/nouvelle fonctionnalité. Gra ce a une mini application que j'ai créé et intégrer au logiciel, qui permet de nous envoyer des messages avec des pièces jointe en plus.

[a028762]

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

[Laurent 1973]

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.

[RyzenOC]

Tu confonds avec le Pair Programming où en effet, tu développes à 2 (un au clavier, l'autre en relecture).

Qui utilise cette méthode ?

Pour ma part j'ai jamais pu l'utiliser concrètement, j'avais essayer une fois, mais n'aime pas trop, car soit l'un code et l'autre glande, soit l'un code et l'autre critique chacune de tes lignes.

C'est très difficile a mettre en place je trouve.

[redbullch]

soit l'un code et l'autre critique chacune de tes lignes.

C'est le but, sinon ça sert à rien.

[Luckyluke34]

Ca c'est la théorie, et c'est peut-être le discours qu'on t'a vendu ou que tu vends toi-même...

On l'a mis en pratique dans mon équipe actuelle et dans la précédente et ça marche pas trop mal : moins de bugs, connaissance plus complète de la base de code par chacun, meilleure implication et satisfaction des membres de l'équipe.

Une des raisons pour lesquelles je ne travaille que seul ; et pour lesquelles celui qui prétendra m'apprendre à coder prendra directement ma main dans la figure.

Il ne s'agit pas d'apprendre à quelqu'un à coder mais de mettre une deuxième paire d'yeux sur le coup pour détecter les fautes d'étourderie qui arrivent à tout le monde, et apporter des idées de meilleur design. Si grande gueule et désaccord il y a, d'autres membres de l'équipe sont consultés. On a toujours trouvé un terrain d'entente, et si ce n'était pas le cas, je pense que le problème nous exploserait à la face d'une manière ou d'une autre, code review ou non. Ne serait-ce que quand on essaierait d'intégrer ensemble le code de deux personnes ayant des visions opposées.

Attention, je ne parle pas de code review par écrit a posteriori (qui peut effectivement être génératrice de malentendus et non-dits) mais en conversation directe avec la personne.

[Spownik]

Contrôler le code par des collègues ? Ca s'appelle le code review. Avec UpSource etc... Je le pratique. Le code devient nettement plus propre, le programme plus stable, et partage de connaissances etc...

Que du positif à mon avis, le petit bémol c'est que certaine fois ça peut retarder les mises en production. Mais c'est rare, et moi ça m'est jamais arrivé.

[cchatelain]

É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".

Tu as juste décrit mon chef...

Sinon, je pense que c'est évident : une autre personne détectera plus facilement des erreurs que le codeur lui-même.