Qu'est-ce que l'analyse statique ?
Qu'est-ce que l'analyse statique ?
L'analyse statique est l'analyse automatique du code source sans exécuter l'application.
Lorsque l'analyse est effectuée pendant l'exécution du programme, elle est connue sous le nom d'analyse dynamique.
L'analyse statique est souvent utilisée pour détecter :
- Vulnérabilités de sécurité.
- Problèmes de performance.
- Non-respect des normes.
- Utilisation de structures de programmation obsolètes.
Comment fonctionne un outil d'analyse statique ?
Le concept de base commun à tous les outils d'analyse statique est la recherche dans le code source pour identifier des modèles de codage spécifiques associés à une sorte d'avertissement ou d'informations.
Cela pourrait être aussi simple que « les classes de test de JUnit 5 n'ont pas besoin d'être « publiques » ». Ou quelque chose de complexe à identifier, comme « une entrée de chaîne non fiable utilisée dans une instruction d'exécution SQL ».
La manière dont les outils d'analyse statique implémentent cette fonctionnalité varie.
- technologie d'analyse du code source pour créer un arbre syntaxique abstrait (AST),
- correspondance de texte avec des expressions régulières,
- une combinaison de ce qui précède.
La correspondance d'expressions régulières sur du texte est très flexible, il est facile d'écrire des règles de correspondance, mais elle peut souvent entraîner de nombreux faux positifs et les règles de correspondance ignorent le contexte de code environnant.
La correspondance AST traite le code source comme du code de programme, et pas seulement comme des fichiers remplis de texte. Cela permet une correspondance contextuelle plus spécifique et peut réduire le nombre de faux positifs signalés par rapport au code.
Analyse statique dans le cadre de l'intégration continue
L'analyse statique est souvent effectuée au cours du processus d'intégration continue (CI) pour générer un rapport sur les problèmes de conformité qui peut être examiné pour obtenir une vue objective de la base de code au fil du temps.
Certaines personnes utilisent l'analyse statique comme mesure objective de la qualité de leur code en configurant l'outil d'analyse statique pour ne mesurer que des parties spécifiques du code et ne générer des rapports que sur un sous-ensemble de règles.
L'objectivité est assurée par les règles utilisées car celles-ci ne varient pas dans leur évaluation du code au fil du temps. Il est clair que la combinaison des règles utilisées et de leur configuration est une décision subjective et différentes équipes choisissent d'utiliser des règles différentes à des moments différents.
L'exécution de l'analyse statique dans CI est utile mais peut retarder le retour d'information au programmeur. Les programmeurs ne reçoivent pas de feedback lorsqu'ils codent, ils le reçoivent plus tard lorsque le code est exécuté via l'outil d'analyse statique. Un autre effet secondaire de l'exécution de l'analyse statique dans CI est que les résultats sont plus faciles à ignorer.
Pour aider les équipes à accorder plus d'attention aux résultats de l'analyse statique, il est généralement possible de configurer une métrique de seuil dans le processus de génération pour qu'elle échoue si la métrique est dépassée, par exemple si un certain nombre de règles sont déclenchées.
Analyse statique dans l'EDI
Pour recevoir des commentaires plus rapidement, de nombreux plugins de l'EDI exécutent les règles d'analyse statique dans l'EDI à la demande ou périodiquement à mesure que le code change.
Les violations de règles peuvent alors être détectées dans l'EDI pendant que le programmeur écrit du code, et pour rendre les règles plus difficiles à ignorer, les violations peuvent souvent être configurées pour être affichées sous forme de code souligné dans l'éditeur.
Personnellement, je trouve que c'est un moyen utile d'améliorer mon codage, en particulier lorsque je travaille avec une nouvelle bibliothèque couverte par l'outil d'analyse statique. Bien que cela puisse être « bruyant » avec des faux positifs ou des règles qui ne vous intéressent pas. Mais ce problème est résolu en prenant la mesure supplémentaire de configurer l'outil d'analyse statique pour ignorer certaines règles.
Corriger le code en fonction de règles d'analyse statique
Avec la plupart des outils d'analyse statique, la correction de la règle est laissée au programmeur. Il doit donc comprendre la cause de la violation de la règle et comment la corriger.
Très peu d'outils d'analyse statique permettent également de corriger les violations, car la correction dépend souvent du contexte de l'équipe, de la technologie utilisée et des styles de codage convenus.
Règles par défaut
Une fausse confiance dans la qualité des règles peut survenir lorsque les outils d'analyse statique sont fournis avec des règles par défaut. Il est tentant de croire qu'elles couvrent tous les problèmes qu'un programmeur peut rencontrer et toutes les circonstances dans lesquelles ces règles devraient s'appliquer. Parfois, les circonstances dans lesquelles une règle doit s'appliquer peuvent être subtiles et difficiles à détecter.
L'espoir est qu'en utilisant un outil d'analyse statique et en étudiant plus en détail les règles et les violations, les programmeurs développeront les compétences nécessaires pour détecter et éviter le problème dans le contexte de leur domaine spécifique.
Lorsque le domaine nécessite des règles contextuelles, les outils d'analyse statique peuvent ne pas avoir de règles correspondant à votre domaine ou à votre bibliothèque. De plus, les outils peuvent souvent être difficiles à configurer et à développer.
Désagréments
Aucun de ces « désagréments » n'est insurmontable :
- faux positifs
- absence de correctifs
- configuration pour ignorer les règles
- ajout de règles spécifiques au contexte
Mais ils sont souvent utilisés comme excuses pour éviter d'utiliser les outils d'analyse statique en premier lieu, ce qui est dommage car l'utilisation de l'analyse statique peut être extrêmement utile pour :
- mettre en évidence de meilleures approches pour les développeurs juniors
- obtenir des commentaires rapides sur les violations de codage claires
- identifier les problèmes obscurs que le programmeur n'a jamais rencontrés auparavant
- confirmer que le programmeur a adopté une bonne approche de codage (lorsqu'aucune violation n'est signalée)
Outils d'analyse statique basés sur l'IDE
En tant que contributeur individuel à un projet, j'aime utiliser les outils d'analyse statique qui s'exécutent depuis l'EDI afin de recevoir rapidement des commentaires sur mon code.
Cela complète tout processus de révision des pull requests et l'intégration CI qu'un projet peut avoir.
J'essaie d'identifier les outils qui me donneront un avantage et amélioreront mon flux de travail individuel.
Lorsque les outils s'exécutent dans l'EDI, parce qu'ils ont tendance à partager la même interface graphique de base et la même approche de configuration, il peut être tentant de les visualiser de manière interchangeable.
Les outils peuvent avoir des fonctionnalités ou des ensembles de règles qui se chevauchent, mais pour en tirer le meilleur parti, j'installe plusieurs outils pour tirer parti de leurs points forts.
Les outils IDE d'analyse statique que j'utilise activement lors du codage sont répertoriés ci-dessous :
- les inspections IntelliJ intégrées - modèles de codage courants
- SpotBugs - erreurs courantes
- SonarLint - modèles d'utilisation courants
- CheckStyle - modèles de style courants
- Sensei de Secure Code Warrior - création de règles personnalisées
Je les utilise tous parce qu'ils fonctionnent bien ensemble pour se compléter et se compléter mutuellement.
Inspections IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà ses inspections.
Il s'agit de règles d'analyse statique qui sont signalées dans l'EDI. Certains d'entre eux disposent également d'options QuickFix pour réécrire le code afin de résoudre le problème.
Les règles sont configurables de manière activée et désactivée, et vous pouvez choisir le niveau d'erreur utilisé pour le mettre en évidence dans l'EDI.
Il existe de nombreuses inspections IntelliJ de qualité. Je le sais parce que je les ai lus en écrivant ceci. J'utilise les inspections IntelliJ par défaut et je ne les ai pas configurées, mais pour tirer pleinement parti des inspections, vous devez les lire, identifier celles qui correspondent à votre style de codage et configurer le niveau d'avertissement de manière à ce que vous les remarquiez dans le code.
L'avantage des inspections IntelliJ est qu'elles sont fournies gratuitement avec l'IDE et qu'elles aident à développer la mémoire musculaire de :
- en remarquant les avertissements et les erreurs dans la source lorsque vous écrivez du code
- passez la souris sur le code marqué pour connaître les violations des règles
- en utilisant alt+enter pour appliquer un QuickFix au problème
Repérez les bugs
Le Repérez les bugs Le plugin IntelliJ utilise l'analyse statique pour essayer de vous avertir des bogues dans votre code.
SpotBugs peut être configuré à partir des préférences d'IntelliJ pour scanner votre code. Les règles réelles utilisées se trouvent dans l'onglet Détecteur.
J'ai tendance à utiliser SpotBugs après avoir écrit et revu mon code, puis j'exécute la commande « Analyser les fichiers de projet, y compris les sources de test ».
Cela m'aide à identifier les bogues, le code mort et les optimisations évidentes. Cela m'oblige également à faire des recherches sur certaines des violations signalées pour m'aider à décider quoi faire.
SpotBugs détectera les problèmes mais ne propose aucune action QuickFix pour tenter de les résoudre.
SpotBugs est facile à configurer et je trouve que c'est un deuxième avis objectif utile à consulter dans mon IDE.
ソナー・リント
Le Sonar Lint plug-in.
SonarLint peut être configuré à partir des préférences IntelliJ pour sélectionner les règles selon lesquelles le code est validé.
Par défaut, SonarLint s'exécute en temps réel et affiche les problèmes liés au code actuel que vous modifiez.
SonarLint ne propose pas de solutions rapides, mais la documentation associée aux rapports de violation est généralement claire et bien documentée.
J'ai trouvé SonarLint utile par le passé pour m'avertir des nouvelles fonctionnalités de Java dont j'avais connaissance dans les nouvelles versions de Java.
Vérifiez le style
Le Vérifiez le style Le plugin propose un mélange de règles de formatage et de qualité du code.
Le plugin CheckStyle est fourni avec « Sun Checks » et « Google Checks ».
Les définitions de celles-ci peuvent être facilement trouvé en ligne.
CheckStyle ajoute le plus de valeur lorsqu'un projet a passé du temps à créer son propre ensemble de règles. Ensuite, le plugin IDE peut être configuré pour utiliser cet ensemble de règles et les programmeurs peuvent effectuer un scan avant de valider le code dans CI.
CheckStyle est très souvent utilisé comme plugin d'échec de construction pour les processus CI lorsque le nombre de violations de CheckStyle dépasse un seuil.
先生
Senseï utilise une analyse statique basée sur un arbre de syntaxe abstrait (AST) pour faire correspondre le code et créer des QuickFix, ce qui permet une identification très spécifique du code présentant des problèmes.
L'AST permet aux QuickFIX associés à une recette de comprendre le code environnant. Par exemple, lors de l'ajout d'une nouvelle classe dans le code, toute importation pour cette classe ne sera ajoutée au fichier source qu'une seule fois, et non pour chaque remplacement.
Sensei a été créé pour faciliter la création de règles de correspondance personnalisées qui peuvent ne pas exister, ou qui seraient difficiles à configurer, dans d'autres outils.
Plutôt que de modifier un fichier de configuration, toutes les configurations peuvent être effectuées dans l'interface graphique. Lors de la création de nouvelles recettes, l'interface graphique permet de voir facilement à quel code correspond la recette. Et lors de la définition des QuickFix, l'état avant et après du code peut être comparé immédiatement. Cela permet de créer plus facilement des recettes très contextuelles, c'est-à-dire propres aux équipes, à la technologie et même aux programmeurs individuels.
J'utilise Sensei en combinaison avec d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne les résoudront pas. Un cas d'utilisation courant pour Sensei consiste à reproduire la recherche correspondante de l'autre outil dans Sensei et à l'étendre à l'aide d'une solution rapide. Cela présente l'avantage que le correctif personnalisé appliqué répond déjà aux normes de codage de votre projet.
Je me retrouve régulièrement à créer des recettes Sensei qui existent déjà dans le set IntelliJ Intensions parce que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé ou parce que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.
Je complète les outils existants, plutôt que d'essayer de les remplacer complètement.
Sensei peut également être très utile lorsque vous identifiez une variante contextuelle d'une règle commune. Par exemple, si vous utilisez une bibliothèque SQL non prise en charge par l'outil d'analyse statique, mais que les règles SQL courantes du moteur d'analyse statique s'appliquent toujours, vous pouvez créer des variantes spécifiques à la bibliothèque de ces règles à l'aide de Sensei.
Sensei ne propose pas de nombreuses recettes génériques, comme les outils d'analyse statique mentionnés, mais sa force réside dans le fait qu'il facilite la création de nouvelles recettes, avec des QuickFix configurés pour correspondre à votre style de codage et à vos cas d'utilisation spécifiques.
REMARQUE : nous travaillons sur un référentiel public de recettes pour couvrir les cas d'utilisation génériques, et vous pouvez le trouver ici.
Résumé
J'ai tendance à choisir des outils qui fonctionnent ensemble, qui sont configurables et faciles à développer pour répondre à mon contexte spécifique. J'utilise les outils d'analyse statique de l'EDI depuis des années pour m'aider à identifier les problèmes et à en savoir plus sur les langages de programmation et les bibliothèques que j'utilise.
J'utilise tous les outils mentionnés en combinaison :
- IntelliJ Intentions permet de signaler les problèmes de code courants dès le départ, souvent avec des correctifs rapides associés.
- SpotBugs détecte des bogues simples que j'ai peut-être oubliés et m'alerte en cas de problèmes de performances.
- SonarLint identifie les fonctionnalités de Java que je ne connaissais pas et m'invite à d'autres méthodes pour modéliser mon code.
- CheckStyle m'aide à me conformer à un style de codage convenu qui est également appliqué pendant le CI.
- Sensei m'aide à créer des QuickFix pour compléter les scénarios courants trouvés par les outils d'analyse statique et créer des recettes de projets ou de technologies spécifiques qui peuvent être difficiles à configurer dans un autre outil.
---
Installez Sensei depuis IntelliJ en utilisant « Préférences \ Plugins » (Mac) ou « Paramètres \ Plugins » (Windows), puis recherchez simplement « code sécurisé Sensei ».
Vous pouvez trouver un référentiel d'exemples de code et de recettes pour les cas d'utilisation courants sur le compte GitHub de Secure Code Warrior, dans le cadre du projet `sensei-blog-examples`.
https://github.com/securecodewarrior/sensei-blog-examples
Découvrez l'analyse statique et comment elle peut vous aider à écrire un meilleur code grâce à des exemples de 5 approches et plugins basés sur l'IDE.
アラン・リチャードソンは、20年以上にわたり、開発者として、またテスターからテスト責任者まで、あらゆるレベルのテストに携わってきたプロフェッショナルなIT経験を持っています。アラン・リチャードソンは、Secure Code Warrior のデベロッパーリレーションズの責任者として、チームと直接連携し、高品質で安全なコードの開発を促進しています。また、「Dear Evil Tester」や「Java For Testers」など4冊の著書があります。また、テクニカルWebテストやSelenium WebDriver with Javaを学ぶためのオンライントレーニングcourses を作成しています。アランは、SeleniumSimplified.com、EvilTester.com、JavaForTesters.com、CompendiumDev.co.ukに執筆やトレーニングビデオを掲載している。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約する
アラン・リチャードソンは、20年以上にわたり、開発者として、またテスターからテスト責任者まで、あらゆるレベルのテストに携わってきたプロフェッショナルなIT経験を持っています。アラン・リチャードソンは、Secure Code Warrior のデベロッパーリレーションズの責任者として、チームと直接連携し、高品質で安全なコードの開発を促進しています。また、「Dear Evil Tester」や「Java For Testers」など4冊の著書があります。また、テクニカルWebテストやSelenium WebDriver with Javaを学ぶためのオンライントレーニングcourses を作成しています。アランは、SeleniumSimplified.com、EvilTester.com、JavaForTesters.com、CompendiumDev.co.ukに執筆やトレーニングビデオを掲載している。
Qu'est-ce que l'analyse statique ?
L'analyse statique est l'analyse automatique du code source sans exécuter l'application.
Lorsque l'analyse est effectuée pendant l'exécution du programme, elle est connue sous le nom d'analyse dynamique.
L'analyse statique est souvent utilisée pour détecter :
- Vulnérabilités de sécurité.
- Problèmes de performance.
- Non-respect des normes.
- Utilisation de structures de programmation obsolètes.
Comment fonctionne un outil d'analyse statique ?
Le concept de base commun à tous les outils d'analyse statique est la recherche dans le code source pour identifier des modèles de codage spécifiques associés à une sorte d'avertissement ou d'informations.
Cela pourrait être aussi simple que « les classes de test de JUnit 5 n'ont pas besoin d'être « publiques » ». Ou quelque chose de complexe à identifier, comme « une entrée de chaîne non fiable utilisée dans une instruction d'exécution SQL ».
La manière dont les outils d'analyse statique implémentent cette fonctionnalité varie.
- technologie d'analyse du code source pour créer un arbre syntaxique abstrait (AST),
- correspondance de texte avec des expressions régulières,
- une combinaison de ce qui précède.
La correspondance d'expressions régulières sur du texte est très flexible, il est facile d'écrire des règles de correspondance, mais elle peut souvent entraîner de nombreux faux positifs et les règles de correspondance ignorent le contexte de code environnant.
La correspondance AST traite le code source comme du code de programme, et pas seulement comme des fichiers remplis de texte. Cela permet une correspondance contextuelle plus spécifique et peut réduire le nombre de faux positifs signalés par rapport au code.
Analyse statique dans le cadre de l'intégration continue
L'analyse statique est souvent effectuée au cours du processus d'intégration continue (CI) pour générer un rapport sur les problèmes de conformité qui peut être examiné pour obtenir une vue objective de la base de code au fil du temps.
Certaines personnes utilisent l'analyse statique comme mesure objective de la qualité de leur code en configurant l'outil d'analyse statique pour ne mesurer que des parties spécifiques du code et ne générer des rapports que sur un sous-ensemble de règles.
L'objectivité est assurée par les règles utilisées car celles-ci ne varient pas dans leur évaluation du code au fil du temps. Il est clair que la combinaison des règles utilisées et de leur configuration est une décision subjective et différentes équipes choisissent d'utiliser des règles différentes à des moments différents.
L'exécution de l'analyse statique dans CI est utile mais peut retarder le retour d'information au programmeur. Les programmeurs ne reçoivent pas de feedback lorsqu'ils codent, ils le reçoivent plus tard lorsque le code est exécuté via l'outil d'analyse statique. Un autre effet secondaire de l'exécution de l'analyse statique dans CI est que les résultats sont plus faciles à ignorer.
Pour aider les équipes à accorder plus d'attention aux résultats de l'analyse statique, il est généralement possible de configurer une métrique de seuil dans le processus de génération pour qu'elle échoue si la métrique est dépassée, par exemple si un certain nombre de règles sont déclenchées.
Analyse statique dans l'EDI
Pour recevoir des commentaires plus rapidement, de nombreux plugins de l'EDI exécutent les règles d'analyse statique dans l'EDI à la demande ou périodiquement à mesure que le code change.
Les violations de règles peuvent alors être détectées dans l'EDI pendant que le programmeur écrit du code, et pour rendre les règles plus difficiles à ignorer, les violations peuvent souvent être configurées pour être affichées sous forme de code souligné dans l'éditeur.
Personnellement, je trouve que c'est un moyen utile d'améliorer mon codage, en particulier lorsque je travaille avec une nouvelle bibliothèque couverte par l'outil d'analyse statique. Bien que cela puisse être « bruyant » avec des faux positifs ou des règles qui ne vous intéressent pas. Mais ce problème est résolu en prenant la mesure supplémentaire de configurer l'outil d'analyse statique pour ignorer certaines règles.
Corriger le code en fonction de règles d'analyse statique
Avec la plupart des outils d'analyse statique, la correction de la règle est laissée au programmeur. Il doit donc comprendre la cause de la violation de la règle et comment la corriger.
Très peu d'outils d'analyse statique permettent également de corriger les violations, car la correction dépend souvent du contexte de l'équipe, de la technologie utilisée et des styles de codage convenus.
Règles par défaut
Une fausse confiance dans la qualité des règles peut survenir lorsque les outils d'analyse statique sont fournis avec des règles par défaut. Il est tentant de croire qu'elles couvrent tous les problèmes qu'un programmeur peut rencontrer et toutes les circonstances dans lesquelles ces règles devraient s'appliquer. Parfois, les circonstances dans lesquelles une règle doit s'appliquer peuvent être subtiles et difficiles à détecter.
L'espoir est qu'en utilisant un outil d'analyse statique et en étudiant plus en détail les règles et les violations, les programmeurs développeront les compétences nécessaires pour détecter et éviter le problème dans le contexte de leur domaine spécifique.
Lorsque le domaine nécessite des règles contextuelles, les outils d'analyse statique peuvent ne pas avoir de règles correspondant à votre domaine ou à votre bibliothèque. De plus, les outils peuvent souvent être difficiles à configurer et à développer.
Désagréments
Aucun de ces « désagréments » n'est insurmontable :
- faux positifs
- absence de correctifs
- configuration pour ignorer les règles
- ajout de règles spécifiques au contexte
Mais ils sont souvent utilisés comme excuses pour éviter d'utiliser les outils d'analyse statique en premier lieu, ce qui est dommage car l'utilisation de l'analyse statique peut être extrêmement utile pour :
- mettre en évidence de meilleures approches pour les développeurs juniors
- obtenir des commentaires rapides sur les violations de codage claires
- identifier les problèmes obscurs que le programmeur n'a jamais rencontrés auparavant
- confirmer que le programmeur a adopté une bonne approche de codage (lorsqu'aucune violation n'est signalée)
Outils d'analyse statique basés sur l'IDE
En tant que contributeur individuel à un projet, j'aime utiliser les outils d'analyse statique qui s'exécutent depuis l'EDI afin de recevoir rapidement des commentaires sur mon code.
Cela complète tout processus de révision des pull requests et l'intégration CI qu'un projet peut avoir.
J'essaie d'identifier les outils qui me donneront un avantage et amélioreront mon flux de travail individuel.
Lorsque les outils s'exécutent dans l'EDI, parce qu'ils ont tendance à partager la même interface graphique de base et la même approche de configuration, il peut être tentant de les visualiser de manière interchangeable.
Les outils peuvent avoir des fonctionnalités ou des ensembles de règles qui se chevauchent, mais pour en tirer le meilleur parti, j'installe plusieurs outils pour tirer parti de leurs points forts.
Les outils IDE d'analyse statique que j'utilise activement lors du codage sont répertoriés ci-dessous :
- les inspections IntelliJ intégrées - modèles de codage courants
- SpotBugs - erreurs courantes
- SonarLint - modèles d'utilisation courants
- CheckStyle - modèles de style courants
- Sensei de Secure Code Warrior - création de règles personnalisées
Je les utilise tous parce qu'ils fonctionnent bien ensemble pour se compléter et se compléter mutuellement.
Inspections IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà ses inspections.
Il s'agit de règles d'analyse statique qui sont signalées dans l'EDI. Certains d'entre eux disposent également d'options QuickFix pour réécrire le code afin de résoudre le problème.
Les règles sont configurables de manière activée et désactivée, et vous pouvez choisir le niveau d'erreur utilisé pour le mettre en évidence dans l'EDI.
Il existe de nombreuses inspections IntelliJ de qualité. Je le sais parce que je les ai lus en écrivant ceci. J'utilise les inspections IntelliJ par défaut et je ne les ai pas configurées, mais pour tirer pleinement parti des inspections, vous devez les lire, identifier celles qui correspondent à votre style de codage et configurer le niveau d'avertissement de manière à ce que vous les remarquiez dans le code.
L'avantage des inspections IntelliJ est qu'elles sont fournies gratuitement avec l'IDE et qu'elles aident à développer la mémoire musculaire de :
- en remarquant les avertissements et les erreurs dans la source lorsque vous écrivez du code
- passez la souris sur le code marqué pour connaître les violations des règles
- en utilisant alt+enter pour appliquer un QuickFix au problème
Repérez les bugs
Le Repérez les bugs Le plugin IntelliJ utilise l'analyse statique pour essayer de vous avertir des bogues dans votre code.
SpotBugs peut être configuré à partir des préférences d'IntelliJ pour scanner votre code. Les règles réelles utilisées se trouvent dans l'onglet Détecteur.
J'ai tendance à utiliser SpotBugs après avoir écrit et revu mon code, puis j'exécute la commande « Analyser les fichiers de projet, y compris les sources de test ».
Cela m'aide à identifier les bogues, le code mort et les optimisations évidentes. Cela m'oblige également à faire des recherches sur certaines des violations signalées pour m'aider à décider quoi faire.
SpotBugs détectera les problèmes mais ne propose aucune action QuickFix pour tenter de les résoudre.
SpotBugs est facile à configurer et je trouve que c'est un deuxième avis objectif utile à consulter dans mon IDE.
ソナー・リント
Le Sonar Lint plug-in.
SonarLint peut être configuré à partir des préférences IntelliJ pour sélectionner les règles selon lesquelles le code est validé.
Par défaut, SonarLint s'exécute en temps réel et affiche les problèmes liés au code actuel que vous modifiez.
SonarLint ne propose pas de solutions rapides, mais la documentation associée aux rapports de violation est généralement claire et bien documentée.
J'ai trouvé SonarLint utile par le passé pour m'avertir des nouvelles fonctionnalités de Java dont j'avais connaissance dans les nouvelles versions de Java.
Vérifiez le style
Le Vérifiez le style Le plugin propose un mélange de règles de formatage et de qualité du code.
Le plugin CheckStyle est fourni avec « Sun Checks » et « Google Checks ».
Les définitions de celles-ci peuvent être facilement trouvé en ligne.
CheckStyle ajoute le plus de valeur lorsqu'un projet a passé du temps à créer son propre ensemble de règles. Ensuite, le plugin IDE peut être configuré pour utiliser cet ensemble de règles et les programmeurs peuvent effectuer un scan avant de valider le code dans CI.
CheckStyle est très souvent utilisé comme plugin d'échec de construction pour les processus CI lorsque le nombre de violations de CheckStyle dépasse un seuil.
先生
Senseï utilise une analyse statique basée sur un arbre de syntaxe abstrait (AST) pour faire correspondre le code et créer des QuickFix, ce qui permet une identification très spécifique du code présentant des problèmes.
L'AST permet aux QuickFIX associés à une recette de comprendre le code environnant. Par exemple, lors de l'ajout d'une nouvelle classe dans le code, toute importation pour cette classe ne sera ajoutée au fichier source qu'une seule fois, et non pour chaque remplacement.
Sensei a été créé pour faciliter la création de règles de correspondance personnalisées qui peuvent ne pas exister, ou qui seraient difficiles à configurer, dans d'autres outils.
Plutôt que de modifier un fichier de configuration, toutes les configurations peuvent être effectuées dans l'interface graphique. Lors de la création de nouvelles recettes, l'interface graphique permet de voir facilement à quel code correspond la recette. Et lors de la définition des QuickFix, l'état avant et après du code peut être comparé immédiatement. Cela permet de créer plus facilement des recettes très contextuelles, c'est-à-dire propres aux équipes, à la technologie et même aux programmeurs individuels.
J'utilise Sensei en combinaison avec d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne les résoudront pas. Un cas d'utilisation courant pour Sensei consiste à reproduire la recherche correspondante de l'autre outil dans Sensei et à l'étendre à l'aide d'une solution rapide. Cela présente l'avantage que le correctif personnalisé appliqué répond déjà aux normes de codage de votre projet.
Je me retrouve régulièrement à créer des recettes Sensei qui existent déjà dans le set IntelliJ Intensions parce que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé ou parce que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.
Je complète les outils existants, plutôt que d'essayer de les remplacer complètement.
Sensei peut également être très utile lorsque vous identifiez une variante contextuelle d'une règle commune. Par exemple, si vous utilisez une bibliothèque SQL non prise en charge par l'outil d'analyse statique, mais que les règles SQL courantes du moteur d'analyse statique s'appliquent toujours, vous pouvez créer des variantes spécifiques à la bibliothèque de ces règles à l'aide de Sensei.
Sensei ne propose pas de nombreuses recettes génériques, comme les outils d'analyse statique mentionnés, mais sa force réside dans le fait qu'il facilite la création de nouvelles recettes, avec des QuickFix configurés pour correspondre à votre style de codage et à vos cas d'utilisation spécifiques.
REMARQUE : nous travaillons sur un référentiel public de recettes pour couvrir les cas d'utilisation génériques, et vous pouvez le trouver ici.
Résumé
J'ai tendance à choisir des outils qui fonctionnent ensemble, qui sont configurables et faciles à développer pour répondre à mon contexte spécifique. J'utilise les outils d'analyse statique de l'EDI depuis des années pour m'aider à identifier les problèmes et à en savoir plus sur les langages de programmation et les bibliothèques que j'utilise.
J'utilise tous les outils mentionnés en combinaison :
- IntelliJ Intentions permet de signaler les problèmes de code courants dès le départ, souvent avec des correctifs rapides associés.
- SpotBugs détecte des bogues simples que j'ai peut-être oubliés et m'alerte en cas de problèmes de performances.
- SonarLint identifie les fonctionnalités de Java que je ne connaissais pas et m'invite à d'autres méthodes pour modéliser mon code.
- CheckStyle m'aide à me conformer à un style de codage convenu qui est également appliqué pendant le CI.
- Sensei m'aide à créer des QuickFix pour compléter les scénarios courants trouvés par les outils d'analyse statique et créer des recettes de projets ou de technologies spécifiques qui peuvent être difficiles à configurer dans un autre outil.
---
Installez Sensei depuis IntelliJ en utilisant « Préférences \ Plugins » (Mac) ou « Paramètres \ Plugins » (Windows), puis recherchez simplement « code sécurisé Sensei ».
Vous pouvez trouver un référentiel d'exemples de code et de recettes pour les cas d'utilisation courants sur le compte GitHub de Secure Code Warrior, dans le cadre du projet `sensei-blog-examples`.
https://github.com/securecodewarrior/sensei-blog-examples
Qu'est-ce que l'analyse statique ?
L'analyse statique est l'analyse automatique du code source sans exécuter l'application.
Lorsque l'analyse est effectuée pendant l'exécution du programme, elle est connue sous le nom d'analyse dynamique.
L'analyse statique est souvent utilisée pour détecter :
- Vulnérabilités de sécurité.
- Problèmes de performance.
- Non-respect des normes.
- Utilisation de structures de programmation obsolètes.
Comment fonctionne un outil d'analyse statique ?
Le concept de base commun à tous les outils d'analyse statique est la recherche dans le code source pour identifier des modèles de codage spécifiques associés à une sorte d'avertissement ou d'informations.
Cela pourrait être aussi simple que « les classes de test de JUnit 5 n'ont pas besoin d'être « publiques » ». Ou quelque chose de complexe à identifier, comme « une entrée de chaîne non fiable utilisée dans une instruction d'exécution SQL ».
La manière dont les outils d'analyse statique implémentent cette fonctionnalité varie.
- technologie d'analyse du code source pour créer un arbre syntaxique abstrait (AST),
- correspondance de texte avec des expressions régulières,
- une combinaison de ce qui précède.
La correspondance d'expressions régulières sur du texte est très flexible, il est facile d'écrire des règles de correspondance, mais elle peut souvent entraîner de nombreux faux positifs et les règles de correspondance ignorent le contexte de code environnant.
La correspondance AST traite le code source comme du code de programme, et pas seulement comme des fichiers remplis de texte. Cela permet une correspondance contextuelle plus spécifique et peut réduire le nombre de faux positifs signalés par rapport au code.
Analyse statique dans le cadre de l'intégration continue
L'analyse statique est souvent effectuée au cours du processus d'intégration continue (CI) pour générer un rapport sur les problèmes de conformité qui peut être examiné pour obtenir une vue objective de la base de code au fil du temps.
Certaines personnes utilisent l'analyse statique comme mesure objective de la qualité de leur code en configurant l'outil d'analyse statique pour ne mesurer que des parties spécifiques du code et ne générer des rapports que sur un sous-ensemble de règles.
L'objectivité est assurée par les règles utilisées car celles-ci ne varient pas dans leur évaluation du code au fil du temps. Il est clair que la combinaison des règles utilisées et de leur configuration est une décision subjective et différentes équipes choisissent d'utiliser des règles différentes à des moments différents.
L'exécution de l'analyse statique dans CI est utile mais peut retarder le retour d'information au programmeur. Les programmeurs ne reçoivent pas de feedback lorsqu'ils codent, ils le reçoivent plus tard lorsque le code est exécuté via l'outil d'analyse statique. Un autre effet secondaire de l'exécution de l'analyse statique dans CI est que les résultats sont plus faciles à ignorer.
Pour aider les équipes à accorder plus d'attention aux résultats de l'analyse statique, il est généralement possible de configurer une métrique de seuil dans le processus de génération pour qu'elle échoue si la métrique est dépassée, par exemple si un certain nombre de règles sont déclenchées.
Analyse statique dans l'EDI
Pour recevoir des commentaires plus rapidement, de nombreux plugins de l'EDI exécutent les règles d'analyse statique dans l'EDI à la demande ou périodiquement à mesure que le code change.
Les violations de règles peuvent alors être détectées dans l'EDI pendant que le programmeur écrit du code, et pour rendre les règles plus difficiles à ignorer, les violations peuvent souvent être configurées pour être affichées sous forme de code souligné dans l'éditeur.
Personnellement, je trouve que c'est un moyen utile d'améliorer mon codage, en particulier lorsque je travaille avec une nouvelle bibliothèque couverte par l'outil d'analyse statique. Bien que cela puisse être « bruyant » avec des faux positifs ou des règles qui ne vous intéressent pas. Mais ce problème est résolu en prenant la mesure supplémentaire de configurer l'outil d'analyse statique pour ignorer certaines règles.
Corriger le code en fonction de règles d'analyse statique
Avec la plupart des outils d'analyse statique, la correction de la règle est laissée au programmeur. Il doit donc comprendre la cause de la violation de la règle et comment la corriger.
Très peu d'outils d'analyse statique permettent également de corriger les violations, car la correction dépend souvent du contexte de l'équipe, de la technologie utilisée et des styles de codage convenus.
Règles par défaut
Une fausse confiance dans la qualité des règles peut survenir lorsque les outils d'analyse statique sont fournis avec des règles par défaut. Il est tentant de croire qu'elles couvrent tous les problèmes qu'un programmeur peut rencontrer et toutes les circonstances dans lesquelles ces règles devraient s'appliquer. Parfois, les circonstances dans lesquelles une règle doit s'appliquer peuvent être subtiles et difficiles à détecter.
L'espoir est qu'en utilisant un outil d'analyse statique et en étudiant plus en détail les règles et les violations, les programmeurs développeront les compétences nécessaires pour détecter et éviter le problème dans le contexte de leur domaine spécifique.
Lorsque le domaine nécessite des règles contextuelles, les outils d'analyse statique peuvent ne pas avoir de règles correspondant à votre domaine ou à votre bibliothèque. De plus, les outils peuvent souvent être difficiles à configurer et à développer.
Désagréments
Aucun de ces « désagréments » n'est insurmontable :
- faux positifs
- absence de correctifs
- configuration pour ignorer les règles
- ajout de règles spécifiques au contexte
Mais ils sont souvent utilisés comme excuses pour éviter d'utiliser les outils d'analyse statique en premier lieu, ce qui est dommage car l'utilisation de l'analyse statique peut être extrêmement utile pour :
- mettre en évidence de meilleures approches pour les développeurs juniors
- obtenir des commentaires rapides sur les violations de codage claires
- identifier les problèmes obscurs que le programmeur n'a jamais rencontrés auparavant
- confirmer que le programmeur a adopté une bonne approche de codage (lorsqu'aucune violation n'est signalée)
Outils d'analyse statique basés sur l'IDE
En tant que contributeur individuel à un projet, j'aime utiliser les outils d'analyse statique qui s'exécutent depuis l'EDI afin de recevoir rapidement des commentaires sur mon code.
Cela complète tout processus de révision des pull requests et l'intégration CI qu'un projet peut avoir.
J'essaie d'identifier les outils qui me donneront un avantage et amélioreront mon flux de travail individuel.
Lorsque les outils s'exécutent dans l'EDI, parce qu'ils ont tendance à partager la même interface graphique de base et la même approche de configuration, il peut être tentant de les visualiser de manière interchangeable.
Les outils peuvent avoir des fonctionnalités ou des ensembles de règles qui se chevauchent, mais pour en tirer le meilleur parti, j'installe plusieurs outils pour tirer parti de leurs points forts.
Les outils IDE d'analyse statique que j'utilise activement lors du codage sont répertoriés ci-dessous :
- les inspections IntelliJ intégrées - modèles de codage courants
- SpotBugs - erreurs courantes
- SonarLint - modèles d'utilisation courants
- CheckStyle - modèles de style courants
- Sensei de Secure Code Warrior - création de règles personnalisées
Je les utilise tous parce qu'ils fonctionnent bien ensemble pour se compléter et se compléter mutuellement.
Inspections IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà ses inspections.
Il s'agit de règles d'analyse statique qui sont signalées dans l'EDI. Certains d'entre eux disposent également d'options QuickFix pour réécrire le code afin de résoudre le problème.
Les règles sont configurables de manière activée et désactivée, et vous pouvez choisir le niveau d'erreur utilisé pour le mettre en évidence dans l'EDI.
Il existe de nombreuses inspections IntelliJ de qualité. Je le sais parce que je les ai lus en écrivant ceci. J'utilise les inspections IntelliJ par défaut et je ne les ai pas configurées, mais pour tirer pleinement parti des inspections, vous devez les lire, identifier celles qui correspondent à votre style de codage et configurer le niveau d'avertissement de manière à ce que vous les remarquiez dans le code.
L'avantage des inspections IntelliJ est qu'elles sont fournies gratuitement avec l'IDE et qu'elles aident à développer la mémoire musculaire de :
- en remarquant les avertissements et les erreurs dans la source lorsque vous écrivez du code
- passez la souris sur le code marqué pour connaître les violations des règles
- en utilisant alt+enter pour appliquer un QuickFix au problème
Repérez les bugs
Le Repérez les bugs Le plugin IntelliJ utilise l'analyse statique pour essayer de vous avertir des bogues dans votre code.
SpotBugs peut être configuré à partir des préférences d'IntelliJ pour scanner votre code. Les règles réelles utilisées se trouvent dans l'onglet Détecteur.
J'ai tendance à utiliser SpotBugs après avoir écrit et revu mon code, puis j'exécute la commande « Analyser les fichiers de projet, y compris les sources de test ».
Cela m'aide à identifier les bogues, le code mort et les optimisations évidentes. Cela m'oblige également à faire des recherches sur certaines des violations signalées pour m'aider à décider quoi faire.
SpotBugs détectera les problèmes mais ne propose aucune action QuickFix pour tenter de les résoudre.
SpotBugs est facile à configurer et je trouve que c'est un deuxième avis objectif utile à consulter dans mon IDE.
ソナー・リント
Le Sonar Lint plug-in.
SonarLint peut être configuré à partir des préférences IntelliJ pour sélectionner les règles selon lesquelles le code est validé.
Par défaut, SonarLint s'exécute en temps réel et affiche les problèmes liés au code actuel que vous modifiez.
SonarLint ne propose pas de solutions rapides, mais la documentation associée aux rapports de violation est généralement claire et bien documentée.
J'ai trouvé SonarLint utile par le passé pour m'avertir des nouvelles fonctionnalités de Java dont j'avais connaissance dans les nouvelles versions de Java.
Vérifiez le style
Le Vérifiez le style Le plugin propose un mélange de règles de formatage et de qualité du code.
Le plugin CheckStyle est fourni avec « Sun Checks » et « Google Checks ».
Les définitions de celles-ci peuvent être facilement trouvé en ligne.
CheckStyle ajoute le plus de valeur lorsqu'un projet a passé du temps à créer son propre ensemble de règles. Ensuite, le plugin IDE peut être configuré pour utiliser cet ensemble de règles et les programmeurs peuvent effectuer un scan avant de valider le code dans CI.
CheckStyle est très souvent utilisé comme plugin d'échec de construction pour les processus CI lorsque le nombre de violations de CheckStyle dépasse un seuil.
先生
Senseï utilise une analyse statique basée sur un arbre de syntaxe abstrait (AST) pour faire correspondre le code et créer des QuickFix, ce qui permet une identification très spécifique du code présentant des problèmes.
L'AST permet aux QuickFIX associés à une recette de comprendre le code environnant. Par exemple, lors de l'ajout d'une nouvelle classe dans le code, toute importation pour cette classe ne sera ajoutée au fichier source qu'une seule fois, et non pour chaque remplacement.
Sensei a été créé pour faciliter la création de règles de correspondance personnalisées qui peuvent ne pas exister, ou qui seraient difficiles à configurer, dans d'autres outils.
Plutôt que de modifier un fichier de configuration, toutes les configurations peuvent être effectuées dans l'interface graphique. Lors de la création de nouvelles recettes, l'interface graphique permet de voir facilement à quel code correspond la recette. Et lors de la définition des QuickFix, l'état avant et après du code peut être comparé immédiatement. Cela permet de créer plus facilement des recettes très contextuelles, c'est-à-dire propres aux équipes, à la technologie et même aux programmeurs individuels.
J'utilise Sensei en combinaison avec d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne les résoudront pas. Un cas d'utilisation courant pour Sensei consiste à reproduire la recherche correspondante de l'autre outil dans Sensei et à l'étendre à l'aide d'une solution rapide. Cela présente l'avantage que le correctif personnalisé appliqué répond déjà aux normes de codage de votre projet.
Je me retrouve régulièrement à créer des recettes Sensei qui existent déjà dans le set IntelliJ Intensions parce que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé ou parce que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.
Je complète les outils existants, plutôt que d'essayer de les remplacer complètement.
Sensei peut également être très utile lorsque vous identifiez une variante contextuelle d'une règle commune. Par exemple, si vous utilisez une bibliothèque SQL non prise en charge par l'outil d'analyse statique, mais que les règles SQL courantes du moteur d'analyse statique s'appliquent toujours, vous pouvez créer des variantes spécifiques à la bibliothèque de ces règles à l'aide de Sensei.
Sensei ne propose pas de nombreuses recettes génériques, comme les outils d'analyse statique mentionnés, mais sa force réside dans le fait qu'il facilite la création de nouvelles recettes, avec des QuickFix configurés pour correspondre à votre style de codage et à vos cas d'utilisation spécifiques.
REMARQUE : nous travaillons sur un référentiel public de recettes pour couvrir les cas d'utilisation génériques, et vous pouvez le trouver ici.
Résumé
J'ai tendance à choisir des outils qui fonctionnent ensemble, qui sont configurables et faciles à développer pour répondre à mon contexte spécifique. J'utilise les outils d'analyse statique de l'EDI depuis des années pour m'aider à identifier les problèmes et à en savoir plus sur les langages de programmation et les bibliothèques que j'utilise.
J'utilise tous les outils mentionnés en combinaison :
- IntelliJ Intentions permet de signaler les problèmes de code courants dès le départ, souvent avec des correctifs rapides associés.
- SpotBugs détecte des bogues simples que j'ai peut-être oubliés et m'alerte en cas de problèmes de performances.
- SonarLint identifie les fonctionnalités de Java que je ne connaissais pas et m'invite à d'autres méthodes pour modéliser mon code.
- CheckStyle m'aide à me conformer à un style de codage convenu qui est également appliqué pendant le CI.
- Sensei m'aide à créer des QuickFix pour compléter les scénarios courants trouvés par les outils d'analyse statique et créer des recettes de projets ou de technologies spécifiques qui peuvent être difficiles à configurer dans un autre outil.
---
Installez Sensei depuis IntelliJ en utilisant « Préférences \ Plugins » (Mac) ou « Paramètres \ Plugins » (Windows), puis recherchez simplement « code sécurisé Sensei ».
Vous pouvez trouver un référentiel d'exemples de code et de recettes pour les cas d'utilisation courants sur le compte GitHub de Secure Code Warrior, dans le cadre du projet `sensei-blog-examples`.
https://github.com/securecodewarrior/sensei-blog-examples
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
レポートを表示するデモを予約する
アラン・リチャードソンは、20年以上にわたり、開発者として、またテスターからテスト責任者まで、あらゆるレベルのテストに携わってきたプロフェッショナルなIT経験を持っています。アラン・リチャードソンは、Secure Code Warrior のデベロッパーリレーションズの責任者として、チームと直接連携し、高品質で安全なコードの開発を促進しています。また、「Dear Evil Tester」や「Java For Testers」など4冊の著書があります。また、テクニカルWebテストやSelenium WebDriver with Javaを学ぶためのオンライントレーニングcourses を作成しています。アランは、SeleniumSimplified.com、EvilTester.com、JavaForTesters.com、CompendiumDev.co.ukに執筆やトレーニングビデオを掲載している。
Qu'est-ce que l'analyse statique ?
L'analyse statique est l'analyse automatique du code source sans exécuter l'application.
Lorsque l'analyse est effectuée pendant l'exécution du programme, elle est connue sous le nom d'analyse dynamique.
L'analyse statique est souvent utilisée pour détecter :
- Vulnérabilités de sécurité.
- Problèmes de performance.
- Non-respect des normes.
- Utilisation de structures de programmation obsolètes.
Comment fonctionne un outil d'analyse statique ?
Le concept de base commun à tous les outils d'analyse statique est la recherche dans le code source pour identifier des modèles de codage spécifiques associés à une sorte d'avertissement ou d'informations.
Cela pourrait être aussi simple que « les classes de test de JUnit 5 n'ont pas besoin d'être « publiques » ». Ou quelque chose de complexe à identifier, comme « une entrée de chaîne non fiable utilisée dans une instruction d'exécution SQL ».
La manière dont les outils d'analyse statique implémentent cette fonctionnalité varie.
- technologie d'analyse du code source pour créer un arbre syntaxique abstrait (AST),
- correspondance de texte avec des expressions régulières,
- une combinaison de ce qui précède.
La correspondance d'expressions régulières sur du texte est très flexible, il est facile d'écrire des règles de correspondance, mais elle peut souvent entraîner de nombreux faux positifs et les règles de correspondance ignorent le contexte de code environnant.
La correspondance AST traite le code source comme du code de programme, et pas seulement comme des fichiers remplis de texte. Cela permet une correspondance contextuelle plus spécifique et peut réduire le nombre de faux positifs signalés par rapport au code.
Analyse statique dans le cadre de l'intégration continue
L'analyse statique est souvent effectuée au cours du processus d'intégration continue (CI) pour générer un rapport sur les problèmes de conformité qui peut être examiné pour obtenir une vue objective de la base de code au fil du temps.
Certaines personnes utilisent l'analyse statique comme mesure objective de la qualité de leur code en configurant l'outil d'analyse statique pour ne mesurer que des parties spécifiques du code et ne générer des rapports que sur un sous-ensemble de règles.
L'objectivité est assurée par les règles utilisées car celles-ci ne varient pas dans leur évaluation du code au fil du temps. Il est clair que la combinaison des règles utilisées et de leur configuration est une décision subjective et différentes équipes choisissent d'utiliser des règles différentes à des moments différents.
L'exécution de l'analyse statique dans CI est utile mais peut retarder le retour d'information au programmeur. Les programmeurs ne reçoivent pas de feedback lorsqu'ils codent, ils le reçoivent plus tard lorsque le code est exécuté via l'outil d'analyse statique. Un autre effet secondaire de l'exécution de l'analyse statique dans CI est que les résultats sont plus faciles à ignorer.
Pour aider les équipes à accorder plus d'attention aux résultats de l'analyse statique, il est généralement possible de configurer une métrique de seuil dans le processus de génération pour qu'elle échoue si la métrique est dépassée, par exemple si un certain nombre de règles sont déclenchées.
Analyse statique dans l'EDI
Pour recevoir des commentaires plus rapidement, de nombreux plugins de l'EDI exécutent les règles d'analyse statique dans l'EDI à la demande ou périodiquement à mesure que le code change.
Les violations de règles peuvent alors être détectées dans l'EDI pendant que le programmeur écrit du code, et pour rendre les règles plus difficiles à ignorer, les violations peuvent souvent être configurées pour être affichées sous forme de code souligné dans l'éditeur.
Personnellement, je trouve que c'est un moyen utile d'améliorer mon codage, en particulier lorsque je travaille avec une nouvelle bibliothèque couverte par l'outil d'analyse statique. Bien que cela puisse être « bruyant » avec des faux positifs ou des règles qui ne vous intéressent pas. Mais ce problème est résolu en prenant la mesure supplémentaire de configurer l'outil d'analyse statique pour ignorer certaines règles.
Corriger le code en fonction de règles d'analyse statique
Avec la plupart des outils d'analyse statique, la correction de la règle est laissée au programmeur. Il doit donc comprendre la cause de la violation de la règle et comment la corriger.
Très peu d'outils d'analyse statique permettent également de corriger les violations, car la correction dépend souvent du contexte de l'équipe, de la technologie utilisée et des styles de codage convenus.
Règles par défaut
Une fausse confiance dans la qualité des règles peut survenir lorsque les outils d'analyse statique sont fournis avec des règles par défaut. Il est tentant de croire qu'elles couvrent tous les problèmes qu'un programmeur peut rencontrer et toutes les circonstances dans lesquelles ces règles devraient s'appliquer. Parfois, les circonstances dans lesquelles une règle doit s'appliquer peuvent être subtiles et difficiles à détecter.
L'espoir est qu'en utilisant un outil d'analyse statique et en étudiant plus en détail les règles et les violations, les programmeurs développeront les compétences nécessaires pour détecter et éviter le problème dans le contexte de leur domaine spécifique.
Lorsque le domaine nécessite des règles contextuelles, les outils d'analyse statique peuvent ne pas avoir de règles correspondant à votre domaine ou à votre bibliothèque. De plus, les outils peuvent souvent être difficiles à configurer et à développer.
Désagréments
Aucun de ces « désagréments » n'est insurmontable :
- faux positifs
- absence de correctifs
- configuration pour ignorer les règles
- ajout de règles spécifiques au contexte
Mais ils sont souvent utilisés comme excuses pour éviter d'utiliser les outils d'analyse statique en premier lieu, ce qui est dommage car l'utilisation de l'analyse statique peut être extrêmement utile pour :
- mettre en évidence de meilleures approches pour les développeurs juniors
- obtenir des commentaires rapides sur les violations de codage claires
- identifier les problèmes obscurs que le programmeur n'a jamais rencontrés auparavant
- confirmer que le programmeur a adopté une bonne approche de codage (lorsqu'aucune violation n'est signalée)
Outils d'analyse statique basés sur l'IDE
En tant que contributeur individuel à un projet, j'aime utiliser les outils d'analyse statique qui s'exécutent depuis l'EDI afin de recevoir rapidement des commentaires sur mon code.
Cela complète tout processus de révision des pull requests et l'intégration CI qu'un projet peut avoir.
J'essaie d'identifier les outils qui me donneront un avantage et amélioreront mon flux de travail individuel.
Lorsque les outils s'exécutent dans l'EDI, parce qu'ils ont tendance à partager la même interface graphique de base et la même approche de configuration, il peut être tentant de les visualiser de manière interchangeable.
Les outils peuvent avoir des fonctionnalités ou des ensembles de règles qui se chevauchent, mais pour en tirer le meilleur parti, j'installe plusieurs outils pour tirer parti de leurs points forts.
Les outils IDE d'analyse statique que j'utilise activement lors du codage sont répertoriés ci-dessous :
- les inspections IntelliJ intégrées - modèles de codage courants
- SpotBugs - erreurs courantes
- SonarLint - modèles d'utilisation courants
- CheckStyle - modèles de style courants
- Sensei de Secure Code Warrior - création de règles personnalisées
Je les utilise tous parce qu'ils fonctionnent bien ensemble pour se compléter et se compléter mutuellement.
Inspections IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà ses inspections.
Il s'agit de règles d'analyse statique qui sont signalées dans l'EDI. Certains d'entre eux disposent également d'options QuickFix pour réécrire le code afin de résoudre le problème.
Les règles sont configurables de manière activée et désactivée, et vous pouvez choisir le niveau d'erreur utilisé pour le mettre en évidence dans l'EDI.
Il existe de nombreuses inspections IntelliJ de qualité. Je le sais parce que je les ai lus en écrivant ceci. J'utilise les inspections IntelliJ par défaut et je ne les ai pas configurées, mais pour tirer pleinement parti des inspections, vous devez les lire, identifier celles qui correspondent à votre style de codage et configurer le niveau d'avertissement de manière à ce que vous les remarquiez dans le code.
L'avantage des inspections IntelliJ est qu'elles sont fournies gratuitement avec l'IDE et qu'elles aident à développer la mémoire musculaire de :
- en remarquant les avertissements et les erreurs dans la source lorsque vous écrivez du code
- passez la souris sur le code marqué pour connaître les violations des règles
- en utilisant alt+enter pour appliquer un QuickFix au problème
Repérez les bugs
Le Repérez les bugs Le plugin IntelliJ utilise l'analyse statique pour essayer de vous avertir des bogues dans votre code.
SpotBugs peut être configuré à partir des préférences d'IntelliJ pour scanner votre code. Les règles réelles utilisées se trouvent dans l'onglet Détecteur.
J'ai tendance à utiliser SpotBugs après avoir écrit et revu mon code, puis j'exécute la commande « Analyser les fichiers de projet, y compris les sources de test ».
Cela m'aide à identifier les bogues, le code mort et les optimisations évidentes. Cela m'oblige également à faire des recherches sur certaines des violations signalées pour m'aider à décider quoi faire.
SpotBugs détectera les problèmes mais ne propose aucune action QuickFix pour tenter de les résoudre.
SpotBugs est facile à configurer et je trouve que c'est un deuxième avis objectif utile à consulter dans mon IDE.
ソナー・リント
Le Sonar Lint plug-in.
SonarLint peut être configuré à partir des préférences IntelliJ pour sélectionner les règles selon lesquelles le code est validé.
Par défaut, SonarLint s'exécute en temps réel et affiche les problèmes liés au code actuel que vous modifiez.
SonarLint ne propose pas de solutions rapides, mais la documentation associée aux rapports de violation est généralement claire et bien documentée.
J'ai trouvé SonarLint utile par le passé pour m'avertir des nouvelles fonctionnalités de Java dont j'avais connaissance dans les nouvelles versions de Java.
Vérifiez le style
Le Vérifiez le style Le plugin propose un mélange de règles de formatage et de qualité du code.
Le plugin CheckStyle est fourni avec « Sun Checks » et « Google Checks ».
Les définitions de celles-ci peuvent être facilement trouvé en ligne.
CheckStyle ajoute le plus de valeur lorsqu'un projet a passé du temps à créer son propre ensemble de règles. Ensuite, le plugin IDE peut être configuré pour utiliser cet ensemble de règles et les programmeurs peuvent effectuer un scan avant de valider le code dans CI.
CheckStyle est très souvent utilisé comme plugin d'échec de construction pour les processus CI lorsque le nombre de violations de CheckStyle dépasse un seuil.
先生
Senseï utilise une analyse statique basée sur un arbre de syntaxe abstrait (AST) pour faire correspondre le code et créer des QuickFix, ce qui permet une identification très spécifique du code présentant des problèmes.
L'AST permet aux QuickFIX associés à une recette de comprendre le code environnant. Par exemple, lors de l'ajout d'une nouvelle classe dans le code, toute importation pour cette classe ne sera ajoutée au fichier source qu'une seule fois, et non pour chaque remplacement.
Sensei a été créé pour faciliter la création de règles de correspondance personnalisées qui peuvent ne pas exister, ou qui seraient difficiles à configurer, dans d'autres outils.
Plutôt que de modifier un fichier de configuration, toutes les configurations peuvent être effectuées dans l'interface graphique. Lors de la création de nouvelles recettes, l'interface graphique permet de voir facilement à quel code correspond la recette. Et lors de la définition des QuickFix, l'état avant et après du code peut être comparé immédiatement. Cela permet de créer plus facilement des recettes très contextuelles, c'est-à-dire propres aux équipes, à la technologie et même aux programmeurs individuels.
J'utilise Sensei en combinaison avec d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne les résoudront pas. Un cas d'utilisation courant pour Sensei consiste à reproduire la recherche correspondante de l'autre outil dans Sensei et à l'étendre à l'aide d'une solution rapide. Cela présente l'avantage que le correctif personnalisé appliqué répond déjà aux normes de codage de votre projet.
Je me retrouve régulièrement à créer des recettes Sensei qui existent déjà dans le set IntelliJ Intensions parce que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé ou parce que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.
Je complète les outils existants, plutôt que d'essayer de les remplacer complètement.
Sensei peut également être très utile lorsque vous identifiez une variante contextuelle d'une règle commune. Par exemple, si vous utilisez une bibliothèque SQL non prise en charge par l'outil d'analyse statique, mais que les règles SQL courantes du moteur d'analyse statique s'appliquent toujours, vous pouvez créer des variantes spécifiques à la bibliothèque de ces règles à l'aide de Sensei.
Sensei ne propose pas de nombreuses recettes génériques, comme les outils d'analyse statique mentionnés, mais sa force réside dans le fait qu'il facilite la création de nouvelles recettes, avec des QuickFix configurés pour correspondre à votre style de codage et à vos cas d'utilisation spécifiques.
REMARQUE : nous travaillons sur un référentiel public de recettes pour couvrir les cas d'utilisation génériques, et vous pouvez le trouver ici.
Résumé
J'ai tendance à choisir des outils qui fonctionnent ensemble, qui sont configurables et faciles à développer pour répondre à mon contexte spécifique. J'utilise les outils d'analyse statique de l'EDI depuis des années pour m'aider à identifier les problèmes et à en savoir plus sur les langages de programmation et les bibliothèques que j'utilise.
J'utilise tous les outils mentionnés en combinaison :
- IntelliJ Intentions permet de signaler les problèmes de code courants dès le départ, souvent avec des correctifs rapides associés.
- SpotBugs détecte des bogues simples que j'ai peut-être oubliés et m'alerte en cas de problèmes de performances.
- SonarLint identifie les fonctionnalités de Java que je ne connaissais pas et m'invite à d'autres méthodes pour modéliser mon code.
- CheckStyle m'aide à me conformer à un style de codage convenu qui est également appliqué pendant le CI.
- Sensei m'aide à créer des QuickFix pour compléter les scénarios courants trouvés par les outils d'analyse statique et créer des recettes de projets ou de technologies spécifiques qui peuvent être difficiles à configurer dans un autre outil.
---
Installez Sensei depuis IntelliJ en utilisant « Préférences \ Plugins » (Mac) ou « Paramètres \ Plugins » (Windows), puis recherchez simplement « code sécurisé Sensei ».
Vous pouvez trouver un référentiel d'exemples de code et de recettes pour les cas d'utilisation courants sur le compte GitHub de Secure Code Warrior, dans le cadre du projet `sensei-blog-examples`.
https://github.com/securecodewarrior/sensei-blog-examples
目次
アラン・リチャードソンは、20年以上にわたり、開発者として、またテスターからテスト責任者まで、あらゆるレベルのテストに携わってきたプロフェッショナルなIT経験を持っています。アラン・リチャードソンは、Secure Code Warrior のデベロッパーリレーションズの責任者として、チームと直接連携し、高品質で安全なコードの開発を促進しています。また、「Dear Evil Tester」や「Java For Testers」など4冊の著書があります。また、テクニカルWebテストやSelenium WebDriver with Javaを学ぶためのオンライントレーニングcourses を作成しています。アランは、SeleniumSimplified.com、EvilTester.com、JavaForTesters.com、CompendiumDev.co.ukに執筆やトレーニングビデオを掲載している。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約するダウンロード
%20(1).avif)
.avif)
