Discussion :

[captaindidou]

Tu parles d'une nouvelle ...

La relecture croisée est une bonne pratique connue depuis le siècle dernier.

[el_slapper]

Tu parles d'une nouvelle ...

La relecture croisée est une bonne pratique connue depuis le siècle dernier.

...mais encore ignorée par bien des gens. D'ou l'utilité de piqures de rappel fréquentes.

[shenron666]

Ce genre de pratique, comme dit captaindidou, n'est pas nouvelle et déjà appliquée.

Parmis les problèmes liés à son application, il y a celui où le client ou l'employeur n'est que rarement prêt à payer pour le temps passé.

De plus, la lecture de code source n'est pas à la portée de tout développeur.
Il faut aussi de l'expérience, que le développeur qui va critiquer le code en ait au moins autant que celui a développé.

S'il n'y a pas de retour, d'échange entre les développeurs il n'y aura pas de valeur ajoutée.
Mais dans ce cas, il faut que le développeur du code original sache accepter la critique et que le développeur en charge de la relecture sache être pédagogue.
Tout cela coûte du temps, de l'argent et rien que pour cela c'est rarement mis en place.

[JakoJako]

C'est vrai qu'à première vue, on peut avoir l'impression que ça va perdre du temps.

Mais tout le monde a à y gagner, à condition de le faire intelligemment (ne pas être 'méchant' quand on fait la critique, et pas 'susceptible' quand on la reçoit):
* il ya de toutes façons plus d'idées dans 2 têtes que dans une
* le moins expérimenté profitera des des conseils du plus expérimenté
* le plus expérimenté évitera de faire des choses 'trop compliquées' ou nécessitant un niveau technique 'trop élevé' (quand c'est possible évidemment): ça devrait profiter à ma maintenabilité du programme
* quand on sait qu'on va être relu, à moins d'être un gougnafier, on soigne un peu plus le code, les commentaires, la présentation… ce qui ne peut qu'être bénéfique !

Malheureusement, chez nous, ce n'est pas une pratique généralisée...

[SurferIX]

... pouvant les rendre caduc :..

"caduc" ou "caduques" ?

Sinon, si t'essaie de faire ça avec un bon développeur, tu vas rapidement faire face à un problème classique (crois en mon expérience de 18 ans de pratique) : "je suis un bon dev, laaaaaaaaaaaaaaargement au dessus de la moyenne, donc j'ai 90% de chances que les critiques soient inutiles, voire stupides et me fassent perdre mon temps". Avec ce genre de personne, good luck !

Par contre, avec quelqu'un de débutant et / ou / d'ouvert d'esprit, c'est évident que c'est très profitable. Cela dépend des protagonistes, en fait.

[ChristianRoberge]

Le rôle du manager n'est pat nécessairement de contrôler et construire les binômes de validation (contrairement à ce qui à été dit plutôt). Personnellement, j'ai travaillé dans une équipe collégiale de 5 personnes pendant 2 ans où tous les étapes du projets (design, codage, déploiement et correction de bugs). Le rôle du manager était minimal et personne officiellement dirigeait les activités quotidienne de l'équipe. Ce fut une de mes plus belle expérience de ma vie où j'ai appris beaucoup sur l'ensemble des facette du métier. Je trouve que nous avons accomplie un logiciel exceptionnel en qualité. Donc pour moi, j'irais beaucoup plus loin que l'article car il ne faut pas se limiter à 2 et à la validation.