Qu'est-ce que l'inspection du Code ?
L'inspection du code consiste à revoir et à améliorer le code avant de le tester.
Les tests et l'inspection visent tous deux à améliorer le code, mais ils reposent sur deux concepts distincts :
- Le test est dynamique et exécute le logiciel pour vérifier ses fonctionnalités.
(Voir aussi : Tests automatisés avec AscentialTest) - L'inspection du code analyse le code source sur la base d'un ensemble de règles.
Inspection manuelle, automatisée ou continue ?
Différentes stratégies sont possibles pour l'inspection du code :
| Stratégie | Description | Avantages et inconvénients |
|---|---|---|
| Revue de code manuelle | Les membres de l'équipe passent en revue le code de chacun pour trouver et corriger les éventuels problèmes. | Better code Human costs > limited frequency |
| Programmation en binôme | 2 programmeurs à 1 poste : l'un écrit le code, l'autre le révise. | Un meilleur code et un meilleur transfert de connaissances. La productivité peut être problématique. |
| Inspection automatisée | Revue effectuée par une machine. | Aucune limitation de fréquence. Nécessite des outils d'analyse de code |
| Inspection continue du code | Revue automatique incluse dans un flux d'intégration continue. | Voir ci-dessous |
Pourquoi mettre en œuvre l'inspection continue du code ?
L'inspection continue du code est un élément essentiel du processus de développement DevOps et Agile, où la revue de code traditionnelle ne suffit pas.
L'inspection du code améliore la qualité et la sécurité globale du code, tout en réduisant les coûts de remédiation et de maintenance en identifiant précocement les éventuels défauts.
Chaque fois qu'un développeur intègre son travail dans le pipeline CI/CD, le code est automatiquement analysé à la recherche de défauts. Les objectifs courants de l'inspection continue sont les suivants :
- Détecter et éliminer les vulnérabilités de sécurité
- Respecter les normes de "grammaire" du code
- Respecter les normes de lisibilité du code
- Adhésion aux couches architecturales
- Supprimer les doublons de code
- Améliorer les performances
- Et plus encore...
Types de problèmes détectés
| Bug | Défaut ou erreur - autre que les erreurs de syntaxe - qui peut casser l'application à tout moment. La correction est hautement prioritaire. |
| Maintenabilité | Ce problème lié à la qualité n'est pas un bug. Il n'est pas techniquement incorrect et n'empêche pas l'application de fonctionner. Cependant, il augmente le coût des modifications et la probabilité d'introduire de nouveaux bugs. |
| Vulnérabilité | Un défaut ou une faiblesse du code qui peut entraîner une faille de sécurité. |
| Alerte de sécurité | Un morceau de code qui pourrait créer une faille de sécurité, mais qui doit être examiné manuellement pour le déterminer. |
| Métrique | Mesures objectives de certaines propriétés ou entités du code. Traditionnellement utilisée pour l'estimation des coûts, l'assurance qualité, le débogage, l'optimisation des performances et l'attribution des tâches. |
| Erreur de syntaxe | Erreur grammaticale dans la syntaxe d'une phrase qui peut empêcher le code de se compiler ou de s'exécuter. Sa correction est hautement prioritaire. |
Gravité du problème
Tous les problèmes ne sont pas critiques. Pour aider à hiérarchiser les améliorations, chaque problème est assorti d'un niveau de gravité :
| Critique | Bug qui va probablement altérer le bon fonctionnement de l'application et qui doit être corrigé le plus rapidement possible. |
| Majeure | Vulnérabilité de sécurité ou bogue qui pourrait éventuellement altérer le bon fonctionnement de l'application. À corriger le plus rapidement possible |
| Mineure | Défaut de qualité qui peut affecter significativement la productivité du développeur. |
| Faible | Défaut de qualité qui peut légèrement affecter la productivité du développeur. |
| Information | Métriques ou informations sur le code. |
Comment la sévérité d'un problème est-elle définie ?
La gravité d'un problème dépend de son impact et de sa probabilité.
Un impact élevé/faible est évalué selon les critères suivants :
- Pour les bugs : ce problème peut-il interrompre le fonctionnement de l'application ou corrompre les données stockées ?
- Pour les vulnérabilités : si cette brèche était exploitée, causerait-elle des dommages importants ?
- Pour les problèmes de maintenabilité : ce problème pourrait-il amener un développeur à introduire un bug ?
| Critique | Majeure | Mineure | Faible | |
|---|---|---|---|---|
| Impact | Elevé | Elevé | Faible | Faible |
| Probabilité | Elevé | Faible | Elevé | Faible |
Autres définititions
| Règle d'inspection | Une pratique de codage qui devrait être suivie, pour éviter de générer des bogues, des vulnérabilités ou des problèmes de qualité du code. |
|---|---|
| Coût de remédiation | Le temps estimé nécessaire pour corriger tous les bugs et les problèmes de sécurité. |
| Dette Technique | Temps estimé pour regler tous les problèmes de maintenabilité |