Revue de code, inspection de produit logiciel, audit de code source
L'objectif d'une revue de code est de trouver des bugs, de corriger les erreurs de conception, afin d'améliorer la qualité et la sécurité du logiciel. Elle intervient généralement à la fin des tests, au début de la phase de pilote, juste avant le passage en production. Ces étapes font partie du processus de développement logiciel dans les Méthodes Agiles (Scrum, Kanban) ou Extreme Programming.
La revue de code faite par un oeil exterieur permet d'encourager les discussions sur le code et de progresser.
L'inspection de produit logiciel peut s'appliquer à des documents de conception d'un logiciel, des spécifications, des codes sources, des tests.
Certains outils sont dédiés à la revue de code, comme: CodeStriker, JCR, Agile Review, Crew , Review Board, Rietveld
l’analyse statique permet d’effectuer des contrôles automatisés : respect de règles de coding, vérifier la complexité du code, taux de couverture des tests unitaires. Je pense à des outils comme Checkstyle, Clover, Lint, Findbugs, Sonar
Par contre, ces outils ne répondent pas à des questions plus abstraites, comme le respect du cahier des charges, la pertinence par rapport aux exigences, l'anticipation de changements technologiques futurs, la réutilisabilité, la bonne connaissance métier, l'éfficience de l'architecture, etc.
Un développeur programme d'une certaine manière bien à lui, issue de son experience passée. Le fait de pouvoir discuter avec un autre développeur à propos de son code permet de se faire une autre opinion et d'améliorer le programme.
Par exemple, avant de commencer une revue de code d'un programme, il faut regarder dans l'IDE le nombre de fichiers, de ressources associées au projet (à la solution...). Ceci afin d'estimer globalement le temps nécéssaire à la revue.
Ensuite, un coup d'oeil rapide permet de voir si l'indentation est bien faite: pour un meilleure lecture et compréhension du code. A ce niveau, nous pouvons appliquer certaines normes, comme par exemple le retourà la ligne ou pas après l'ouverture de l'accolade "{" à la fin de la méthode. Certains développeurs écrivent ça:
|
methode { } |
D'autres écrivent ça:
|
methode{ } |
Et j'ai rencontré certains développeurs qui alternaient. Donc la revue de code permet de mettre le développeur en face de ce genre de cas et de lui faire prendre consicience qu'il serait bien d'adopter une certaine rigueur pour uniformiser tout ça et gagner en visibilité
Dans le jargon dev, la CR, c'est la "Code Review", la revue de code
Evitons les lignes vides: des fois après un point-virgule, un retour à la ligne s'impose. Il arrive que le développeur appuie 2 fois très vite sur la touche "entrée" (défaut de clavier?) et une ligne vide est insérée. Certaines suites logicielles procèdent à de l'analyse statique. Ils comptent le nombre de lignes crées comme un gage de qualité: "moins il y a de lignes écrites, moins il risque d'y avoir de bugs". Quand dans un programme il y a des milliers de lignes de codes, voire des millions, les logiciels d'inspection automatisée pénalisent ces sauts de ligne.
Ensuite, le style: est-ce que les normes ont été respectées? Le nommage des variables en CamelCase par exemple. Soit on utilise le CamelCase, soit le PascalCase, mais pas les deux.
Vérification des constructeurs: est-ce qu'ils sont bien formés? Un constructeur pas très bien construit dans les règles de l'art en C# ou Java peut passer relativement bien par exemple, mais en C++ il peut y avoir des conséquences hasardeuses (plantages aléatoires selon l'état de la mémoire)
Est-ce que le développeur a respecté le philosophie: "Une classe = une responsabilité?"
Est-ce que le concept MVC (Model view controller) est respecté? Que fait ce pop-up d'affichage dans la partie "modèle"? Il ne devrait pas être là...
Pourquoi avoir choisi "public" alors que l'on aurait pu choisir "private" ou "friendly", "friend", "protected"... pour les membres, pour davantage de sécurité?
le nom du fichier est-il bien le nom donné à la classe? La classe commence-t-elle par une majuscule?
Bref. Pour mes revues de code, j'utilise les méthode de Dorothy Graham, Tom Gilb, et Michael Fagan, pour en moyenne 7 heure de "CR" (code review) pour 150 lignes de codes, soit une journée de travail.
Les célèbres Joe O'Brien and Jim Weirich lors d'une revue de code
Vous souhaitez une information sur la revue de code? Un conseil? Une expertise? Remplissez ce formulaire, je reviendrai vers vous dès que possible: