Recommandations générales
Objet
|
Recommandations générales pour chaque revue.
|
Lorsque vous générez un logiciel de haute qualité, réviser l'implémentation complémente les autres mécanismes de
qualité que sont la compilation, l'intégration et le test. Avant de réviser l'implémentation, compilez-la et utilisez
des outils, des vérificateurs de règle de code par exemple, pour détecter le plus d'erreurs possible. Envisagez
d'utiliser des outils permettant la visualisation du code. Si le code est exécuté en utilisant des outils de détection
d'erreur d'exécution, vous pouvez détecter et supprimer des erreurs supplémentaires avant de réviser l'implémentation.
La révision de l'implémentation présente les avantages suivants :
-
Renforcer et stimuler un style de codage commun pour le projet. Réviser le code permet aux membres de suivre de
façon efficace les instructions de programmation. Pour ce faire, il est plus important de réviser les résultats
provenant de tous les auteurs et implémenteurs que l'ensemble des fichiers du code source.
-
Rechercher les erreurs que les tests automatisés n'ont pas détectées. Les revues d'implémentation détectent des
erreurs différentes de celles identifiées lors du test.
-
Permettre le partage de connaissances entre individus et les transférer des personnes les plus expérimentées à
celles qui le sont moins.
Plusieurs méthodes peuvent être utilisées pour réviser l'implémentation. Utilisez l'une des méthodes suivantes :
-
Inspection. Technique d'évaluation formelle dans laquelle l'implémentation est examinée en détail. Les
inspections sont considérées comme la technique de revue la plus productive. cependant cette méthode 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'erreurs éventuelles, de violation de normes de codage, 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 de petites modifications ainsi que comme contrôle d'exactitude.
Les compétences requises pour ce rôle sont similaire à celles du rôle : Implémenteur.
Les personnes remplissant ce rôle sont souvent considérée comme expertes dans le langage de programmation utilisé pour
le code révisé. Dans la plupart des projets, ce rôle est rempli par des programmeurs expérimentés de l'équipe
d'implémentation.
Voir aussi Technique : Revues.
|
Définir des points de contrôle pour l'implémentation
Objet
|
Etablir une liste de contrôle de revue de l'implémentation.
|
Cette section présente une liste de contrôle générale pour la revue de l'implémentation, à titre d'exemple, afin
d'indiquer les éléments à rechercher lors d'une revue. Les instructions de programmation doivent être votre source
d'information pour la qualité du code.
Généralités
-
Le code suit-il les instructions de programmation ?
-
Le code est-il autodocumentant ? Est-il possible de comprendre le code en le lisant ?
-
Toutes les erreurs détectées par les vérificateurs de règle de code et/ou les outils de détection d'erreurs
d'exécution ont-elles été traitées ?
Commentaires
-
Les commentaires sont-ils à jour ?
-
Les commentaires sont-ils clairs et corrects ?
-
Les commentaires sont-ils faciles à modifier si le code est modifié ?
-
Les commentaires sont-ils ciblés sur le pourquoi, et non pas sur le comment ?
-
Toutes les erreurs liées à des surprises, à des cas exceptionnels ou à des solutions palliatives sont-elles
commentées ?
-
Le but de chaque opération est-il commenté ?
-
Tous les autres éléments importants de chaque opération sont-ils commentés ?
Code source
-
Le nom de chaque opération décrit-il ce que l'action effectue ?
-
Les paramètres ont-ils des noms descriptifs ?
-
Le parcours normal de chaque opération est-il facile à distinguer des chemins spécifiques ?
-
L'opération n'est-elle pas trop longue et ne peut-elle pas être simplifiée en procédant à l'extraction
d'instructions associées dans des opérations distinctes ?
-
L'opération n'est-elle pas trop longue et ne peut-elle pas être simplifiée en réduisant le nombre de points de
décision ? Un point de décision est une instruction dans laquelle le code peut prendre plusieurs chemins. Par
exemple, les instructions if-, else-, and-, while- et case-.
-
L'imbrication de boucles est-elle réduite ?
-
Les variables sont-elles correctement nommées ?
-
Le code est-il simple et évite-t-il les solutions trop audacieuses ?
|
Préparation du compte-rendu de la revue et documentation des incidents
Objet
|
Documenter les résultats de la revue.
Vérifier que les incidents identifiés sont documentés.
|
A la suite de chaque réunion de revue, les résultats de la réunion doivent être documentés dans un compte-rendu de revue. De plus, les incidents doivent être documentés
dans une demande de changement (et quelqu'un doit éventuellement être affecté
comme propriétaire et responsable de sa résolution).
|
|