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.
É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.
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.
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).
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.
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:
Fonctionne assez bien.
la source
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!
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.
la source