Qu'est-ce qu'un état d'esprit utile lors de la réalisation d'un examen de code officiel


14

Notre équipe a récemment commencé à effectuer des révisions de code pour chaque enregistrement.

En tant que chef d'équipe, j'essaie de trouver un équilibre entre fournir trop de suggestions, ennuyer les développeurs et diminuer la production des équipes, et laisser aller le code que j'aurais écrit différemment.

Existe-t-il des preuves, des études ou des conseils provenant de sources bien connues qui suggèrent une approche utile?


2
La première question à se poser: pourquoi faites-vous des revues de code?
Philip Kendall

1
Je serais tenté d'attribuer une sorte d '«importance» à chaque élément de rétroaction. Vulnérabilité de sécurité critique = très haute importance. Bug = importance normale. Formatage du code = aucune importance (blâmez les outils qui ne se reformatent pas comme vous le souhaitez et non le programmeur).
Brendan

Cela pourrait vous intéresser
Laiv

La façon dont une personne aborde ou répond à une révision de code en dit long sur sa capacité à maintenir l'objectivité et à penser de manière critique. Parfois, les développeurs ont besoin d'une formation spécifique à cet effet.
Frank Hileman

Réponses:


15

Gardez à l'esprit les objectifs primordiaux: au final, seuls les logiciels qui fonctionnent comptent

L'examen par les pairs et l'examen du code d'enregistrement ont pour objectif d' améliorer la qualité . Mais il n'y a rien de pire pour la qualité qu'un développeur démotivé. En tant que chef d'équipe, votre rôle n'est pas d'approuver le code comme quelque chose que vous auriez pu écrire vous-même, mais de promouvoir le travail d'équipe et d'assurer le résultat global.

Définissez clairement la portée de votre évaluation

Gardez à l'esprit: ce n'est pas votre code, mais le code de l'équipe. Donc, concentrez-vous sur les choses qui pourraient conduire à de mauvais résultats.

  • Ne remettez pas en question la façon dont votre développeur a choisi de répondre aux exigences, sauf si vous êtes certain que cela ne fonctionnera pas (mais il aurait déjà dû échouer aux tests, non?)

  • Ne contestez pas les performances médiocres, sauf s'il existe une mesure indiquant où se situe le problème. L'optimisation prématurée est la racine de tout Mal ;-)

  • Si vous trouvez une conception ou une structure logicielle à contester, alors demandez-vous pourquoi elle n'a pas été prise à l'avance! Le code déjà écrit coûte cher à réécrire. Si cela se produit, il est temps de revoir vos pratiques de développement logiciel et de travail d'équipe au moins autant que le code.

  • veiller au respect des normes de codage établies. C'est le sujet le plus ennuyeux à discuter pour le réviseur et le révisé. Lorsque tout le monde a accepté d'utiliser des noms de classe en majuscules dans votre équipe et qu'un gars a une classe sans, est-ce une question de goût? Ou de l'efficacité et du risque du travail d'équipe?

Soit dit en passant, si vous pensez qu'une norme de codage ne vaut pas la peine d'être discutée, supprimez-la de vos normes et ne perdez pas de temps et d'énergie dessus.

Développer le leadership: le côté humain de la revue

En tant que chef d'équipe, vous pouvez trouver ici une opportunité de vous développer et de développer votre équipe, au-delà de la formalité d'un contrôle qualité:

  • Les révisions de code sont beaucoup plus agréables pour tout le monde, s'il y a un véritable échange. Donnez également à votre développeur l'occasion de montrer ses compétences (et oui, vous pourriez peut-être apprendre quelque chose de nouveau).
  • Ayez l'oreille ouverte à la critique des choix de conception ou des normes existantes. Parfois, les gens peuvent mieux faire face à de telles frustrations, simplement parce qu'ils peuvent en parler.
  • Accompagnez vos juniors: n'hésitez pas à donner des conseils ou des orientations de refactoring pour la prochaine itération. Ne faites pas cela avec les personnes âgées: dans un autre monde, votre rôle respectif aurait pu changer.

Profitez d'autres pratiques

Il y a deux ou trois choses que vous pouvez éviter dans la révision de code:

  • L'utilisation d'un analyseur de code statique dans votre chaîne de génération peut automatiser la recherche de bogues courants ou de constructions non portables, bien avant l'examen par les pairs. Certains outils peuvent même vérifier certaines de vos normes de codage .
  • Si vous avez des normes sur la disposition du code, utilisez un pré-commit pretty-print ou des formateurs similaires pour formater automatiquement le code comme requis. Ne passez jamais de temps sur quelque chose qu'un logiciel pourrait faire pour vous mieux et sans discuter :-)
  • Enfin, la qualité n'est pas seulement assurée par la revue, mais aussi par les tests. Si vous n'utilisez pas encore TDD , réfléchissez-y indépendamment de la révision du code.

"Logiciel fonctionnel"? Pas très utile. "Logiciel correct" - c'est ce que je préfère!
Frank Hileman

@FrankHileman En effet! Et précis, fiable, utilisable, performant et adapté à l'usage. Il s'agit juste de bien définir le terme "travailler" ;-)
Christophe

3

En tant que développeurs que nous sommes, l'état d'esprit doit rester toujours ouvert et sceptique en même temps.

Ouverte, car nous ne savons pas quand un développeur peut nous surprendre, et sceptique quant à nos propres idées car nous oublions souvent qu'en génie logiciel, il n'y a pas une seule façon correcte d'implémenter une solution. La raison d'être de nos solutions pourrait avoir du sens pour nous et n'en avoir pour les autres. Derrière une odeur de code, il pourrait y avoir une excellente idée. Peut-être que le développeur n'a pas trouvé le moyen de l'exprimer correctement.

Parce que nous (les humains) sommes terribles à communiquer, ne faites pas de fausses hypothèses, soyez prêt à demander au propriétaire du code le code que vous examinez. S'il échoue à coder l'idée selon les normes de l'entreprise, en tant que développeur principal, soyez prêt à le guider également.

Voici l'approche subjective. L'approche objective, l'OMI, est très bien expliquée dans cette question .

En plus du lien ci-dessus, l'ensemble des objectifs à atteindre (maintenabilité, lisibilité, portabilité, cohésion élevée, couplage lâche, etc.) ne sont pas nécessairement les Dix Commandements. Vous (l'équipe) devez être en mesure d'adapter ces objectifs à un point où l'équilibre entre qualité et productivité rend le travail confortable et «habitable pour les développeurs».

Je proposerais l'utilisation d'outils d'analyse de code statique pour mesurer la progression de la qualité en fonction de ces objectifs. Des outils comme SonarQube nous fournissent des portes de qualité et des profils de qualité qui peuvent être personnalisés en fonction de nos priorités. Il nous fournit également un outil de suivi des problèmes, où les développeurs peuvent être ciblés avec des problèmes liés à l'odeur de code, aux bogues, aux pratiques douteuses, etc.

Ce type d'outils peut être un bon point de départ, mais comme je l'ai dit, restez sceptique. Vous pouvez trouver certaines règles dans Sonar sans signification pour vous, alors n'hésitez pas à les ignorer ou à les supprimer de votre profil de qualité.


2

Se mêler du code du développeur pour les changements cosmétiques démotivera le développeur, mais dans des circonstances absolues, cela doit être fait. Le responsable doit trouver l'équilibre entre fournir une révision de code utile et apprendre à laisser tomber les lacunes mineures. https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/


quelles sont les «circonstances absolues» qui nécessitent des changements cosmétiques?
Ewan

1
Lorsque les directives de codage n'ont pas été suivies, les défauts de conception de code qui peuvent provoquer des fuites de mémoire sont des cas où le responsable ne peut pas se permettre de lâcher prise.
Nishanth Menon

Votre lien est mort
Greenonline

1

Quelques points à garder à l'esprit:

  1. Il s'agit autant de psychologie que de technologie, il n'y a donc pas de règle d'or ici.
  2. Ce qui concerne les gens, ce n'est pas seulement la connaissance mais aussi la culture et la position dans la hiérarchie.
  3. S'il s'agit d'un jeu "long" (entreprise stable et établie), une équipe bien intégrée où les gens se font confiance a généralement une valeur plus élevée que le code examiné. Il ne devrait pas être utilisé pour forcer des choses qui ne sont pas absolument nécessaires pour continuer. Le diable est dans les détails ...
  4. S'il s'agit d'un jeu "court" (projet parallèle, R&D, beaucoup de pigistes dans un groupe), les coûts de la CR surmontent souvent les aventures qui en découlent. Et l'attitude devrait être "juste faire wok"

-4

Il n'y a que deux choses qui comptent.

  1. Existe-t-il des tests automatisés pour toutes les exigences?
  2. Passent-ils tous?

Tout le reste est cosmétique et devrait être discuté au-dessus de la bière plutôt que d'être imposé comme une porte.

Si vous suivez cette vue, elle vous limite à une zone de mise au point étroite.

Les exigences sont-elles bonnes? Idéalement, vous devriez savoir avant de commencer la tâche, c'est-à-dire que les performances, la sécurité, etc. devraient tous être là

Les tests sont-ils de bons tests? Tout cas de bord manqué, teste-t-il bien l'exigence, etc. En fin de compte: Pouvez-vous écrire un test qui est pour une exigence existante mais qui échouera?


3
Diriez-vous qu'un code sans saut de ligne, avec uniquement des noms de variables à une seule lettre et autrement obscurci est acceptable? Tous les tests réussiraient, mais ce n'est pas maintenable .
Philip Kendall

Dans une revue de code? Oui. Dès que vous commencez à nommer son tout subjectif. Vous choisissez un exemple extrême, mais il y a de nombreux cas où les gens utilisent des itérateurs à lettre unique ou condensent du code en fonctions à ligne unique qui seraient considérées comme une bonne pratique
Ewan
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.