Les contrôles qualité ont pour principal intérêt de pouvoir remonter le plus rapidement possible des informations sur le produit en cours de développement afin de permettre à l’équipe de réagir tout aussi rapidement afin de minimiser les impacts. Un problème découvert trop tard peut avoir des conséquences en termes de budget, de délai ou d’image vis à vis des clients. Le coût peut en effet être multiplié par 5 si le défaut est détecté après la mise en production du produit.
Le but de l'inspection continue, initiée par la société SonarSource SA, est de répondre aux problématiques posées par les revues humaines. Ces revues :
- ne sont pas assez exhaustives
- sont subjectives
- interviennent trop tardivement
- n'impliquent pas assez les acteurs
L'inspection continue (donc outillée) permet :
- d'être exécutée régulièrement (lors d'un push sur le SCM par exemple)
- d'obtenir un feedback très rapide voire immédiat pendant que le code est encore chaud dans les esprits
- d'impliquer les développeurs dans un cercle vertueux d'apprentissage et d'amélioration continue
- d'impliquer les développeurs dans un effort commun
- d'offrir des tableaux de bord et de mesurer l'évolution au fil du temps
- d'obtenir des mesures sur la base de code complète ainsi que sur le nouveau code (différentiel)
- d'être objective car basée sur des règles et bonnes ou mauvaises pratiques connues
💡 L'inspection continue est donc à mettre en place dès le début d'un projet, ce qui est très facile avec des outils comme GitLab-CI.
Nombre d'outils sont disponibles (directement ou non) pour remonter rapidement aux développeurs des indicateurs sur la qualité du code produit :
- Les remontées d'informations directement dans l'IDE (soit nativement soit via des plugins type SonarLint ou FindBugs).
- Les contrôles de compilation et de succès des tests lors d'un push (via Jenkins, GitLab CI, ...).
- Les contrôles outillés quotidiens via SonarQube (qui ajoutent en plus un suivi temporel grâce aux Dashboards).
- Les analyses via des outils d'APM : l’Application Performance Monitoring suit les transactions de bout en bout permettant la remontée d'informations et de métriques de toutes sortes.
SonarQube (anciennement sonar et à ne pas confondre avec SonarJ) édité par la société SonarSource SA est le standard du marché dans le domaine de l'analyse de la qualité du code d'une application et supporte plus d'une vingtaine de langages. SonarQube définit 3 catégories de violations :
- Bugs : Bug avéré ou du code manifestement erroné ou très susceptible de générer un comportement inattendu.
- Vulnérabilités : provenant de code potentiellement vulnérable à l'exploitation par les pirates.
- Mauvaises pratiques (Code Smells) : provenant de code qui va dégrader la maintenabilité, la robustesse ou la performance. Elles sont mesurées et affichées principalement en termes de temps qu'elles prendront pour être corriger.
SonarQube définit également pour chaque anomalie relevée un niveau de criticité parmi 5, du plus au moins important :
- Bloquant (blocker) : anomalie à corriger immédiatement.
- Critique (critical) : anomalie à corriger rapidement.
- Majeur (major) : anomalie à étudier, une correction planifiée est souhaitable.
- Mineur (minor) : anomalie à prendre en compte si possible (souvent facile à corriger).
- Informatif (info) : anomalie à prendre en compte si possible (souvent facile à corriger).
Enfin l'outil peut même amender automatiquement les merge request (via un plugin), les violations étant visibles dès lors directement dans GitLab.
SonarLint du même éditeur est un plugin disponible pour différents IDE (Eclipse, IntelliJ IDEA, VS Code, ...) permettant d'avoir un retour immédiat (Fix issues before they exist) lors de l'écriture du code (donc avant le commit) sans devoir attendre de lancer une analyse SonarQube.
Quelques outils utilisables pour de l'inspection continue "au poste" (feedback immédiat) ou automatisée (feedback asynchrone) :
| Langage | Objectif | Feedback immédiat dans l'IDE | Feedback asynchrone via l'inspection continue |
|---|---|---|---|
| Java | Mesurer la qualité du code source | SonarLint (Eclipse, IntelliJ, VS Code) | SonarQube |
| Java | Déterminer la couverture de code par les tests | EclEmma (Eclipse), Run with Coverage (IntelliJ) | JaCoco, Cobertura |
| Java | Analyser les vulnérabilités dans les dépendances tierce partie | Snyk Vulnerabilities Scanning (IntelliJ) | Snyk CLI |
| Java | Analyser les vulnérabilités dans les dépendances tierce partie | OWASP Dependency Check | OWASP Dependency Track |
| Shell | Analyse statique de code script shell | ShellCheck (extension VS Code) | ShellCheck + SonarQube |
| JavaScript | Analyser les vulnérabilités dans les dépendances tierce partie | Snyk CLI | Snyk CLI |
| JavaScript | Analyse statique de code JavaScript | JSHint (+ extension VS Code) | SonarQube |
| TypeScript | Analyse statique de code TypeScript | TSLint (+ extension VS Code) | ? |
- 🇬🇧 SonarSource White Paper
- 🇬🇧 SonarQube
- 🇫🇷 Blog JetBrains : Gagnez du temps sur les révisions de code et la planification de projet avec l’analyse statique