Face à un code review ou un débogage sans fin, on se demande parfois comment se simplifier la vie. En cherchant un peu, ou en tombant par hasard sur, on peut découvrir une phrase magique : "Analyse statique". Voyons ce que c'est et comment cela peut interagir avec votre projet.
En fait, si vous écrivez dans un langage moderne, alors, sans même vous en rendre compte, vous avez utilisé un analyseur statique. Tout simplement parce que tout compilateur moderne fournit, même de manière minime, un certain nombre d'avertissements concernant des problèmes potentiels dans le code. Par exemple, en compilant du code C++ dans Visual Studio, vous pouvez voir ce qui suit :
Dans cette sortie, nous voyons que la variable var n'a pas été utilisée nulle part dans la fonction. Vous avez donc presque toujours utilisé un simple analyseur statique. Cependant, contrairement à des analyseurs professionnels tels que Coverity, Klocwork ou PVS-Studio, les avertissements fournis par le compilateur ne peuvent indiquer qu'un petit éventail de problèmes.
Si vous ne savez pas vraiment ce qu'est l'analyse statique et comment l'implémenter, , pour vous familiariser plus en détail avec cette méthodologie.
Pourquoi a-t-on besoin de l'analyse statique ?
En deux mots : accélération et simplification.
L'analyse statique permet de trouver une multitude de problèmes dans le code : allant d'une mauvaise utilisation des constructions du langage à des 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 voir, il y a une faute de frappe dans la dernière ligne. Par exemple, PVS-Studio génère l'avertissement suivant :
Considérez la vérification de la validité de l'utilisation de l'élément 'y'.
Si vous voulez tester cette erreur par vous-même, essayez un exemple prêt à l'emploi sur Compiler Explorer : **.
Et comme vous le comprenez, il n'est pas toujours possible de faire attention à de tels morceaux de code immédiatement, et cela peut entraîner de longues heures de débogage, se demandant pourquoi tout fonctionne si étrangement.
Cependant, c'est une erreur manifeste. Que faire si le développeur a écrit un code non optimal parce qu'il a oublié une subtilité du langage ? Ou même a introduit dans le code ? К сожалению, подобные случаи совершенно обыденны и львиная часть времени тратится на то, чтобы отладить специфично работающий код, который содержит опечатки, типичные ошибки или undefined behavior.
C'est précisément pour ces situations que l'analyse statique a été créée. C'est un assistant pour le développeur, qui lui signalera divers problèmes dans le code et expliquera dans la documentation pourquoi il ne faut pas écrire de cette manière, quelles en sont les conséquences et comment les corriger. Voici un exemple de ce à quoi cela peut ressembler : **.
Vous pouvez trouver d'autres erreurs intéressantes que l'analiseur peut détecter dans les articles suivants :
Maintenant que vous avez lu ce matériel et que vous vous êtes convaincu de l'utilité de l'analyse statique, vous avez peut-être envie de l'essayer en pratique. Mais par où commencer ? Comment intégrer ce nouvel outil dans un projet existant ? Et comment familiariser l'équipe avec celui-ci ? Vous trouverez les réponses à ces questions ci-dessous.
Remarque. L'analyse statique ne remplace pas et n'annule pas quelque chose d'aussi utile que les revues de code. Elle complète ce processus, aidant à repérer et corriger à l'avance les fautes de frappe, les inexactitudes et les constructions dangereuses. Il est beaucoup plus productif de se concentrer lors des revues de code sur les algorithmes et la clarté du code, plutôt que de chercher une parenthèse mal placée ou .
0. Introduction à l'outil
Tout commence par une version d'essai. En effet, il est difficile de se décider à intégrer quoi que ce soit dans le processus de développement si l'on n'a jamais vu l'outil en action. C'est pourquoi la première étape consiste à télécharger .
Ce que vous apprendrez à cette étape :
- Quelles sont les méthodes pour interagir avec l'analiseur ;
- L'analiseur est-il compatible avec votre environnement de développement ;
- Quels problèmes existent actuellement dans vos projets.
Une fois que vous avez tout installé, la première chose à faire est de lancer l'analyse de l'ensemble du projet (, , ). Dans le cas de PVS-Studio dans Visual Studio, vous verrez une image similaire (cliquable) :
Le fait est qu'en général, pour des projets avec une base de code importante, les analyseurs statiques produisent un grand nombre d'avertissements. Il n'est pas nécessaire de tous les corriger, car votre projet fonctionne déjà, ce qui signifie que ces problèmes ne sont pas critiques. Cependant, vous et de les corriger si nécessaire. Pour cela, il faut filtrer la sortie et ne conserver que les messages les plus fiables. Dans le plugin PVS-Studio pour Visual Studio, cela se fait par un filtrage selon les niveaux et les catégories d'erreurs. Pour obtenir les résultats les plus précis, laissez activés uniquement Couverture d'ombre du soleil et Général (cliquable aussi) :
Il est en effet beaucoup plus simple de consulter 178 avertissements que plusieurs milliers...
Dans les onglets Élevé et Faible on trouve souvent de bons avertissements, cependant ces catégories incluent des diagnostics qui ont une précision (fiabilité) moindre. Pour en savoir plus sur les niveaux d'avertissements et les options de travail sous Windows, vous pouvez consulter ici : **.
Après avoir examiné les erreurs les plus intéressantes (et les avoir corrigées avec succès), il est temps de . Cela est nécessaire pour que les nouveaux avertissements ne se perdent pas parmi les anciens. De plus, l'analyseur statique est un assistant pour le programmeur, et non une liste de bugs. 🙂
1. Automatisation
Après la prise de contact, il est temps de configurer les plugins et de les intégrer dans le CI. Cela doit être fait avant que les programmeurs ne commencent à utiliser l'analyseur statique. En effet, le programmeur peut oublier d'activer l'analyse ou ne pas vouloir du tout. Pour cela, il est nécessaire de faire une vérification finale afin que le code non analysé ne puisse pas entrer dans la branche principale de développement.
Ce que vous apprendrez à cette étape :
- Quelles options d'automatisation l'outil propose ;
- Si l'analyseur est compatible avec votre système de build.
Puisque la documentation idéale n'existe pas, il arrive parfois qu'il faille écrire à . C'est normal, et nous sommes heureux de vous aider. 🙂
Et maintenant, passons aux services d'intégration continue (CI). N'importe quel analyseur peut y être intégré sans problèmes majeurs. Pour cela, il faut créer une étape distincte dans le pipeline, qui se trouve généralement après la compilation et les tests unitaires. Cela se fait à l'aide de diverses utilitaires en ligne de commande. Par exemple, PVS-Studio propose les utilitaires suivants :
- (analyse de solutions, projets C#, C++ sous Windows)
- (monitoring de la compilation)
- (analyse de projets C++ sous Linux / macOS)
- (analyse de solutions, projets C# sous Linux / macOS)
- (analyse de projets Java)
- (convertisseur de fichiers de rapport)
Pour intégrer l'analyse dans le CI, il faut faire trois choses :
- Installer l'analyseur ;
- Lancer l'analyse ;
- Livrer les résultats.
Par exemple, pour installer PVS-Studio sur Linux (basé sur Debian), il faut 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-studioDans les systèmes sous Windows, il n'est pas possible d'installer l'analyseur via un gestionnaire de paquets, mais il est possible de déployer l'analyseur depuis la ligne de commande :
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsPour en savoir plus sur le déploiement de PVS-Studio dans les systèmes sous Windows, vous pouvez lire **.
Après l'installation, il faut lancer directement l'analyse. Cependant, il est recommandé de le faire uniquement après la compilation et les tests. Cela est dû au fait que l'analyse statique nécessite 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 caractéristiques du projet, je vais montrer une option pour C++ (Linux) en exemple :
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wLa première commande effectuera l'analyse, et la seconde le rapport au format texte, l'affichera à l'écran et renverra un code de retour différent de 0 en cas d'avertissements. Un tel mécanisme est utile pour bloquer la construction en cas de messages d'erreur. Cependant, vous pouvez toujours supprimer le drapeau -w et ne pas bloquer la construction contenant des avertissements.
Remarque. Le format texte n'est pas pratique. Il est donné simplement à titre d'exemple. Notez le format de rapport plus intéressant — FullHtml. Il permet de naviguer dans le code.
Pour en savoir plus sur la configuration de l'analyse sur CI, vous pouvez lire l'article "" (Windows) ou "" (Linux).
Bien, vous avez configuré le fonctionnement de l'analyseur sur le serveur de construction. Maintenant, si quelqu'un a téléchargé du code non vérifié, l'étape de vérification échouera, et vous pourrez détecter le problème. Cependant, ce n'est pas très pratique, car il est plus efficace de vérifier le projet non pas après la fusion des branches, mais avant, lors de la demande de tirage.
En général, la configuration de l'analyse de la demande de tirage ne diffère pas beaucoup du lancement normal de l'analyse sur CI, à l'exception de la nécessité d'obtenir la liste des fichiers modifiés. En général, ils peuvent être obtenus en demandant la différence entre les branches à l'aide de git :
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listIl est maintenant nécessaire de transmettre cette liste de fichiers à l'analiseur. Par exemple, dans PVS-Studio, cela est réalisé à l'aide d'un drapeau. -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listPour en savoir plus sur l'analyse des pull requests, vous pouvez consulter ** Même si votre CI n'est 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 pull requests, vous pourrez bloquer les commits contenant des avertissements, créant ainsi une frontière que le code non vérifié ne pourra pas traverser.
Tout cela est certainement bien, mais j'aimerais pouvoir voir tous les avertissements au même endroit. Non seulement ceux du vérificateur statique, mais aussi ceux des tests unitaires ou de l'analyseur dynamique. Pour cela, divers services et plugins existent. PVS-Studio, par exemple, dispose d'un .
2. Intégration sur les machines des développeurs.
Il est maintenant temps d'installer et de configurer l'analiseur pour un usage quotidien lors du développement. À ce stade, vous avez déjà découvert la plupart des méthodes de travail, donc cela peut être considéré comme la partie la plus facile.
Comme option la plus simple, les développeurs peuvent eux-mêmes installer l'analiseur nécessaire. Cependant, cela prendra beaucoup de temps et les détournera de leur développement, c'est pourquoi vous pouvez automatiser ce processus en utilisant un installateur et les drapeaux nécessaires. Pour PVS-Studio, il existe différents . Cependant, il y a toujours des gestionnaires de paquets, comme Chocolatey (Windows), Homebrew (macOS) ou des dizaines d'options pour Linux.
Ensuite, il faudra installer les plugins nécessaires, par exemple pour , , etc.
3. Utilisation quotidienne.
À ce stade, il est temps de dire quelques mots sur les moyens d'accélérer le travail de l'analiseur lors de l'utilisation quotidienne. Une analyse complète de tout le projet prend beaucoup de temps, mais à quelle fréquence modifions-nous le code dans l'ensemble du projet ? Il est peu probable qu'il existe un refactoring si vaste qu'il affecte immédiatement tout le code. Le nombre de fichiers modifiés à la fois ne dépasse généralement pas une dizaine, c'est donc à ceux-là qu'il vaut la peine de s'intéresser. Pour une telle situation, il existe un . Ne vous inquiétez pas, ce n'est pas un autre outil. C'est un mode spécial qui permet d'analyser uniquement les fichiers modifiés et leurs dépendances, et cela se fait automatiquement après la compilation, 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 en informera automatiquement. Par exemple, PVS-Studio vous avertira par une notification :
Il ne suffit pas de dire aux développeurs d'utiliser l'outil. Il faut leur expliquer ce que c'est et comment cela fonctionne. Voici des articles sur le démarrage rapide avec PVS-Studio, mais de tels tutoriels sont disponibles pour tout outil que vous préférez :
Ces articles fournissent toutes les informations nécessaires pour une utilisation quotidienne et ne prennent pas beaucoup de temps. 🙂
Dès les premières étapes de découverte de l'outil, nous avons supprimé de nombreux avertissements lors de l'une des premières exécutions. Malheureusement, les analyseurs statiques ne sont pas parfaits, ils génèrent donc parfois des faux positifs. Les supprimer est généralement facile, par exemple, dans le plugin PVS-Studio pour Visual Studio, il suffit d'appuyer sur un bouton :
Cependant, vous pouvez également signaler ces derniers. Si le faux positif peut être corrigé, vous pouvez remarquer dans les futures mises à jour qu'il y a de moins en moins de faux positifs spécifiques à votre base de code.
Après intégration
Nous avons donc couvert toutes les étapes de l'intégration de l'analyse statique dans le processus de développement. Malgré l'importance de la configuration de tels outils dans le CI, l'endroit le plus crucial pour exécuter est l'ordinateur de développeur. Car l'analyseur statique n'est pas un juge qui vous dit, de loin, que le code n'est pas bon. Au contraire, c'est un assistant qui vous guide lorsque vous êtes fatigué et vous rappelle si vous avez oublié quelque chose.
Il est peu probable que l'analyse statique simplifie significativement le développement sans une utilisation régulière. En effet, son principal avantage pour les développeurs réside non seulement dans la recherche des parties de code complexes et controversées, mais aussi dans leur détection précoce. Vous conviendrez qu'il n'est pas seulement désagréable de découvrir un problème une fois que les modifications ont été envoyées en test, mais que cela prend également beaucoup de temps. L'analyse statique, lorsqu'elle est utilisée régulièrement, examine chaque changement directement sur votre ordinateur et signale les zones suspectes pendant que vous travaillez sur le code.
Et si vous ou vos collègues hésitez encore à adopter un analyseur, je vous propose de lire maintenant l'article "". Cet article traite des préoccupations typiques des développeurs selon lesquelles l'analyse statique prendrait leur temps, et ainsi de suite.
Si vous souhaitez partager cet article avec un public anglophone, merci d'utiliser le lien vers la traduction : Maxim Zvyagintsev. .
Source : habr.com
