Analyse statique - de l'introduction à l'intégration

Fatigué des révisions de code ou du débogage sans fin, vous réfléchissez parfois à la façon de vous simplifier la vie. Et après avoir cherché un peu, ou tombé dessus par hasard, vous pouvez voir la phrase magique : « Analyse statique ». Voyons de quoi il s'agit et comment il peut interagir avec votre projet.

Analyse statique - de l'introduction à l'intégration
En fait, si vous écrivez dans une langue moderne, alors, sans même vous en rendre compte, vous l'avez exécuté via un analyseur statique. Le fait est que tout compilateur moderne fournit, même s'il est minuscule, un ensemble d'avertissements concernant des problèmes potentiels dans le code. Par exemple, lors de la compilation du code C++ dans Visual Studio, vous pouvez voir ce qui suit :

Analyse statique - de l'introduction à l'intégration
Dans cette sortie, nous voyons que la variable var n'a jamais été utilisé nulle part dans la fonction. Donc en réalité, vous avez presque toujours utilisé un simple analyseur de code statique. Cependant, contrairement aux analyseurs professionnels tels que Coverity, Klocwork ou PVS-Studio, les avertissements fournis par le compilateur ne peuvent indiquer qu'un petit nombre de problèmes.

Si vous ne savez pas avec certitude ce qu'est l'analyse statique et comment la mettre en œuvre, lire cet articlepour en savoir plus sur cette méthodologie.

Pourquoi avez-vous besoin d’une analyse statique ?

En un mot : accélération et simplification.

L'analyse statique vous permet de trouver de nombreux problèmes différents dans le code : de l'utilisation incorrecte des constructions du langage aux fautes de frappe. Par exemple, au lieu de

auto x = obj.x;
auto y = obj.y;
auto z = obj.z;

Vous avez écrit le code suivant :

auto x = obj.x;
auto y = obj.y;
auto z = obj.x;

Comme vous pouvez le constater, il y a une faute de frappe dans la dernière ligne. Par exemple, PVS-Studio émet l'avertissement suivant :

V537 Pensez à vérifier l'exactitude de l'utilisation de l'élément « y ».

Si vous souhaitez mettre la main sur cette erreur, essayez un exemple prêt à l'emploi dans l'Explorateur du compilateur : *клик*.

Et comme vous le comprenez, il n'est pas toujours possible de prêter attention à de telles sections de code tout de suite, et à cause de cela, vous pouvez vous asseoir pendant une bonne heure pour déboguer, en vous demandant pourquoi tout fonctionne si étrangement.

Mais c’est clairement une erreur. Et si le développeur écrivait du code sous-optimal parce qu’il avait oublié certaines subtilités du langage ? Ou même l'a autorisé dans le code comportement indéfini? Malheureusement, de tels cas sont tout à fait courants et la part du lion du temps est consacrée au débogage de code spécifiquement fonctionnel contenant des fautes de frappe, des erreurs typiques ou un comportement indéfini.

C'est pour ces situations qu'est apparue l'analyse statique. Il s'agit d'un assistant pour le développeur qui signalera divers problèmes dans le code et expliquera dans la documentation pourquoi il n'est pas nécessaire d'écrire de cette façon, à quoi cela peut conduire et comment y remédier. Voici un exemple de ce à quoi cela pourrait ressembler : *клик*.

Vous pouvez trouver des erreurs plus intéressantes que l'analyseur peut détecter dans les articles :

Maintenant que vous avez lu ce document et que vous êtes convaincu des avantages de l'analyse statique, vous voudrez peut-être l'essayer. Mais par où commencer ? Comment intégrer un nouvel outil dans votre projet actuel ? Et comment lui présenter l’équipe ? Vous trouverez ci-dessous les réponses à ces questions.

Note. L'analyse statique ne remplace ni n'annule une chose aussi utile que les révisions de code. Il complète ce processus, en aidant à remarquer et à corriger à l'avance les fautes de frappe, les inexactitudes et les conceptions dangereuses. Il est beaucoup plus productif de se concentrer sur les révisions de code sur les algorithmes et la clarté du code, plutôt que de chercher une parenthèse mal placée ou lire des fonctions de comparaison ennuyeuses.

0. Connaître l'outil

Tout commence par une version d'essai. En effet, il est difficile de décider d’introduire quelque chose dans le processus de développement si l’on n’a jamais vu l’outil en live auparavant. Par conséquent, la première chose à faire est de télécharger Version d'essai.

Ce que vous apprendrez à ce stade :

  • Quels sont les moyens d'interagir avec l'analyseur ;
  • L'analyseur est-il compatible avec votre environnement de développement ?
  • Quels problèmes rencontrez-vous actuellement dans vos projets ?

Après avoir installé tout ce dont vous avez besoin, la première chose à faire est de lancer une analyse de l'ensemble du projet (Windows, Linux/Unix, macOS). Dans le cas de PVS-Studio dans Visual Studio, vous verrez une image similaire (cliquable) :

Analyse statique - de l'introduction à l'intégration
Le fait est que les analyseurs statiques émettent généralement un grand nombre d'avertissements pour les projets comportant une base de code importante. Il n'est pas nécessaire de tous les résoudre, puisque votre projet fonctionne déjà, ce qui signifie que ces problèmes ne sont pas critiques. Cependant, vous vous pouvez consulter les avertissements les plus intéressants et corrigez-les si nécessaire. Pour ce faire, vous devez filtrer la sortie et laisser uniquement les messages les plus fiables. Dans le plugin PVS-Studio pour Visual Studio, cela se fait en filtrant par niveaux d'erreur et catégories. Pour obtenir le résultat le plus précis possible, ne laissez que Haute и Général (également cliquable) :

Analyse statique - de l'introduction à l'intégration
En effet, 178 avertissements sont bien plus faciles à visualiser que plusieurs milliers...

Dans les onglets Moyenne и Faible Il existe souvent de bons avertissements, mais ces catégories incluent les diagnostics moins précis (fiabilité). Plus d'informations sur les niveaux d'avertissement et les options pour travailler sous Windows peuvent être trouvées ici : *клик*.

Avoir examiné avec succès les erreurs les plus intéressantes (et les avoir corrigées avec succès) vaut la peine supprimer les avertissements restants. Cela est nécessaire pour que les nouveaux avertissements ne se perdent pas parmi les anciens. De plus, un analyseur statique est un assistant pour le programmeur, et non une liste de bugs. 🙂

1. Automatisation

Après avoir fait connaissance, il est temps de configurer les plugins et de les intégrer dans CI. Cela doit être fait avant que les programmeurs commencent à utiliser l'analyseur statique. Le fait est que le programmeur peut oublier d'activer l'analyse ou ne pas vouloir la faire du tout. Pour ce faire, vous devez effectuer une vérification finale de tout afin que le code non testé ne puisse pas entrer dans la branche de développement générale.

Ce que vous apprendrez à ce stade :

  • Quelles options d'automatisation l'outil propose-t-il ;
  • L'analyseur est-il compatible avec votre système d'assemblage ?

Comme une documentation parfaite n’existe pas, il faut parfois écrire soutenir. C'est normal et nous sommes heureux de vous aider. 🙂

Passons maintenant aux services d'intégration continue (CI). N’importe quel analyseur peut y être implémenté sans problème sérieux. Pour ce faire, vous devez créer une étape distincte dans le pipeline, qui est généralement située après la construction et les tests unitaires. Cela se fait à l'aide de divers utilitaires de console. Par exemple, PVS-Studio fournit les utilitaires suivants :

Pour intégrer l'analyse dans CI, vous devez faire trois choses :

  • Installez l'analyseur ;
  • Exécuter une analyse ;
  • Donner des résultats.

Par exemple, pour installer PVS-Studio sous Linux (base Debian), vous devez exécuter les commandes suivantes :

wget -q -O - https://files.viva64.com/etc/pubkey.txt 
    | sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list 
  https://files.viva64.com/etc/viva64.list
  
sudo apt-get update -qq
sudo apt-get install -qq pvs-studio

Sur les systèmes exécutant Windows, il n'existe aucun moyen d'installer l'analyseur depuis le gestionnaire de packages, mais il est possible de déployer l'analyseur depuis la ligne de commande :

PVS-Studio_setup.exe /verysilent /suppressmsgboxes 
/norestart /nocloseapplications

Vous pouvez en savoir plus sur le déploiement de PVS-Studio sur les systèmes exécutant Windows *ici*.

Après l'installation, vous devez exécuter l'analyse directement. Cependant, il est recommandé de le faire uniquement après la compilation et les tests réussis. En effet, l'analyse statique prend généralement deux fois plus de temps que la compilation.

Étant donné que la méthode de lancement dépend de la plate-forme et des fonctionnalités du projet, je vais montrer l'option pour C++ (Linux) à titre d'exemple :

pvs-studio-analyzer analyze -j8 
                            -o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -w

La première commande effectuera l'analyse, et la seconde enveloppesconvertit le rapport au format texte, l'affiche à l'écran et renvoie un code retour autre que 0 s'il y a des avertissements. Un mécanisme comme celui-ci peut être facilement utilisé pour bloquer une construction lorsqu'il y a des messages d'erreur. Cependant, vous pouvez toujours supprimer le drapeau -w et ne bloquez pas un assembly contenant des avertissements.

Note. Le format du texte n'est pas pratique. Il est fourni simplement à titre d'exemple. Faites attention à un format de rapport plus intéressant - FullHtml. Il vous permet de naviguer dans le code.

Vous pouvez en savoir plus sur la configuration de l'analyse sur CI dans l'article "PVS-Studio et intégration continue" (Windows) ou "Comment configurer PVS-Studio dans Travis CI" (Linux).

D'accord, vous avez configuré l'analyseur sur le serveur de build. Désormais, si quelqu'un télécharge du code non testé, l'étape de vérification échouera et vous pourrez détecter le problème. Cependant, ce n'est pas tout à fait pratique, car il est plus efficace de vérifier le projet non pas après la fusion des branches, mais avant lui, au stade de la pull request.

De manière générale, la mise en place d’une analyse pull request n’est pas très différente du lancement habituel d’une analyse sur CI. Sauf la nécessité d'obtenir une liste des fichiers modifiés. Ceux-ci peuvent généralement être obtenus en interrogeant les différences entre les branches à l'aide de git :

git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list

Vous devez maintenant transmettre cette liste de fichiers à l'analyseur en entrée. Par exemple, dans PVS-Studio, cela est implémenté à l'aide du drapeau -S:

pvs-studio-analyzer analyze -j8 
                            -o PVS-Studio.log 
                            -S .pvs-pr.list

Vous pouvez en savoir plus sur l'analyse des demandes de tirage *ici*. Même si votre CI ne figure pas dans la liste des services mentionnés dans l’article, la section générale consacrée à la théorie de ce type d’analyse vous sera utile.

En configurant l'analyse des demandes d'extraction, vous pouvez bloquer les validations contenant des avertissements, créant ainsi une limite que le code non testé ne peut pas franchir.

Tout cela est certainement bien, mais j'aimerais pouvoir voir tous les avertissements au même endroit. Non seulement à partir de l'analyseur statique, mais aussi à partir de tests unitaires ou de l'analyseur dynamique. Il existe différents services et plugins pour cela. PVS-Studio, par exemple, a plugin pour l'intégration dans SonarQube.

2. Intégration sur les machines des développeurs

Il est maintenant temps d'installer et de configurer l'analyseur pour une utilisation quotidienne en matière de développement. À ce stade, vous êtes déjà familiarisé avec la plupart des méthodes de travail, c'est donc la partie la plus simple.

Comme option la plus simple, les développeurs peuvent installer eux-mêmes l'analyseur nécessaire. Cependant, cela prendra beaucoup de temps et les détournera du développement. Vous pouvez donc automatiser ce processus à l'aide d'un programme d'installation et des indicateurs nécessaires. Pour PVS-Studio, il existe différents drapeaux pour l'installation automatisée. Cependant, il existe toujours des gestionnaires de packages, par exemple Chocolatey (Windows), Homebrew (macOS) ou des dizaines d'options pour Linux.

Ensuite vous devrez installer les plugins nécessaires, par exemple pour Visual Studio, IDÉE, la cavalière, et ainsi de suite

3. Utilisation quotidienne

À ce stade, il est temps de dire quelques mots sur les moyens d'accélérer l'analyseur lors d'une utilisation quotidienne. Une analyse complète de l'ensemble du projet prend beaucoup de temps, mais à quelle fréquence modifions-nous le code tout au long du projet en même temps ? Il n’existe pratiquement aucune refactorisation si importante qu’elle affecterait immédiatement l’ensemble de la base de code. Le nombre de fichiers modifiés simultanément dépasse rarement une douzaine, il est donc logique de les analyser. Pour une telle situation, il existe mode d'analyse incrémentielle. Ne vous inquiétez pas, ce n’est pas un autre outil. Il s'agit d'un mode spécial qui vous permet d'analyser uniquement les fichiers modifiés et leurs dépendances, et cela se produit automatiquement après la construction si vous travaillez dans un IDE avec le plugin installé.

Si l'analyseur détecte des problèmes dans le code récemment modifié, il le signalera indépendamment. Par exemple, PVS-Studio vous en informera à l'aide d'une alerte :

Analyse statique - de l'introduction à l'intégration
Bien entendu, il ne suffit pas de dire aux développeurs d’utiliser l’outil. Nous devons d’une manière ou d’une autre leur dire de quoi il s’agit et comment cela se passe. Voici, par exemple, des articles sur un démarrage rapide de PVS-Studio, mais vous pouvez trouver des didacticiels similaires pour n'importe quel outil que vous préférez :

De tels articles fournissent toutes les informations nécessaires à un usage quotidien et ne prennent pas beaucoup de temps. 🙂

Même au stade de la connaissance de l'outil, nous avons supprimé de nombreux avertissements lors d'un des premiers lancements. Malheureusement, les analyseurs statiques ne sont pas parfaits et donnent donc parfois de faux positifs. Il est généralement facile de les supprimer ; par exemple, dans le plugin PVS-Studio pour Visual Studio, il vous suffit de cliquer sur un bouton :

Analyse statique - de l'introduction à l'intégration
Cependant, vous pouvez faire plus que simplement les supprimer. Par exemple, vous pouvez signaler un problème au support. Si le faux positif peut être corrigé, alors dans les futures mises à jour, vous remarquerez qu'à chaque fois il y a de moins en moins de faux positifs spécifiques à votre base de code.

Après intégration

Nous avons donc parcouru toutes les étapes d'intégration de l'analyse statique dans le processus de développement. Malgré l’importance de configurer de tels outils sur CI, l’endroit le plus important pour les exécuter est l’ordinateur du développeur. Après tout, un analyseur statique n’est pas un juge qui dit quelque part loin de vous que le code n’est pas bon. Au contraire, c'est un assistant qui vous indique si vous êtes fatigué et vous rappelle si vous avez oublié quelque chose.

Certes, sans utilisation régulière, il est peu probable que l'analyse statique simplifie considérablement le développement. Après tout, son principal avantage pour un développeur ne réside pas tant dans la recherche de sections de code complexes et controversées, mais dans leur détection précoce. Convenez que découvrir un problème après l'envoi des modifications pour test est non seulement désagréable, mais prend également beaucoup de temps. L'analyse statique, lorsqu'elle est utilisée régulièrement, examine chaque modification directement sur votre ordinateur et signale les endroits suspects pendant que vous travaillez sur le code.

Et si vous ou vos collègues ne savez toujours pas si cela vaut la peine d'implémenter l'analyseur, alors je vous suggère maintenant de commencer à lire l'article "Raisons d'introduire l'analyseur de code statique PVS-Studio dans le processus de développement". Il répond aux préoccupations typiques des développeurs selon lesquelles l'analyse statique prendrait leur temps, etc.

Analyse statique - de l'introduction à l'intégration

Si vous souhaitez partager cet article avec un public anglophone, veuillez utiliser le lien de traduction : Maxim Zvyagintsev. Analyse statique : de la prise en main à l'intégration.

Source: habr.com

Ajouter un commentaire