Quelle est l'importance des commentaires positifs dans les revues de code?

Est-il important de souligner les bonnes parties du code lors de son examen et les raisons pour lesquelles il est bon? Les commentaires positifs peuvent être tout aussi utiles pour le développeur examiné et pour les autres participants.

Nous effectuons des révisions à l'aide d'un outil en ligne, afin que les développeurs puissent ouvrir des révisions pour leur code validé, tandis que d'autres peuvent réviser leur code dans un délai donné (par exemple, une semaine). D'autres peuvent commenter le code ou les commentaires d'autres relecteurs.

Devrait-il y avoir un équilibre entre les commentaires positifs et négatifs?

Améliorez la qualité et le moral en utilisant des évaluations de code par des pairs
http://www.slideshare.net/SmartBear_Software/improve-quality-and-morale-using-peer-code-reviews

Ce que tout le monde devrait faire: Révision du code
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

Ces deux articles indiquent que l’un des objectifs de la révision du code est de partager les connaissances sur les bonnes techniques de développement, et pas seulement de rechercher les erreurs.

Donc, je dirais que c'est très important. Qui veut aller à une réunion et seulement être critiqué?

Quand je fais des revues de code, j’ai tendance à avoir un monologue en cours d’exécution, donc si je comprends ce que je lis, il y aura beaucoup de "Ok, je vois ce que ça fait .. Bon, ça relie à ça et appelle ça, ça va… et cette pièce dépend de ces deux-là ça va. ".

Je pense que de cette façon, ce n'est pas "oo la la c'est tellement génial!", Cela pourrait être un code ennuyeux parfaitement trivial, mais entendre quelqu'un d'autre analyser et montrer que la compréhension de ce que vous avez écrit est une forme de rétroaction positive en soi, le retour étant "Ce code a du sens", lorsque je tombe sur des parties que je ne comprends pas, je demande des explications et lorsque je le comprends, je m'écrie "Ah, je l'ai eu".

Je pense que ce simple transfert de compréhension est un éloge à un autre ingénieur car nous souhaitons tous que notre code soit compris par d'autres, cela donne une forme de validation implicite.

Cela dit, si vous voyez des parties du code qui ont des caractéristiques bonnes ou positives (même un code trivial ennuyeux peut être bon s'il s'agit de la forme minimale d'elle-même), j'ai tendance à énoncer ces caractéristiques, encore une fois, je ne les attribue pas comme "Wow!" génial!" autant que "je vois que ceci est une implémentation minimale" ou "Ok, cet algorithme complexe a beaucoup de commentaires", concentrez-vous sur les attributs du code et non sur le bonté ou le mal inhérent.

Chaque fois que vous attribuez le "bien" ou le "mal" à un code lors d'une révision de code pour éviter que l'ingénieur ne se sente mépris ou tenu sur un socle, ne dites pas que quelque chose est bon ou mauvais, mais parlez plutôt de la cause et de l'effet de leur code.

"Ok cette partie a du sens, ah il y a un nombre magique ici, le sens de cette valeur pourrait ne pas être bien compris par le prochain ingénieur qui toucherait cela"

"Je vois que vous avez un conteneur DI ici ok donc vous aurez un couplage lâche avec ce référentiel"

"Ah, il y a un dictionnaire statique ici, si plusieurs threads le touchent, nous pourrions rencontrer certaines conditions de concurrence"

Remarquez, je ne dis pas que tout soit bon ou mauvais, mais si l'ingénieur doit le changer ou non, il sera compris par l'ingénieur dont le code est en cours de révision. Évidemment, vous devez mettre fin à la révision du code avec un yay ou un nay, mais accumuler ces déclarations au fil de celle-ci adoucira les nay car des explications ont déjà été données sous la forme de déclarations de cause à effet lorsque vous leur dites: "J'aimerais bien ces nombres magiques fixés avant de vérifier ceci dans ".

Si je trouvais quelque chose dans une revue de code qui me plaisait vraiment et qui dépassait largement le code "assez bon", je donnerais des commentaires positifs.

En général, je pense que si quelqu'un écrit un code d'article qui vous fait dire "Waouh, c'est vraiment sympa!" alors oui, les commentaires positifs sont importants - cela montre à l'auteur que ce qu'ils ont fait a plu aux autres, et qu'ils devraient essayer de le faire à nouveau. Cependant, il ne suffit pas de suivre les directives et les pratiques standard. Donner des éloges parce que quelqu'un a bien mis en retrait ou ajouté des commentaires passe-partout pourrait placer la barre assez bas.

Ce n’est pas tant une question de programmation que c’est une question de gestion générale et d’interactions humaines. Les commentaires positifs dans les revues de code sont tout aussi importants que les commentaires positifs dans toutes sortes de revues.

Que cela soit nécessaire ou non (et dans quelle mesure), cela dépend de la disposition et de la composition émotionnelle de la personne à qui vous parlez. Certaines personnes réagissent beaucoup plus efficacement aux corrections lorsqu'elles sont associées à des éloges. D'autres voient les éloges comme peu sincères lorsqu'ils sont livrés avec correction.

La formule générale est parfois appelée "Feedback Sandwich": les bonnes choses en premier, les mauvaises choses en second, les bonnes choses en dernier. L'idée est de garder le ton général positif tout en veillant à ce que les commentaires négatifs soient reçus. Cela peut aider à prévenir le stress lors de l’anticipation d’un examen et à prévenir les rumeurs égocentriques par la suite. Les deux sont très importants en termes de productivité et de qualité. Ce n’est pas simplement une foutaise délicate et émotionnelle; C'est le comportement humain 101.

Encore une fois, vous devez connaître la personne avec laquelle vous travaillez et comprendre à quoi elle répond. Traiter avec les gens, c'est ça la gestion, et les bons gestionnaires savent comment faire réagir les gens.

Je pense que le retour d'information positif est très important et provient principalement d'une dynamique personnelle de realpolitik. Nous sommes tous assis et écrivons du code pendant des heures, des jours, des semaines, des mois et la plupart d'entre nous sommes fiers de ce que nous faisons. Les revues de code sont une chance de montrer cela.

Si vous passez à une révision de code et que le meilleur résultat que vous pouvez espérer est "pas de commentaire" (c.-à-d. Qu'il n'y a pas de bilan de réactions positives), la réunion pourrait facilement être intitulée dans "Découvrez comment les gens vous pensent mal, c'est mal". En conséquence, les développeurs vont commencer à être ennuyés par les critiques de code, voire à les craindre, ce qui nuit clairement à l’équipe. Les développeurs "oublieront" de faire réviser leur code ou développeront leur impuissance acquise et demanderont simplement à leurs critiques constants quoi faire à propos de tout pour ne pas se laisser abattre lors de ces réunions.

C'est bien beau de dire qu'en théorie, il est plus logique de réparer le mauvais et de demander à tout le monde de laisser les émotions à la porte, mais ce sont précisément des attitudes comme celle-là qui sont responsables pour les développeurs de représentants comme étant sourds sur le ton interpersonnel. Les théories mises à part, nous sommes des êtres humains et les êtres humains aiment recevoir une tape dans le dos de temps en temps, même minime. Ce truc compte.

C’est plus important si vous effectuez des examens côte à côte ou en équipe. Dans une critique écrite, pas de nouvelles, bonnes nouvelles. L'objectif est de faire entrer le code en production. Quand c'est votre code, vous devriez vous sentir bien dans votre peau.

La révision du code doit être utilisée comme source d'informations pour faciliter le mentorat et la gestion de l'équipe. Il existe de nombreuses possibilités de donner une rétroaction positive sans encombrer la base de données de révision de code. Des exemples peuvent être extraits pour être partagés avec d'autres.

Examiner le développeur autrement que son code représente beaucoup plus. Détourner le temps de révision du code peut être contre-productif pour faire sortir une application. Définissez un délai spécifique pour aider le développeur en dehors des révisions de code, mais cela ne signifie pas pour autant que vous devez exclure les commentaires relatifs à la révision de code.

Si je ne fais pas attention à éviter le "compliment de revers", le seul moyen auquel je puisse penser est de pouvoir vous donner un retour positif sur le code. La plupart des gens sont au courant de cela ... cela se traduit par des phrases comme: "Excellent travail, mais ..."

Si tout le monde vient à la réunion avec l’attitude qu'il ne s’agit pas d’un commentaire personnel du programmeur, mais bien d’un effort visant à améliorer les pratiques de codage pour la qualité de tout le système, tous les commentaires sont alors de "bons" commentaires. Les commentaires soulignant les moyens d'améliorer les pratiques de codage deviennent tout aussi importants que les commentaires soulignant une nouvelle méthode utile pour traiter un problème.

À tout le moins, si on ne va pas aussi loin, il faut souligner que le cycle de "bon retour, mauvais retour, bon retour, mauvais retour" dans le processus de révision même sentiment de compliment de revers. N'essayez pas de forcer une bonne rétroaction, essayez de renforcer les bons efforts et comblez des trous dans les connaissances.

Phrases dont j'ai le plus appris au fil des ans:

• "C'est une approche intéressante. Que se passe-t-il si nous devons prendre en compte [un autre cas d'utilisation]?"
• "Bien essayé! Saviez-vous que nous avons déjà une méthode pour le faire? Peut-être devrions-nous faire une analyse comparative pour voir quelle approche est la plus efficace."

Le workflow que j'ai le plus aimé avec les critiques de code était le suivant:

1. Dev soumet le correctif sur la liste de diffusion / l'outil en ligne.
2. Tous ceux qui ont besoin de soins s’intéressent au patch, suggèrent des améliorations.
3. Dev remonte à # 1
4. Si aucune amélioration n'est requise, les gens disent: "Bon travail, s'il vous plaît, engagez-vous". <- RETOUR POSITIF. Tout code accepté est bon. Moins les gens doivent vous dire de changer les choses, mieux vous vous portez.
5. Dev s'engage, passe à l'élément suivant.

Habituellement, les nouveaux développeurs obtiendraient beaucoup plus de commentaires «correctionnels» à mesure qu'ils se familiariseraient avec le code.

Les avantages de cette approche sont les suivants:

1. Tout le monde sait ce que tout le monde fait. Il n'y a pas de connaissance monopolisant ou mystère commet.
2. Tout le monde apprend des commentaires des autres. C'est important. Si les réactions ne se produisent qu'entre deux personnes dans une conversation face à face lors d'un jumelage, alors quelqu'un de l'autre côté de la salle ne bénéficiera pas de la même manière que s'il le faisait sur la liste de diffusion.
3. Les autres développeurs peuvent généralement détecter certains bogues avant qu'ils ne soient dans le contrôle de version.

Je ne suis pas du tout d'accord avec ça. Quelle est la différence entre les bonnes techniques de développement et les soi-disant codeurs Ninja capables d'écrire un code impressionnant mais inexplicable en simple mortel? Le développement logiciel est maintenant (IMO) une discipline du plus petit dénominateur commun où le flair et la ruse sont rejetés au profit de la facilité de maintenance et de la facilité de compréhension. C'est trop risqué.

Je ne peux pas penser à une fois où j'ai vu du code dans une critique qui me ferait dire «Oh c'est cool». Je ne peux que supposer que si je rencontrais un code comme celui-ci, il tomberait dans le camp Cool-Yet-Inacceptable.

Vous auriez également des problèmes avec les personnes qui n’obtiennent aucune réaction positive, peut-être même trop, en essayant de créer un gâchis éventuel "Faites-moi confiance, ça marche!".

Les revues de code servent à répartir la responsabilité de la qualité du code entre les membres de l’équipe, c’est-à-dire qu’un développeur ne peut être blâmé si un problème sérieux se pose plus tard. Utilisez-le pour trouver des problèmes, utilisez-le pour obtenir des explications du développeur original d'éléments étranges au cas où vous auriez à les entretenir. Personnellement, je suis plus intéressé à recevoir des commentaires négatifs. Les clients ne se soucient pas de la fraîcheur de votre code, mais seulement de ce qu'il fait ce qu'ils veulent.

Laissez le backslapping au pub.

Cela a compté pour moi. Je ne veux pas de commentaires de fluff ou de positivité pour des raisons de positivité. Si tout le code que j'ai écrit est de la merde, dis-moi pourquoi, corrigeons-le et apprenons. Mais si je fais quelque chose de bien, il est agréable de l'entendre une fois et de temps en temps. Je n'ai pas besoin de renforcement positif car tout ce que j'ai fait était "correct", mais même s'il s'agit d'un "améliorons X, Y et Z, mais le reste a l'air bien", c'est important.

Pas aussi important que les commentaires honnêtes. Je travaille pour une grande société financière et nos clients ne se soucient pas de savoir si le programmeur fait de gros efforts ou s'il est bon, ou s'il écrit un bon code! Ils ont besoin d'un logiciel qui fonctionne.

Je pense qu'il est important d'être complètement objectif. Vouloir remonter le moral en faisant des commentaires positifs est une perte de temps pour moi.

Cela peut signifier que les critiques de code sont indûment critiques - mais n'est-ce pas là le problème? Nous devrions également être critiques de nous-mêmes. Je trouve que l’hypothèse que le code que j’ai écrit est sans doute une ordure complète et qu’elle pourrait certainement être améliorée me pousse à améliorer mon code et mon niveau de compétence.

Si vous n'obtenez aucun commentaire, vous pouvez considérer que vous avez fait du bon travail.

Le mantra est simple: si on veut un code de qualité (qui est moins en réalité), il faut mettre en pratique les méthodes de révision appropriées. Cela dit, les commentaires positifs aident un développeur / programmeur à réfléchir et à proposer des idées / solutions / correctifs. Ne soyez pas trop sévère, mais soyez ferme sur le point. Questions / Réponses Les responsables doivent être informés des bonnes méthodologies et pratiques afin de pouvoir guider l'équipe (ou un membre) dans la bonne direction. Cela se traduit par la qualité. Période.

Lorsque le code est destiné à un concours ou soumis à un entretien d'embauche (en d'autres termes, un code écrit qui ne peut pas être réécrit), les commentaires positifs sont indispensables. En fait, vous devez vous assurer qu'il y a des retours positifs (si possible!) Et négatifs. De cette façon, le codeur sait où se trouvent ses forces et ses faiblesses et peut compenser.

Cependant, vous semblez parler dans un environnement de travail, où le code peut être réécrit. Dans ce cas, vous essayez de récupérer des bugs de votre système. Ainsi, dans cette situation, seuls les bugs négatifs ont une valeur.

Si cela vous met mal à l'aise, organisez une réunion hebdomadaire de révision du code, où tout le monde peut discuter à la fois du bon et du mauvais code.

EDIT: Bien que je dirai que si quelque chose vous impressionne assez, rien ne vous empêche d’exprimer vos louanges en personne. Le traqueur semble cependant ne servir qu’à la révision du code de production.