Recevoir des commentaires sur son code est souvent compliqué, surtout quand les commentaires sont des avis personnels et ne font pas avancer le problème.

Introduction

On a déjà tous donné: les commentaires de la revue de code sont tels qu’écrire “c’est de la merde” aurait été plus rapide pour un résultat similaire. S’ensuit la désagréable sensation de devoir réécrire intégralement cette portion de code sans réel fondement. Une telle revue est ridicule car elle fait perdre le temps de tous sans vraiment aider à progresser.

Back in the USSR

(Référence musicale de qualité!)

Ce genre de situation donne envie d’éviter certains “contrôleurs” de code inutilement stricts et finit par énerver toute l’équipe car rien n’avance correctement. Alors comment maximiser les bénéfices d’une revue de code? En utilisant la méthode “MoSCoW”: Must (doit), Should (devrait), Could (pourrait), Would (serait). Cette méthode permet d’indiquer le degré d’importance des commentaires et donc le degré d’attention que le développeur doit y porter.

Lors de la rédaction des commentaires, le contrôleur ordonnera les points selon les quatre niveaux M/S/C/W.

  • Must (doit): La modification proposée est obligatoire afin que le code soit approuvé. Il s’agit soit d’une erreur de programmation soit d’un non respect des standards de code. Ce type de point ne peut pas être ignoré.
  • Should (devrait): Il s’agit ici d’améliorations évidentes du code. Le développeur devra expliquer pourquoi il souhaite ignorer ce point, en accord avec le contrôleur (au besoin, prévoir un arbitre).
  • Could (pourrait): Ici le contrôleur propose des améliorations qui pourraient améliorer le code mais qui sont au delà du scope de la tâche à réaliser. Il s’agit plus d’un conseil qu’un point à corriger et le développeur peut l’ignorer sans autre.
  • Would (serait): C’est le code pour les remarques personnelles du commentateur, genre “j’aurais plutôt choisi ceci” ou “je n’aurais pas fait comme cela”. Ce genre de remarque demande souvent un gros travail de refonte mais il s’agit d’un choix personnel. C’est plus souvent pour aider les juniors à progresser rapidement ou entamer une discussion sur un thème précis.

Conclusion

Lorsqu’on réalise une revue de code, hiérarchiser les commentaires selon les quatre niveaux MoSCoW amène une vraie plus-value au processus. A essayer de toute urgence donc.