Découvrez comment intégrer facilement l'analyse statique, les tests unitaires et d'autres méthodes de test de logiciels C et C++ dans votre pipeline CI/CD. Inscrivez-vous pour la démo >>

Évitez les révisions de code inefficaces en éliminant ces 7 mauvaises habitudes

Par Arthur Hicken

16 février 2017

4  min lire

Une solide pratique de révision de code par les pairs est connue pour améliorer la qualité des logiciels, voici donc quelques moyens d'éviter les mauvaises habitudes qui menacent de rendre vos révisions de code inefficaces.

Il est bien établi que l'examen par les pairs offre plus de valeur que ce à quoi on pourrait s'attendre. Comme indiqué dans l'excellent livre de Steve McConnell, Code complet, le taux moyen de détection des défauts est seulement:

  • 25% pour les tests unitaires
  • 35% pour les tests fonctionnels
  • 45% pour les tests d'intégration

En revanche, l'efficacité moyenne des inspections de conception et de code est de 55% et 60% - une statistique impressionnante en effet. Bien sûr, cela ne se concrétise que si ce que vous faites dans le cadre de l'examen par les pairs est efficace et efficient.
Au fil des ans, j'ai été témoin des nombreux écueils qui mènent à des évaluations par les pairs inefficaces. Éviter ces mauvaises habitudes peut être aussi efficace que d'en adopter de nouvelles bonnes! Éliminez les mauvaises habitudes ci-dessous pour éviter des évaluations par les pairs inefficaces.

1. Sous-utilisation des outils

Pour commencer, vous ne devriez pas examiner ou rechercher tout ce qui peut être fait par analyse statique. Cela peut inclure des problèmes de branding, des problèmes de style comme le placement bouclé {
ne me lancez pas;
},
ou en utilisant un algorithme de chiffrement spécifique. Si un outil peut le trouver pour vous, laissez-le. Libérez-vous pour approfondir les caractéristiques de l'algorithme, de la sécurité et des performances du code. Faire un travail intelligent plutôt qu'un travail fastidieux a également l'avantage de rendre l'examen plus intéressant à participer, ce qui le rend à son tour plus engageant et efficace.

2. Vérification lorsque le code / l'auteur n'est pas encore prêt

Il s'agit d'un problème classique qui imprègne en particulier les organisations centrées sur le calendrier. Il y a de fortes chances que si vous libérez en fonction d'une date, vous révisez également en fonction d'une date. La logique est la suivante: "Je n'ai pas encore terminé, mais nous avons déjà programmé un examen, alors regardons au moins ce que nous avons." Vous le savez aussi bien que moi - ce n'est pas un excellent moyen d'effectuer un examen efficace, alors arrêtez de le faire. Assurez-vous que l'auteur du code a terminé, et s'il n'est pas encore prêt, remettez-le jusqu'à ce qu'il le soit.

3. Passer trop de temps à l'examen

C'est un piège facile à tomber. Si l'examen prend trop de temps, vous devez repenser quelque chose. «Trop» peut être soit des sessions de révision qui durent plus d'une heure, soit des sessions qui consomment trop du calendrier de développement global. Si les révisions prennent plus d'une heure, vous essayez probablement de trop réviser à la fois. (Ou l'auteur n'était pas prêt pour la révision.) Après une heure de révision, l'efficacité potentielle diminue rapidement, en particulier pour les auteurs de code. Même si le commentaire n'était pas personnel au départ, après une révision inutilement longue, la critique peut s'aggraver et se sentir plus douloureuse.

4. Devenir personnel

L'examen par les pairs concerne le code, pas les personnes. Assurez-vous que vous parlez du code et non du développeur. Des déclarations telles que "Ce code ne s'adapte pas aussi bien que ce dont nous avons besoin" sont moins susceptibles d'offenser que "Vous avez mal écrit". À l'inverse, lorsque vous êtes la cible de critiques, soyez un bon sport. Reconnaissez que le code de chacun peut être amélioré et que vous pouvez tirer des leçons des données que vous obtenez. Quelle que soit la fin de l'examen sur lequel vous vous trouvez, vous pouvez probablement être plus gracieux pour faciliter un examen fluide, agréable et rapide. Pensez à la révision comme un excellent moyen d'obtenir un mentor gratuit - tout le monde veut obtenir un mentor, mais nous considérons rarement le processus de révision comme un processus de mentorat. Valoriser le mentorat peut vous aider à résister à le prendre personnellement.

5. Le faire à la fin

Ce n'est pas seulement une métaphore de la résolution du nouvel an - je suis vraiment convaincu que la plupart des pratiques de qualité logicielle devraient être traitées comme de l'exercice. Si vous essayez de les grignoter au dernier moment, ils ne seront pas efficaces. Vous ne pouvez pas courir sur un tapis roulant la veille d'un marathon, et vous ne pouvez pas faire votre évaluation par les pairs la veille de votre sortie.

6. Suivi incohérent

Le suivi d'un examen peut avoir une grande incidence sur la valeur de l'examen. Si vous trouvez des éléments lors d'un examen et que vous ne vérifiez pas qu'ils sont corrigés, vous perdez probablement votre temps. Le meilleur avantage se trouve dans un processus cohérent qui inclut la responsabilité. Assurez-vous que tout le monde sait ce que l'on attend d'eux et faites un suivi pour vous assurer que des correctifs sont en cours. Si rien n'est trouvé dans l'examen, soyez critique. Bien que cela puisse arriver de temps en temps, cela devrait certainement vous rendre suspect. Cela peut être un signe d'examens de contrepartie entre les développeurs, ou un signe que votre développement ne comprend pas la valeur de l'examen du code ou comment le faire correctement.

7. Critères incohérents

Si chaque critique ne recherche pas les mêmes choses, vous n'aurez aucune idée de l'efficacité de vos évaluations. La portée du point de vue des pairs doit être basée sur une politique sans ambiguïté qui est clairement écrite et peut être référencée. (Avoir une liste de contrôle peut sembler contraignant au début, mais cela aidera à maintenir l'examen sur la bonne voie et à remplir une double fonction si vous êtes dans un secteur de la conformité comme l'automobile ou le médical, et que vous devez prouver que vous avez effectué un examen efficace. .) L'élimination de l'ambiguïté demande plus de discipline que la simple rédaction de la politique, bien que ce soit une excellente première étape. Idéalement, vous étofferiez quelques scénarios en fonction de votre politique et demanderiez à différentes personnes comment elles le feraient. Il n'est pas rare de trouver des entreprises acceptant un statu quo où différents groupes font les choses différemment, et les deux pensent que l'autre groupe fait des erreurs, mais les deux sont autorisés en vertu de la politique ambiguë. Tu peux faire mieux. Mettez tout le monde sur la même longueur d'onde - cela améliorera votre qualité, fournira la cohérence nécessaire à l'évaluation et à l'amélioration, et vous protégera en cas de problème. Si vous êtes dans un environnement de conformité comme ISO 26262 ou FDA, avoir des critères cohérents rationalisera vos audits.

J'ai été témoin d'examens par les pairs dans une grande variété d'organisations et j'ai vu où cela pouvait être incroyablement utile, ainsi qu'une perte de temps totale. L'intégration des bons outils dans les bons processus vous aidera à vous assurer que vous tirez parti du processus. Soutenez votre système d'évaluation par les pairs sans mauvaise habitude avec un outil d'analyse statique sur lequel vous pouvez compter pour appliquer les normes et les meilleures pratiques, et concentrez-vous sur les défauts intéressants qui feront de vous un meilleur ingénieur.

Par Arthur Hicken

Arthur est impliqué dans la sécurité logicielle et l'automatisation des tests chez Parasoft depuis plus de 25 ans, aidant à la recherche de nouvelles méthodes et techniques (dont 5 brevets) tout en aidant les clients à améliorer leurs pratiques logicielles.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.