Bonnes lignes directrices et bonnes pratiques pour la révision obligatoire du code [clôturé]

Nous essayons de réviser le code obligatoire sur chaque commit - rien n'entre dans le master qui n'a pas été validé par au moins 1 personne non l'auteur - pendant quelques sprints. Nous avons adhéré à la fois aux développeurs et à la direction (ce qui est une situation incroyable) et nous voulons obtenir certains des avantages pour lesquels il est connu:

• réduction évidente des bogues
• plus de sensibilisation aux changements qui se produisent autour du projet
• l'effet "je sais que quelqu'un va regarder ça donc je ne serai pas paresseux" / anti-cowboy
• cohérence accrue au sein des projets et entre eux

Mais nous introduisons quelque chose qui est connu pour réduire la vitesse, et s'il est mal fait, cela pourrait créer une stupide étape bureaucratique dans le pipeline de validation qui ne fait que prendre du temps. Choses qui me préoccupent:

• les avis se résumant à une simple cueillette
• (hyperboliquement) des personnes ouvrant d'énormes problèmes architecturaux dans le cadre d'un examen de validation sur deux lignes.
• Je ne veux pas biaiser les réponses avec d'autres choses.

Bien que nous soyons tous des gens raisonnables et que nous ferons beaucoup d'auto-analyse, nous pourrions certainement utiliser des informations gagnées au combat sur le genre de choses que nous devrions essayer d'accomplir dans une session d'examen pour vraiment faire fonctionner les examens pour nous. . Quelles sont les directives et politiques que vous avez trouvées efficaces?

1. Faites des commentaires courts.

   Il est difficile de rester concentré, en particulier pendant la révision de code, pendant longtemps. De plus, les révisions de code longues peuvent indiquer soit qu'il y a trop de choses à dire sur le code (voir les deux points suivants), soit que l'examen devient une discussion sur des questions plus vastes, telles que l'architecture.

   En outre, un examen doit rester un examen, pas une discussion. Cela ne signifie pas que l'auteur du code ne peut pas répondre, mais cela ne devrait pas se transformer en un long échange d'opinions.

2. Évitez de revoir le code qui est trop mauvais.

   La révision du code de faible qualité est déprimante à la fois pour le réviseur et l'auteur du code. Si un morceau de code est terrible, une revue de code n'est pas utile. Au lieu de cela, l'auteur doit être invité à réécrire le code correctement.

3. Utilisez des vérificateurs automatisés avant l'examen.

   Les vérificateurs automatisés évitent de perdre un temps précieux à pointer des erreurs qui peuvent être trouvées automatiquement. Par exemple, pour le code C #, l'exécution de StyleCop, les mesures de code et en particulier l'analyse de code est une bonne occasion de trouver certaines des erreurs avant l'examen. Ensuite, l'examen du code peut être consacré à des points qui sont extrêmement difficiles à faire pour une machine.

4. Choisissez soigneusement les personnes qui effectuent les évaluations.

   Deux personnes qui ne peuvent pas se supporter ne feront pas une bonne révision de l'un des codes de l'autre. Le même problème se pose lorsqu'une personne ne respecte pas l'autre (que ce soit le critique ou l'auteur, soit dit en passant).

   De plus, certaines personnes sont tout simplement incapables de voir leur code révisé, elles ont donc besoin d'une formation et d'une préparation spécifiques pour comprendre qu'elles ne sont pas critiquées et qu'elles ne devraient pas le voir comme quelque chose de négatif. Faire un examen, non préparé, n'aidera pas, car ils seront toujours sur une défensive et n'écouteront aucun critique de leur code (prenant chaque suggestion comme critique).

5. Faites des examens informels et formels.

   Avoir une liste de contrôle permet de se concentrer sur un ensemble précis de défauts, en évitant de se consacrer à la cueillette de nit. Cette liste de contrôle peut contenir des points tels que:

   • Injection SQL,
   • Hypothèses erronées sur une langue pouvant entraîner des erreurs,
   • Situations spécifiques pouvant entraîner des erreurs, telles que la priorité de l'opérateur. Par exemple, en C #, cela var a = b ?? 0 + c ?? 0;peut sembler correct pour quelqu'un qui veut ajouter deux nombres annulables avec coalesce à zéro, mais ce n'est pas le cas.
   • Désallocation de la mémoire,
   • Chargement paresseux (avec ses deux risques: charger la même chose plus d'une fois et ne pas la charger du tout),
   • Débordements,
   • Structures de données (avec des erreurs comme une simple liste au lieu d'un ensemble de hachage, par exemple),
   • Validation des entrées et programmation défensive en général,
   • Sécurité des fils,
   • etc.

   J'arrête la liste ici, mais il y a des centaines de points qui peuvent figurer dans une liste de contrôle, selon les points faibles d'un auteur précis.

6. Ajustez progressivement la liste de contrôle.

   Afin de rester constructif et utile dans le temps, les listes de contrôle utilisées dans les examens formels doivent être ajustées dans le temps en fonction des erreurs trouvées. Par exemple, les premiers examens informels peuvent révéler un certain nombre de risques d'injection SQL. La vérification de l'injection SQL sera incluse dans la liste de contrôle. Lorsque, quelques mois plus tard, il apparaît que l'auteur fait désormais très attention aux requêtes dynamiques par rapport aux requêtes paramétrées, SQL Injection peut être supprimé de la liste de contrôle.

Nous avons presque une liste de contrôle:

• Montrez-moi la description de la tâche.
• Expliquez-moi le résultat et montrez-le que cela fonctionne. Exécutez différents scénarios (entrée non valide, etc.).
• Montrez-moi les tests réussis. Quelle est la couverture du test?
• Montrez-moi le code - c'est là que nous recherchons des inefficacités évidentes.

Fonctionne assez bien.

Je pense qu'une personne qui a le pouvoir sur les autres serait suffisante, administrateur ou modérateur pour couper les commentaires non pertinents, accélérer la révision des choses qui nécessitent une révision rapide. Décideur unique.

L'inconvénient serait que cette personne doit le faire comme tâche principale, alors qu'elle pourrait faire autre chose, et vous aimeriez probablement avoir la personne la plus expérimentée à ce poste.

La deuxième chose est d'automatiser autant que possible!

• contrôler les espaces blancs
• logiciel de contrôle de style
• builds automatisés avant révision du code
• tests automatisés avant révision du code

Ces choses supprimeront au moins certaines choses que les gens pourraient commenter sans besoin réel. S'il ne se construit pas ou n'a pas d'espaces de fin, il ne suffit pas pour la révision, corrigez-le et faites une nouvelle demande de révision. Si ce n'est pas le cas ou que certains tests échouent, il est évident que ce n'est pas suffisant.

Cela dépend en grande partie de vos technologies, mais trouvez le mieux ce que vous pouvez vérifier automatiquement.

Nous n'avons pas encore gagné cette bataille, mais c'est ce que nous avons trouvé utile.