{"id":32848,"date":"2019-10-31T21:49:16","date_gmt":"2019-10-31T18:49:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi\/"},"modified":"2019-10-31T21:49:16","modified_gmt":"2019-10-31T18:49:16","slug":"vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi","title":{"rendered":"Int\u00e9grez l'analyse statique dans le processus au lieu de l'utiliser pour chercher des bugs.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

L'\u00e9criture de cet article a \u00e9t\u00e9 motiv\u00e9e par la grande quantit\u00e9 de contenus sur l'analyse statique, qui attirent de plus en plus mon attention. Tout d'abord, c'est le blog PVS-studio<\/a><\/noindex>, qui se promeut activement sur Habr gr\u00e2ce \u00e0 des revues des erreurs d\u00e9tect\u00e9es par son outil dans des projets open source. R\u00e9cemment, PVS-studio a introduit le support de Java<\/a><\/noindex>, et bien s\u00fbr, les d\u00e9veloppeurs d'IntelliJ IDEA, dont l'analyseur int\u00e9gr\u00e9 est sans doute le plus avanc\u00e9 pour Java aujourd'hui, ne pouvaient pas rester indiff\u00e9rents<\/a><\/noindex>. <\/p>\n

En lisant de telles revues, on a l'impression qu'il s'agit d'une potion magique : appuyez sur un bouton, et voil\u00e0 \u2014 la liste des d\u00e9fauts devant vos yeux. On aurait l'impression qu'\u00e0 mesure que les analyseurs s'am\u00e9liorent, de plus en plus de bugs seront automatiquement trouv\u00e9s et que les produits scann\u00e9s par ces robots deviendront de mieux en mieux, sans aucun effort de notre part.<\/p>\n

Mais il n'existe pas de potions magiques. Je voudrais parler de ce dont on ne parle g\u00e9n\u00e9ralement pas dans les articles du type \u00ab voici ce que notre robot peut trouver \u00bb : ce que les analyseurs ne peuvent pas faire, quel est leur v\u00e9ritable r\u00f4le et place dans le processus de livraison logicielle, et comment les int\u00e9grer correctement.<\/p>\n

\"Int\u00e9grez
\nCloche \u00e0 rats (source : wikip\u00e9dia<\/a><\/noindex>).<\/i>
\n<\/a><\/noindex><\/p>\n

Ce que les analyseurs statiques ne pourront jamais accomplir<\/h2>\n

\nQu'est-ce que, du point de vue pratique, l'analyse de code source ? Nous soumettons certains codes sources, et en sortie, en peu de temps (beaucoup plus court que les tests) nous obtenons des informations sur notre syst\u00e8me. La limitation fondamentale et math\u00e9matiquement insurmontable est que nous ne pouvons obtenir qu'une classe d'informations plut\u00f4t \u00e9troite de cette mani\u00e8re.<\/p>\n

Le cas le plus c\u00e9l\u00e8bre d'une t\u00e2che non r\u00e9soluble par l'analyse statique est le probl\u00e8me d'arr\u00eat<\/a><\/noindex>: c'est un th\u00e9or\u00e8me qui prouve qu'il est impossible de d\u00e9velopper un algorithme g\u00e9n\u00e9ral qui, \u00e0 partir du code source d'un programme, d\u00e9terminerait s'il va entrer dans une boucle ou se terminer en un temps fini. Une extension de ce th\u00e9or\u00e8me est le th\u00e9or\u00e8me de Rice<\/a><\/noindex>, affirmant que pour toute propri\u00e9t\u00e9 non triviale des fonctions calculables, la question de savoir si un programme arbitraire calcule une fonction avec cette propri\u00e9t\u00e9 est une t\u00e2che algorithmiquement ind\u00e9cidable. Par exemple, il est impossible d'\u00e9crire un analyseur qui d\u00e9termine, pour tout code source, si le programme analys\u00e9 est une impl\u00e9mentation d'un algorithme calculant, disons, le carr\u00e9 d'un entier.<\/p>\n

Ainsi, la fonctionnalit\u00e9 des analyseurs statiques a des limitations insurmontables. Un analyseur statique ne pourra jamais, dans tous les cas, d\u00e9terminer des \u00e9l\u00e9ments comme, par exemple, l'occurrence d'une \u00ab null pointer exception \u00bb dans des langages permettant une valeur nulle, ou dans tous les cas, d\u00e9terminer la survenue d'un \u00ab attribute not found \u00bb dans des langages \u00e0 typage dynamique. Tout ce qu'un analyseur statique le plus performant peut faire, c'est mettre en \u00e9vidence des cas particuliers, dont le nombre parmi tous les probl\u00e8mes potentiels avec votre code source est, sans exag\u00e9ration, une goutte dans l'oc\u00e9an.<\/p>\n

L'analyse statique n'est pas une recherche de bogues<\/h2>\n

\nDe ce qui pr\u00e9c\u00e8de, on peut conclure que l'analyse statique n'est pas un moyen de r\u00e9duire le nombre de d\u00e9fauts dans un programme. Je me risque \u00e0 affirmer que, lorsqu'elle est appliqu\u00e9e pour la premi\u00e8re fois \u00e0 votre projet, elle trouvera des \u00ab endroits int\u00e9ressants \u00bb dans le code, mais ne trouvera probablement aucun d\u00e9faut affectant la qualit\u00e9 de votre programme.<\/p>\n

Les exemples de d\u00e9fauts automatiquement trouv\u00e9s par les analyseurs sont impressionnants, mais il ne faut pas oublier que ces exemples ont \u00e9t\u00e9 trouv\u00e9s gr\u00e2ce \u00e0 l'analyse d'un grand ensemble de grandes bases de code. Sur le m\u00eame principe, les hackers capables de tester plusieurs mots de passe simples sur un grand nombre de comptes finissent par trouver ceux pour lesquels le mot de passe est simple.<\/p>\n

Cela signifie-t-il qu'il ne faut pas appliquer l'analyse statique ? Bien s\u00fbr que non ! Et pour la m\u00eame raison pour laquelle il est utile de v\u00e9rifier chaque nouveau mot de passe contre la liste noire des \u00ab mots de passe simples \u00bb.<\/p>\n

L'analyse statique est plus qu'une recherche de bogues<\/h2>\n

\nEn r\u00e9alit\u00e9, les t\u00e2ches pratiquement r\u00e9solues par l'analyse sont beaucoup plus larges. En effet, l'analyse statique est toute v\u00e9rification des sources effectu\u00e9e avant leur ex\u00e9cution. Voici quelques-unes des choses que l'on peut faire :<\/p>\n