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

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?

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.

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

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/

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"

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?