Activité : Revoir le code
Objet
- Vérifier l'implémentation.
|
Rôle :
Auditeur technique |
Fréquence : Au cours de chaque itération |
Etapes
|
Artefacts d'entrée :
|
Artefacts de sortie :
|
Guides d'utilisation de l'outil :
|
Détails sur l'enchaînement d'activités :
|
Objet |
Recommandations générales pour chaque revue. |
Lorsque vous élaborez des logiciels de haute qualité, la revue de l'implémentation vient compléter d'autres mécanismes de qualité tels que la compilation, l'intégration et le test. Avant de revoir l'implémentation, effectuez une compilation et utilisez des outils tels que des vérificateurs de règles de code pour détecter le plus grand nombre d'erreurs possible. Privilégiez l'utilisation d'outils qui permettent de visualiser le code. Vous pouvez également détecter et éliminer d'autres erreurs avant la revue d'implémentation, si le code est exécuté à l'aide d'outils de détection d'erreurs d'exécution.
Les avantages de la revue d'implémentation sont les suivants :
- Mise en place et encouragement d'un style commun de codage pour le projet. La revue du code est un moyen efficace de suivre les recommandations de programmation.
Pour cela, il est plus important de revoir les résultats de tous les auteurs et implémenteurs que de revoir tous les fichiers de code source.
- Détection d'erreurs que les tests automatisés ne permettent pas de détecter. Les revues d'implémentation permettent de détecter des erreurs différentes de celles détectées lors des tests.
- Partager les connaissances et les transférer des personnes les plus expérimentés aux moins expérimentées.
Plusieurs techniques peuvent être utilisées pour revoir l'implémentation. Utilisez l'une de celles décrites ci-dessous :
- Inspection. Technique d'évaluation formelle pour laquelle un ou plusieurs artefacts sont examinés en détail. L'inspection est considérée comme la technique de revue la plus productive, cependant elle nécessite une formation, et une préparation.
- Révision structurée. Technique d'évaluation dans laquelle l'auteur de l'implémentation guide un ou plusieurs réviseurs tout au long de l'implémentation. Les réviseurs posent des questions et font des commentaires au sujet de la technique, du style, d'omissions ou d'erreurs éventuelles, des changements par rapport à des standards établis, etc.
- Lecture de code. Une ou deux personnes lisent le code. Lorsque les réviseurs sont prêts, ils peuvent se rencontrer et présenter leurs commentaires et leurs questions. Cependant, la réunion n'est pas obligatoire, et les réviseurs peuvent s'ils préfèrent soumettre leurs commentaires et leurs questions à l'auteur par écrit. La lecture de code est recommandée pour vérifier les modifications mineures, et constitue un "contrôle de santé."
Pour ce rôle, les exigences de compétences sont les mêmes que pour le rôle d'implémenteur ; les personnes chargées de ce rôle sont souvent considérées comme des experts dans le langage de programmation utilisé pour le code revu. Dans la plupart des projets, ce rôle est confié à des programmeurs senior membres de l'équipe d'implémentation.
Voir aussi Principes et conseils : revues.
Objet |
Etablir des points de contrôle pour la revue de l'implémentation. |
Cette section indique certains points de contrôle généraux pour les revues d'implémentation, et des exemples de points à traiter lors d'une revue. Les recommandations de programmation doivent constituer la source principale d'informations pour la qualité du code.
Informations générales
- Le code respecte-t-il les recommandations de programmation ?
- Le code est-il documenté ? Est-il possible de comprendre le code en le lisant ?
- Le contrôle de règles de code a-t-il permis de détecter toutes les erreurs, et/ou des outils de détection d'erreurs d'exécution ont-ils été utilisés ?
Commentaires
- Les commentaires sont-ils à jour ?
- Les commentaires sont-ils clairs et corrects ?
- Les commentaires sont-ils faciles à modifier, en cas de modification du code ?
- Les commentaires expliquent-ils pourquoi, et non comment ?
- Toutes les surprises et erreurs liées aux solutions, tous les cas exceptionnels sont-ils commentés ?
- L'objectif de chaque opération est-il commenté ?
- D'autres faits significatifs sur chaque opération sont-ils commentés ?
Code source
- Chaque opération possède-t-elle un nom décrivant l'objet de l'opération ?
- Les paramètres portent-ils des noms descriptifs ?
- Le chemin d'accès à chaque opération est-il normal, clairement différent des autres chemins exceptionnels ?
- L'opération est-elle trop longue, et peut-elle être simplifiée via l'extraction des instructions associées en opérations privées ?
- L'opération est-elle trop longue, et peut-elle être simplifiée via la réduction du nombre de points de décision ?Un point de décision représente une instruction dans laquelle le code peut prendre différents chemins (par exemple les instructions if-, else-, and-, while- et case-.
- Le regroupement de boucles est-il minimisé ?
- Les variables sont-elles correctement nommées ?
- Le code est-il simple et évite-t-il les solutions "sophistiquées" ?
Objet |
Documenter les résultats de la revue.
Vérifier que les anomalies identifiées sont documentées.
|
A la suite de chaque réunion de revue, les résultats de la réunion doivent être documentés dans un enregistrement de revue. En outre, les demandes de changement doivent être enregistrées dans les demandes de modification, puis éventuellement affectées à une personne qui en deviendra propriétaire et sera chargée de la résolution.
| |
|