Indications pour le contrôle de qualité du code
Mise à jour : novembre 2007
La liste suivante fournit plusieurs indications pour le contrôle de qualité du code.
Obligatoire
Insistez sur le contrôle de qualité.
N'acceptez pas une qualité de bas niveau pendant le contrôle du code, car cela engendre ultérieurement des problèmes dans le cycle du produit. Sachez que généralement les équipes ne résolvent pas les problèmes qui sont trop complexes, trop obscurs ou qui sont détectés trop tard dans le cycle du produit.
Utilisez des listes de contrôle.
Suivez les types d'erreurs qui vous faites en général et utilisez-les comme liste de vérification pour le futur code. Vous pouvez démarrer votre liste de vérification avec les erreurs courantes de votre groupe ou division, puis la personnaliser pour votre propre utilisation.
Effectuez des révisions de code.
Les révisions de code vous donnent la possibilité d'expliquer et de mieux comprendre votre propre code, et permettent aux autres de consulter votre code.
Écrivez des tests unitaires.
Le meilleur moyen de garantir la qualité est d'écrire des tests qui valident les données et les algorithmes, en vérifiant que les erreurs antérieures ne se reproduisent pas. Il existe quatre sortes de tests unitaires :
Les tests unitaires positifs appliquent le code comme prévu et vérifient le résultat correct.
Les tests unitaires négatifs emploient le code de manière erronée et intentionnelle, en vérifiant sa robustesse et la gestion des erreurs.
Les tests de contrainte poussent le code au maximum, en essayant de faire apparaître les erreurs subtiles de ressource, de délai ou réentrantes.
Les tests d'injection d'erreurs font apparaître les anomalies de gestion des erreurs.
Pour plus d'informations, consultez Comment : créer un test unitaire.
Utilisez des outils d'analyse du code.
La manière la plus simple de détecter précocement les bogues consiste à augmenter le niveau d'avertissement dans le compilateur et à utiliser des outils d'analyse du code. Les points critiques consistent à ne jamais ignorer un avertissement et à réparer le code.
Pour plus d'informations, consultez Détection et correction des erreurs de code C/C++ et Détection et correction des erreurs du code managé.
N'utilisez pas un langage inapproprié dans votre code source.
Vous ne devez pas utiliser un langage et des références inappropriés dans votre code source. Beaucoup de clients dans le monde sont très sensibles à certaines phases ou noms, en particulier les références à des entités politiques dont la situation peut être mentionnée. Recherchez dans votre code source les références et le langage politiquement sensibles, et signalez toutes les erreurs correspondantes.
Créez des éléments de travail.
N'oubliez pas le travail non terminé ; pensez à créer des éléments de travail pour les commentaires TODO, REVIEW, BUG et UNDONE. Pour plus d'informations, consultez Comment : ajouter de nouveaux éléments de travail.
Évitez
Les fonctions sans spécification.
N'écrivez pas du code sans spécification. Commencez par écrire une spécification et faites-la réviser. Sans spécification, il est impossible pour votre équipe de test de savoir ce qui fonctionne et ce qui ne fonctionne pas. Si vous écrivez du code sans spécification, vous risquez de mal vous comprendre entre vous, de mal comprendre ce que votre client souhaite et de livrer un produit de mauvaise qualité. Pour plus d'informations, consultez Projets d'équipe Team Foundation.
D'atteindre le milieu de la première phase de développement sans avoir mis en place l'installation du produit.
Les membres de l'équipe de test doivent avoir un moyen d'installer le produit sur leurs ordinateurs, même s'il s'agit seulement d'une installation de prototype. Pour plus d'informations, consultez Vue d'ensemble de Team Foundation Build.
Recommandé
Utilisez un style de codage cohérent.
Lorsque toute votre équipe code dans le même style, votre produit gagne en lisibilité, en cohérence, en facilité de maintenance et en qualité globale. Les détails des indications eux-mêmes ne sont pas si importants. Ce qui est important c'est de donner des indications et de s'assurer que l'équipe les suit fidèlement. Les principaux avantages du choix d'un style quel qu'il soit sont la cohérence et la facilité à reconnaître les modèles de codage. Par conséquent, choisissez un style et utilisez-le.
Écrivez des tests unitaires avant d'écrire le code.
Le développement basé d'abord sur les tests est une méthodologie clé du développement souple et de la programmation extrême. En commençant par l'écriture des tests, vous remplissez plusieurs critères de qualité :
Vous garantissez que des tests unitaires sont écrits.
Vous garantissez que votre code peut être testé facilement, ce qui se traduit généralement par une meilleure cohésion du code et un couplage plus faible entre les modules.
Souvent, vous découvrez la conception appropriée pour votre travail en déterminant d'abord comment la conception doit être testée.
Pour plus d'informations, consultez Comment : créer un test unitaire.
Concevez un code qui pourra être porté sur d'autres plateformes.
La conception et le codage pour la portabilité rendent votre code plus fiable, même si vous ne projetez pas vraiment de le porter sur une autre plateforme. Lorsque vous rendez le code portable, vous :
Établissez de meilleures hypothèses.
Faites preuve d'une plus grande clarté dans les types de données et vos objectifs de conception.
Garantissez que votre code est plus à même de prendre en charge de futures nouvelles plateformes.
Refactorisez le code existant dans des fonctions plus petites.
La refactorisation peut renouveler un code ancien. Les tentatives de réparation de gros systèmes anciens peuvent être difficiles, parce qu'ils peuvent être tellement complexes dans leurs interactions que vous hésitez à modifier ne serait-ce qu'un commentaire.
Pour réussir la refactorisation, vous devez d'abord incorporer des tests unitaires forts pour garantir que la refactorisation n'introduit pas de nouvelles erreurs. Ensuite, séparez les grandes fonctions en collections de fonctions plus petites sans rien modifier dans les fonctionnalités. Appliquez les recommandations suivantes :
Chaque fonction plus petite doit exécuter juste un type de tâche, telle que l'interface utilisateur, l'accès aux bases de données, les interactions COM avec une seule interface, etc.
Après avoir complètement refactorisé toutes les fonctions dans un sous-système, vous pouvez modifier individuellement les petites fonctions sans affecter le système entier. Vous pouvez ajouter, supprimer ou améliorer une fonction à la fois.
Pour plus d'informations, consultez Types et classes de refactorisation.
Révisez le code existant.
Les bogues se regroupent souvent dans des modules spécifiques. Lorsque votre nouveau code est propre mais que certains modules de votre ancien code hébergent des bogues, révisez juste ces modules. Si le nouveau code est trop entrelacé avec l'ancien code, la refactorisation peut souvent aider à résoudre les problèmes. Pour plus d'informations, consultez Détection et correction des erreurs de code C/C++ et Détection et correction des erreurs du code managé.
Parcourez tous les chemins de code dans un débogueur.
L'un des meilleurs moyens de vérifier le code consiste à le parcourir dans un débogueur. À chaque ligne, vérifiez que le comportement attendu se produit réellement. Parcourir tous les chemins de code dans un débogueur est comparable à un test unitaire ligne par ligne. La procédure est laborieuse, mais elle vérifie efficacement le comportement attendu.
Non recommandé
L'utilisation d'un document des besoins comme spécification.
N'essayez pas d'interpréter la spécification à partir d'un document des besoins. Votre interprétation peut être différente de celle du chef de projet ou du testeur. Si votre interprétation est différente, votre implémentation ne correspondra pas à ce que les autres attendent.