En communiquant avec les gens lors de conférences et dans les commentaires d'articles, nous rencontrons l'objection suivante: l'analyse statique réduit le temps consacré à la recherche d'erreurs, mais prend du temps aux programmeurs, ce qui élimine les avantages de son utilisation et ralentit même le processus de développement. Analysons cette objection et montrons qu'elle est sans fondement.
L'énoncé «l'analyse statique occupera une partie du temps de travail» indépendamment du contexte est vrai. La révision régulière des avertissements de l'analyseur statique émis pour un code nouveau ou modifié prend vraiment du temps. Cependant, la réflexion doit être poursuivie: mais le temps consacré à cela est bien inférieur à celui consacré à l'identification des erreurs par d'autres méthodes. Pire encore, l'apprentissage des bogues par les clients.
Ici, les tests unitaires peuvent être une très bonne analogie. Les tests unitaires prennent également du temps aux développeurs, mais ce n'est pas une raison pour ne pas les utiliser. L'avantage d'écrire du code meilleur et plus fiable lors de l'utilisation de tests unitaires dépasse 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 première approximation comme une extension des avertissements du compilateur. Naturellement, lorsqu'un programmeur voit un avertissement du compilateur, il y passe du temps. Il doit soit modifier le code, soit passer explicitement du temps à supprimer l'avertissement, par exemple en utilisant #pragma. Cependant, cette fois n'est pas une raison pour désactiver les avertissements du compilateur. Et si quelqu'un fait cela, cela sera interprété sans ambiguïté par les autres comme une inadéquation professionnelle.
Néanmoins, d'où vient la crainte de devoir passer du temps à avertir les analyseurs de code statique?
Tout est très simple. Les programmeurs qui sont encore nouveaux dans cette méthodologie confondent les tests et l'utilisation régulière. Au premier démarrage, 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é. Un analyseur réglé génère un petit nombre de faux positifs lors des lancements réguliers. En d'autres termes, la plupart des avertissements révèlent de vrais défauts ou un code d'odeur. Il est seulement important de faire ce réglage. C'est toute l'astuce qui transforme un analyseur statique du mal, qui prend du temps, en un ami et un assistant.
Tout analyseur statique produira d'abord beaucoup de faux positifs. Il y a plusieurs raisons à cela, et ce sujet mérite un article séparé. Naturellement, nous et les développeurs d'autres analyseurs avons du
mal avec les faux positifs. Mais il y aura toujours de nombreux points positifs si, sans préparation, vous prenez et exécutez soudainement l'analyseur sur un projet. Soit dit en passant, la même image avec les avertissements du compilateur. Supposons que vous ayez un grand projet que vous avez toujours construit, par exemple, à l'aide du compilateur Visual C ++. Supposons que le projet soit miraculeusement portable et compilé à l'aide de GCC. Même ainsi, vous recevrez une montagne d'avertissements du CCG. Quiconque a connu un changement de compilateur dans un grand projet comprend de quoi il s'agit.
Cependant, personne ne force à creuser constamment dans les montagnes d'ordures des avertissements après avoir changé le compilateur ou après avoir démarré l'analyseur. La prochaine étape naturelle consiste à configurer le compilateur ou l'analyseur. Ceux qui disent que «l'analyse des avertissements prend du temps» évalue la complexité de la mise en œuvre 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 et calme.
La configuration d'analyseurs et de compilateurs n'est pas aussi compliquée et laborieuse que les programmeurs aiment l'effrayer. Si vous êtes manager, ne les écoutez pas. Ils sont juste paresseux. Le programmeur peut raconter fièrement comment il a passé 3 jours à chercher le bogue trouvé par le testeur / client. Et c'est normal pour lui. Cependant, de son point de vue, il est inacceptable de passer une journée à configurer l'outil, après quoi une erreur similaire sera détectée avant d'entrer dans le système de contrôle de version.
Oui, de fausses alarmes seront présentes après le réglage. Mais leur nombre est exagéré. Il est tout à fait possible de configurer l'analyseur de sorte que le pourcentage de faux positifs soit de 10% à 15%. C'est-à-dire pour 9 défauts trouvés, un seul avertissement devra ê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, qui peut être trouvée plus en détail dans cet
article .
Encore une chose. Le programmeur peut s'opposer:
Eh bien, supposons que des analyses statiques régulières soient vraiment efficaces. Mais que faire du bruit initial? Sur notre grand projet, nous ne pourrons pas configurer l'outil pendant 1 jour promis. Une seule recompilation pour vérifier le prochain lot de paramètres prend plusieurs heures. Nous ne sommes pas prêts à passer quelques semaines sur tout cela.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, tout n'est pas facile dans un grand projet. Mais, premièrement, nous fournissons un support et aidons à intégrer PVS-Studio dans le processus de développement. Et deuxièmement, il n'est pas du tout nécessaire de commencer à trier tous les avertissements.
Étant donné que votre application fonctionne, cela signifie que les erreurs ne sont pas si critiques et vivent probablement dans du code rarement utilisé. De graves erreurs manifestes ont déjà été trouvées et corrigées à l'aide de méthodes plus lentes et plus coûteuses. Mais à ce sujet ci-dessous dans une
note . Maintenant, quelque chose d'autre est important pour nous. Cela n'a aucun sens de procéder à des modifications massives du code, corrigeant de nombreuses erreurs mineures. Avec autant de refactoring, quelque chose est facile à casser et il y aura plus de mal que de bien.
Il vaut mieux considérer les avertissements existants comme une dette technique. Il sera possible de revenir à la dette plus tard et de travailler progressivement avec les anciens avertissements. En utilisant
le mécanisme de suppression des alertes de masse , vous pouvez commencer rapidement à utiliser PVS-Studio dans un grand projet. Très brièvement, cela se passe comme ceci:
- Vous excluez les répertoires explicitement redondants (bibliothèques tierces) de l'analyse. Dans tous les cas, il est préférable d'effectuer ce réglage 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 supérieurs. L'équipe décide de commencer son utilisation régulière.
- Le projet est en cours de vérification. Tous les avertissements trouvés sont désactivés à l'aide du mécanisme de suppression de masse. En d'autres termes, tous les avertissements actuellement disponibles sont désormais considérés comme une dette technique, qui peut être remboursée ultérieurement.
- Le fichier résultant avec des avertissements supprimés est défini dans le système de contrôle de version. Ce fichier est volumineux, mais ce n'est pas effrayant. Vous effectuez cette opération une fois (ou, au moins, vous le ferez extrêmement rarement). Et maintenant, ce fichier apparaîtra dans tous les développeurs.
- Désormais, tous les développeurs voient des avertissements qui s'appliquent uniquement au code nouveau ou modifié. A partir de ce moment, l'équipe commence à bénéficier d'une analyse statique. Configurez progressivement l'analyseur et faites de la dette technique.
Soit dit en passant, le système de stockage des avertissements sans intérêt est assez intelligent. Les hachages sont stockés pour une chaîne avec une erreur potentielle, ainsi que pour la précédente et la suivante. Pour cette raison, si une ligne est ajoutée au début de l'un des fichiers, alors rien ne «se corrodera» et l'analyseur restera silencieux sur le code considéré comme un devoir technique.
J'espère que nous avons réussi à dissiper l'un des préjugés concernant l'analyse statique. Venez,
téléchargez et essayez notre analyseur de code statique PVS-Studio. Il détectera beaucoup d'erreurs dans les premières étapes et rendra votre code dans son ensemble plus fiable et de haute qualité.
RemarqueLors du développement d'un projet, de nouvelles erreurs apparaissent constamment et sont corrigées. Les erreurs non détectées «se déposent» dans le code pendant une longue période, puis bon nombre d'entre elles peuvent être détectées lors de l'exécution d'une analyse de code statique. De ce fait, il existe parfois un faux sentiment que les analyseurs statiques ne trouvent que des erreurs inintéressantes dans les sections de code rarement utilisées. Bien sûr, c'est le cas si vous n'utilisez pas correctement l'analyseur et ne l'exécutez que de temps en temps, par exemple, peu de temps avant la publication de la version. Plus sur ce sujet
ici . Oui, lors de la rédaction d'articles, nous effectuons nous-mêmes des contrôles ponctuels des projets ouverts. Mais nous avons un objectif différent. Nous voulons démontrer les capacités d'un analyseur de code pour détecter les défauts. Cette tâche a peu à voir avec l'amélioration de la qualité du code de projet dans son ensemble et la réduction des coûts associés à la correction des erreurs.
Liens supplémentaires:- PVS-Studio ROI .
- L'analyse statique améliorera la base de code des projets C ++ complexes .
- Heisenbug 2019. Rapport d'Ivan Ponomarev " Analyse continue du code statique ".
- Ivan Ponomarev. Intégrez une analyse statique dans le processus, ne cherchez pas de bugs avec .
Si vous souhaitez partager cet article avec un public anglophone, veuillez utiliser le lien vers la traduction: Andrey Karpov.
Traitement des objections: l'analyse statique occupera une partie du temps de travail .