Examens par les pairs ou programmation en binôme, ou les deux ?[fermé]

Question

• Participez-vous à des évaluations de code par les pairs ou pratiquez-vous la programmation en binôme, ou les deux ?
• Avez-vous pu démontrer une augmentation de la qualité des logiciels grâce à ces pratiques ?
• Quels avantages et inconvénients avez-vous observés au cours de la pratique ?
• À quels obstacles à la mise en œuvre avez-vous été confrontés ?

Dans mon propre cas, notre équipe de développement a procédé à des évaluations par les pairs d'un certain nombre d'artefacts logiciels différents (analyses des exigences, plans de test, code, etc.).La programmation par les pairs n’était même pas considérée comme une option.

La pratique de l’évaluation par les pairs a été poussée vers le bas et les développeurs n’y ont jamais adhéré.Nous avions un groupe SQA externe qui collectait des mesures sur les activités, mais les chiffres étaient plutôt sans valeur car les efforts étaient timides.Après des années où cela était la manière « officielle » de faire les choses, les développeurs en sont venus à ignorer collectivement les procédures prescrites.

Il y a désormais moins de visibilité sur le moment où les bogues sont introduits dans le cycle de vie.Et ne pas effectuer d'évaluations par les pairs a conduit à une spécialisation accrue au sein de l'équipe... où personne ne connaît vraiment les exigences/la logique des composants en dehors de leur propre domaine spécialisé du système.

Il serait utile de connaître vos expériences en matière d'évaluation par les pairs ou de programmation en binôme, en particulier les histoires de réussite.

Answer 1

Quand j'étais jeune et idiot, l'un de mes premiers travaux consistait à créer un analyseur pour extraire certains champs d'un long fichier PDF qui était converti en texte non formaté.J’en savais assez pour utiliser une certaine forme de regex, mais pas assez sur les regex pour bien faire le travail.Plusieurs jours plus tard, j'ai terminé la tâche, mais lors de l'examen par les pairs, j'ai été écrasé d'apprendre que j'aurais pu faire mieux et que ce que j'avais produit était du déchet.J'ai appris à faire de l'analyse lexicale juste pour prouver que je n'étais pas un idiot, mais disons simplement que le processus d'évaluation par les pairs était nul.Je n’avais pas besoin d’une personne expérimentée pour danser sur mes échecs, j’avais besoin d’un mentor et je me le rappelle à chaque fois que je fais une évaluation par les pairs.

J'aime les évaluations par les pairs lorsque nous vérifions les egos à la porte.(Cela inclut le mien !) Il y a une durée limitée dans ce monde, et seulement une quantité limitée de choses que vous pouvez apprendre et faire.Grâce à un bon examen par les pairs, vous pouvez élargir vos connaissances et accomplir davantage dans un laps de temps plus court.Les problèmes surviennent lorsque les choses se dégradent en une vérification syntaxique excessive.

J'ai quelques règles à cause de cela.Je n’examine rien de ce que nous pouvons automatiser.Exécutez une vérification orthographique et un embellisseur de code.Si vous disposez de quelque chose comme FXCop, exécutez-le, faites ce qu'il dit ou avez une très bonne raison pour laquelle vous ne l'êtes pas.Ensuite, nous pouvons examiner comment le code est élaboré, comment il fonctionne et ce que nous pouvons faire pour l'améliorer.De cette façon, vous obtenez une perspective différente sur la façon de résoudre un problème et pourquoi quelqu’un pense de cette façon.Parfois, l'autre solution n'est pas vraiment meilleure, parfois la nouvelle solution est fantastique et vous l'utiliserez pour le reste de votre vie de programmation.Une fois l’examen fait, c’est tout, je ne l’utilise pas comme exemple contre vous.C’est à vous d’en tirer des leçons.Je ne me débrouillerai pas par la peur ou la menace, tu es une personne intelligente et je vais te laisser le montrer.

Answer 2

Nous essayons de nous assurer qu'aucun code n'entre en production sans avoir été examiné par au moins une autre paire d'yeux.
Habituellement, cela signifie que nous révisons le code.Nous essayons de faire prendre l'habitude au sein de l'équipe que les révisions font partie intégrante de l'écriture de code.Vous l’écrivez, puis demandez l’avis de quelqu’un.
De plus, sur les projets où nous avons suffisamment de personnes disponibles (c'est-à-dire lorsque les tâches sont de bonne taille), nous essayons de coupler la programmation.
Je dois dire que nous y avons certainement vu un avantage.Tout d'abord, c'est un excellent moyen d'encadrer les développeurs juniors de l'équipe : lorsque vous examinez leur code, vous leur montrez ce qui peut être mieux fait, et en faisant équipe avec eux, ils découvrent de meilleures façons de faire les choses, comment des personnes expérimentées réfléchissez et même comment mieux utiliser l'IDE.
En outre, cela permet à toute l’équipe de rester synchronisée en ce qui concerne la connaissance de l’apparence du code.
Et, en plus, cela augmente simplement la joie et le développement personnel de chacun : une équipe capable de parler et de raisonner sur le code est une meilleure équipe, une équipe qui continue d'apprendre et de partager.

Quelques points à surveiller :

• Assurez-vous que les seniors laissent également les juniors programmer lors du jumelage.
• Ne laissez pas les gens s'associer pour de petites tâches, cela fait généralement perdre du temps
• Observez comment les couples s'entendent (ne forcez pas les couples à se rassembler)
• N'oubliez pas de remanier les paires de temps en temps
• Ne laissez pas les critiques correspondre à votre ego - ne laissez pas les gens écraser les autres

Answer 3

L'examen par les pairs devrait être OBLIGATOIRE.

Vous pouvez lire et trouver de nombreux articles et livres qui discutent des différentes manières d'aborder cela au sein d'équipes de différentes tailles, mais vous semblez vous renseigner sur les expériences.

Personnellement, je pense que l’évaluation par les pairs devrait être amusante.Nourriture fournie et garder l'ambiance joviale.Cela devrait vraiment être traité comme un moment où les développeurs/programmeurs peuvent apprendre les uns des autres, pas une chance de juger (et nous savons tous que chaque programme semble né avec un gène de jugement inné).J'ai eu tendance à apprécier ou à aider à organiser les révisions pour qu'elles soient ouvertes 1/3 ou 1/4 du temps.J'entends par là lorsque le groupe se réunit et qu'une personne présente un projet sur lequel elle travaille ou même qu'elle a révisé et qui n'est même pas lié au projet en cours (je sais que c'est difficile avec les délais mais essayez).

Les créatifs se réunissent généralement pour exposer des peintures, des créations et des artistes qu’ils aiment actuellement afin de faciliter l’inspiration.En réalité, l’inspiration devrait être le concept principal que vous espérez promouvoir dans une revue.Deuxièmement, les gens remarquent naturellement des choses que font leurs collègues développeurs qu'ils n'avaient PAS remarquées auparavant.« Oh wow, alors tu as réussi à faire ça en une seule ligne de code ?Cool." L'inspiration des développeurs et motivée sur ce qu'ils font, sur quoi ils travaillent et comment ils y vont versera plus de dividendes que de l'utilisation de l'examen par les pairs pour établir l'ordre de picage et le classement.

Enfin, vient la partie « révision », mais c'est un fait inévitable.Vos meilleurs développeurs verront un code médiocre et après suffisamment d'examens, il est temps pour le mauvais codeur d'intensifier ses efforts ou de l'oublier.

Si vous gardez les choses positives et organisées, c'est généralement une expérience formidable.

J'ai presque oublié d'aborder la programmation en binôme.C'est plus difficile à mettre en place.Évidemment, vous ne pouvez pas faire travailler ensemble deux de vos programmeurs les plus faibles, ou vous pourriez tout aussi bien organiser un million de singes avec un million de machines à écrire.Essayez de mettre une personne plus forte avec une personne plus faible et offrez des incitations aux deux en privé.Quelqu'un de plus faible devrait savoir que l'amélioration pourrait être récompensée (s'il a besoin d'une telle incitation) et le programmeur le plus fort devrait savoir que les vrais leaders commencent comme de bons mentors.Assurez-vous cependant que le développeur le plus faible tape.Ce n'est pas l'inverse, sinon cela devient une présentation et "bâillement" Quelqu'un pourrait ne rien gagner de cette expérience.

Answer 4

J'ai effectué de nombreux coaching agile, et pour aider les gens à surmonter la « stigmatisation » de la programmation en binôme, nous appelons cela « révision du code et de la conception en temps réel ».Les gens semblent mieux comprendre le concept si vous le formulez en ces termes.

Answer 5

La seule expérience directement liée que j'ai dans l'un ou l'autre concerne les évaluations de conception par les pairs (il y a longtemps).Et ils étaient nuls.Si vous lisez la littérature, il était clair qu'ils enfreignaient plusieurs règles des bonnes critiques (sauter sur les gens, se concentrer sur l'orthographe, pas de résultats clairs, etc.).etc.) mais c'était tout ce que nous savions.

MAIS depuis lors, j'ai participé à de nombreuses révisions de code hors ligne.

En fonction du projet, ils ont été mandatés soit avant l'enregistrement dans la succursale "en direct", soit à un moment aléatoire après.Dans 3 projets sur 4, ils ont été adoptés, certes comme un mal nécessaire au début, mais plus tard comme un apport précieux.

L'avantage de toute révision de travail devrait être d'inciter tout le monde à écrire un meilleur code et de donner un encadrement même aux meilleurs codeurs (soyez honnête, vos programmeurs les plus performants écrivent-ils réellement du code lisible ?) Une fois que vous pouvez persuader le personnel moins expérimenté de dire qu'il ne le fait pas. comprends quelque chose - tu es absent.Certains des meilleurs clichés souffleront et souffleront, mais les meilleurs réfléchiront à ce qu'ils ont écrit et changeront réellement les noms ou la mise en page des variables - et ajouteront peut-être même un commentaire.

Le 4ème projet utilise un schéma imposé de révision 'à un moment aléatoire' et les responsables techniques ne l'ont pas encore intégré (équipe brisée ?)

---

Les deux pratiques que vous décrivez sont des approches formelles.Ils ne fonctionnent pas bien pour toutes les personnalités et tous les groupes.

Essayez quelque chose que vous pensez que votre équipe peut réellement faire, puis voyez si cela peut être amélioré.

Une fois que vous aurez eu cet œil supplémentaire sur votre code, vous ne voudrez plus regarder en arrière.

Answer 6

• Oui, notre entreprise utilise des revues de code par les pairs.Nous les effectuons sous forme de révisions Over-The-Shoulder et invitons le testeur de l’équipe à participer à la réunion pour mieux comprendre les changements.

• La révision des codes présente des avantages certains, comme plusieurs études ont pu le démontrer.Pour notre entreprise, il était évident que la qualité du code augmentait à mesure que le nombre d'appels au support diminuait et que le nombre de bogues signalés diminuait également.NOTE:Certains des avantages ici résultaient de la mise en œuvre de Scrum et de l’abandon de Waterfall.En savoir plus sur Scrum ci-dessous.

• Les avantages de la révision du code peuvent être un produit plus stable, un code plus maintenable dans la mesure où il s'applique aux normes de structure et de codage, et il permet aux développeurs de se concentrer davantage sur les nouvelles fonctionnalités plutôt que de « lutter contre les bogues » et d'autres problèmes de production.Il n’y a vraiment aucun inconvénient si les révisions de code sont effectuées « correctement ».Plus d’informations sur la « bonne voie » ci-dessous.

• Certains des obstacles à surmonter lors de la mise en œuvre des révisions de code sont l'idée que « grand frère » me surveille et l'idée que ne pas avoir de code parfait signifie torture et douleur.Il est parfois difficile d'amener les développeurs à se faire confiance, surtout lorsqu'il s'agit d'attitudes de « hiérarchie » ou de « plus saint que toi » et de mettre votre travail acharné sous un microscope.La confiance est la clé pour résoudre ces problèmes.Un développeur doit être sûr qu'il ne sera pas puni par ses pairs ou par la direction pour des erreurs de code.Ça arrive à tout le monde.Prenez note du problème, résolvez-le et passez à autre chose.

MêléeL’un des avantages de l’utilisation de la méthodologie Scrum est qu’un cycle de développement (« sprint ») est court.La durée du « sprint » est déterminée par ce qui fonctionne le mieux pour votre organisation et nécessitera quelques essais et erreurs, mais ne devrait en réalité pas dépasser quatre semaines.L'avantage est que cela oblige les développeurs à communiquer quotidiennement et à communiquer les problèmes dès le début du projet.Cela a été initialement adopté par notre service de développement et s'est étendu à tous les domaines de notre entreprise car les avantages de Scrum sont considérables.Pour plus d'informations, voir : http://en.wikipedia.org/wiki/SCRUM ou http://www.scrumalliance.org/ .Comme les itérations de développement sont plus petites, le processus de révision du code examine des morceaux de code plus petits, ce qui rend la révision plus susceptible de détecter des problèmes que des heures ou des jours de révisions formelles.

"La bonne façon"Les révisions de code effectuées « de la bonne manière » sont complètement subjectives.Cependant, je crois personnellement qu’il devrait s’agir d’examens informels et directs.Tous les participants à un examen devraient éviter d'attaquer personnellement la personne examinée avec des déclarations telles que «pourquoi l'avez-vous fait de cette façon?» ou "à quoi pensiez-vous?" etc.Ces types de commentaires diminuent la confiance entre pairs, conduisant à de l'animosité et à des heures de dispute sur la meilleure/bonne façon de coder une solution.Gardez à l’esprit que les développeurs ne pensent ou ne codent pas exactement de la même manière et qu’il existe de nombreuses solutions à un problème.
Juste une petite précision sur les avis par-dessus l'épaule ;celles-ci peuvent être effectuées via le partage de bureau à distance (choisissez la saveur ici) ou en personne.Cependant, ils ne devraient pas être limités aux seuls développeurs.Nous invitons généralement toute notre équipe Scrum, composée de deux développeurs par équipe, d'un testeur, d'un responsable de la documentation et d'un propriétaire de produit.Tous les non-développeurs sont là pour mieux comprendre les modifications ou les nouvelles fonctionnalités apportées.Ils sont libres de poser des questions ou de fournir des commentaires, mais pas de prendre des décisions ou des commentaires en matière de codage.Cela a été efficace car certaines questions seront posées qui peuvent changer la direction du projet car les exigences initiales peuvent avoir manqué un scénario, mais c'est ça l'agilité, le changement.

SuggestionJe recommanderais fortement de rechercher des critiques de Scrum et de code avant de les rendre obligatoires.Créez les règles de base pour chacun et mettez-les en œuvre dans le cadre de votre culture pour obtenir un produit de meilleure qualité.Cela doit faire partie de votre culture afin qu'il fasse partie d'un processus naturel et intégré à tous les niveaux, car il s'agit d'un changement de paradigme d'une mauvaise qualité, de délais non respectés et de frustration vers des produits de meilleure qualité, moins de frustration et des livrables plus ponctuels. .

Answer 7

Une analyse comparative après être passé aux revues de relations publiques sur github de la programmation en binôme.

L'accent est mis sur la liste étape par étape de ce que nos équipes suivent actuellement dans le processus d'examen des relations publiques.

«Révisions de code vs programmation par paires» https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926