Parler aux gens lors de conférences et dans les commentaires d'articles, nous sommes confrontés à l'objection suivante: l'analyse statique réduit le temps de détection des erreurs, mais prend du temps aux programmeurs, ce qui annule les avantages de son utilisation et ralentit même le processus de développement. Obtenons cette objection redressée et essayons de montrer qu'elle est sans fondement.
L'énoncé «l'analyse statique enlèvera une partie du temps de travail» sorti du contexte est correct. Il faut certainement un certain temps pour examiner régulièrement les avertissements de l'analyseur, émis pour un code nouveau ou modifié. Cependant, nous devons continuer l'idée: mais le temps consacré à cela est bien inférieur au temps nécessaire pour trouver des erreurs par d'autres méthodes. Il est encore pire de découvrir les erreurs des utilisateurs.
Les tests unitaires peuvent être une très bonne analogie ici. Les tests unitaires prennent également du temps aux développeurs, mais ce n'est pas la raison pour ne pas les utiliser. Les avantages d'un code plus sûr et de meilleure qualité lors de l'utilisation de tests unitaires l'emportent sur le coût de leur écriture.
Autre analogie: les avertissements du compilateur. Il s'agit généralement d'un sujet très proche, car les avertissements des outils d'analyse statique peuvent être considérés comme une extension des avertissements du compilateur dans une certaine mesure. Naturellement, lorsqu'un programmeur voit un avertissement du compilateur, il passe un certain temps à y faire face. Il doit soit changer le code, soit passer clairement du temps à supprimer les avertissements, par exemple en utilisant #pragma. Cependant, cet engagement en termes de temps n'a jamais été la raison pour désactiver les avertissements du compilateur. Et si quelqu'un fait cela, cela sera interprété sans équivoque par les autres comme une incapacité professionnelle.
Cependant, d'où vient la peur de perdre du temps pour les avertissements des analyseurs de code statique?
La réponse est très simple. Les programmeurs qui ne connaissent pas encore cette méthodologie confondent les lancements d'essai et l'utilisation régulière. Lors de la première exécution, tous les analyseurs donnent une énorme liste d'avertissements, ce qui est même effrayant à regarder. La raison en est que l'analyseur n'est pas encore configuré. Alors qu'un analyseur configuré émet régulièrement un petit nombre de faux positifs. En d'autres termes, la plupart des avertissements indiquent des défauts réels ou des odeurs de code. Il est juste important de faire cette configuration. C'est l'astuce qui transforme un analyseur statique d'un mal qui perd du temps en un ami et un assistant.
Tout analyseur statique émettra d'abord de nombreux faux positifs. Il y a plusieurs raisons à cela, et ce sujet mérite un article séparé. Naturellement, les développeurs d'autres analyseurs et notre équipe
se battent contre les faux positifs. Mais il y aura toujours de nombreux avertissements, si vous prenez et exécutez l'analyseur sur un projet pour la première fois. Soit dit en passant, la même situation s'applique aux avertissements du compilateur. Supposons que vous ayez un grand projet que vous l'avez toujours construit, par exemple, avec le compilateur Visual C ++. Disons que le projet s'est miraculeusement avéré être portable et compilé à l'aide de GCC. Même ainsi, vous obtiendrez un tas d'avertissements de GCC. Les personnes qui ont connu un changement de compilateur dans un grand projet comprennent de quoi je parle.
Cependant, personne ne vous oblige à creuser constamment dans les tas d'avertissements après avoir changé le compilateur ou après avoir exécuté l'analyseur. La prochaine étape évidente consiste à configurer un compilateur ou un analyseur. Ceux qui disent que "l'analyse des avertissements prend du temps" évaluent la complexité de l'adoption de l'outil, ne pensant qu'à tous ces avertissements qui doivent être surmontés au début, mais ne pensent pas à une utilisation régulière sans hâte.
La configuration des analyseurs, ainsi que des compilateurs, n'est pas aussi difficile et laborieuse que les programmeurs aiment se frayer un chemin. Si vous êtes manager, ne les écoutez pas. Ils sont juste paresseux. Le programmeur peut dire fièrement comment il cherchait un bogue trouvé par le testeur / client pendant 3 jours. Et ça lui va. Cependant, de son point de vue, il n'est pas acceptable de passer une journée à configurer l'outil, après quoi une telle erreur sera détectée avant qu'elle n'entre dans le système de contrôle de version.
Oui, des faux positifs seront présents après la configuration. Mais leur nombre est exagéré. Il est tout à fait possible de configurer un analyseur pour que le pourcentage de faux positifs soit de 10% à 15%. C'est-à-dire que pour 9 défauts trouvés, un seul avertissement nécessitera d'être supprimé comme faux. Alors, où est la "perte de temps" ici? Dans le même temps, 15% est une valeur très réelle; vous pouvez en savoir plus à ce sujet dans cet
article .
Il reste encore une chose. Un programmeur peut s'opposer:
Eh bien, disons que les analyses statiques régulières sont vraiment efficaces. Mais que faire du bruit que j'obtiens la première fois? Sur notre grand projet, nous ne pourrons pas mettre en place l'outil pour 1 jour promis. Une simple recompilation pour vérifier le prochain lot de paramètres prend plusieurs heures. Nous ne sommes pas prêts à passer quelques semaines là-dessus.Et ce n'est pas un problème, mais une tentative pour trouver une raison de ne pas introduire quelque chose de nouveau. Bien sûr, dans un grand projet, tout est toujours difficile. Mais d'abord, nous fournissons un support et nous aidons à intégrer PVS-Studio dans le processus de développement. Et deuxièmement, il n'est pas nécessaire de commencer immédiatement à trier tous les avertissements.
Si votre application fonctionne, les bogues qui y existent ne sont pas si critiques et vivent probablement dans du code rarement utilisé. De graves erreurs évidentes ont déjà été trouvées et corrigées en utilisant des méthodes plus lentes et plus coûteuses. J'écrirai à ce sujet ci-dessous dans la
note . Ce n'est pas ce qui est d'une grande importance maintenant. Il est inutile de faire des modifications massives dans le code, corrigeant beaucoup d'erreurs insignifiantes. Avec un refactoring aussi important, il est facile de casser quelque chose et le mal sera plus que bon.
Il vaut mieux tenir compte des avertissements techniques de la dette existante. Vous pouvez revenir à la dette plus tard et travailler progressivement avec les anciens avertissements. En utilisant le mécanisme de suppression des avertissements de masse, vous pouvez commencer à utiliser PVS-Studio rapidement dans un grand projet. Voici une brève description de ce qui se passe:
- Vous excluez les répertoires manifestement redondants (bibliothèques tierces) de l'analyse. Vous feriez mieux de le faire au tout début afin de réduire le temps d'analyse.
- Vous essayez PVS-Studio et étudiez les avertissements les plus intéressants . Vous aimez les résultats et vous montrez l'outil à vos collègues et patrons. L'équipe décide de commencer à l'utiliser régulièrement.
- Le projet est en cours de vérification. Tous les avertissements supprimés sont désactivés à l'aide du mécanisme de suppression de masse. En d'autres termes, tous les avertissements que vous avez à ce stade sont désormais considérés comme une dette technique qui peut être révisée ultérieurement.
- Le fichier résultant avec des avertissements supprimés entre dans le système de contrôle de version. Ce fichier est volumineux, mais ça va. Vous effectuez ces actions une seule fois (ou, au moins, très rarement). Et maintenant, tous les développeurs auront ce fichier.
- Désormais, tous les développeurs voient des avertissements uniquement liés au code nouveau ou modifié. À partir de ce moment, l'équipe commence à bénéficier d'une analyse statique. Ensuite, vous configurez progressivement l'analyseur et gérez la dette technique.
Soit dit en passant, le système de stockage des avertissements sans intérêt est assez intelligent. Les hachages sont enregistrés pour la ligne avec une erreur potentielle, ainsi que pour la ligne précédente et la ligne suivante. Par conséquent, si vous ajoutez une ligne au début de l'un des fichiers, rien ne sera égaré et l'analyseur gardera le silence sur le code, qui est considéré comme une dette technique.
J'espère que j'ai réussi à dissiper l'une des idées préconçues sur l'analyse statique. Venez,
téléchargez et essayez notre analyseur de code statique PVS-Studio. Il détectera de nombreuses erreurs dans les premiers stades et rendra votre code généralement plus fiable et meilleur.
RemarqueLors du développement de tout projet, de nouvelles erreurs apparaissent et se corrigent constamment. Les erreurs non trouvées "se déposent" dans le code pendant une longue période, puis bon nombre d'entre elles peuvent être détectées lorsque l'analyse de code statique est appliquée. Cela donne parfois la fausse impression que les analyseurs statiques ne trouvent que des erreurs inintéressantes dans des morceaux de code rarement utilisés. Eh bien, c'est vrai - au cas où vous n'utilisez pas correctement l'analyseur et ne l'exécutez que de temps en temps, par exemple, peu de temps avant la version. Plus sur ce sujet est écrit
ici . Oui, nous vérifions nous-mêmes les projets open source lors de la rédaction d'articles. Mais nous avons un objectif différent. Nous nous concentrons sur la démonstration des capacités de l'analyseur de code à détecter les défauts. D'une manière générale, cette tâche n'a pas grand-chose à voir avec l'amélioration de la qualité du code du projet et la réduction des coûts de correction des erreurs.
Liens supplémentaires- PVS-Studio ROI .
- Pourquoi l'analyse statique peut améliorer une base de code C ++ complexe .
- Ivan Ponomarev. Introduisez l'analyse statique dans le processus, ne vous contentez pas de rechercher des bogues avec .