Revue par les pairs

Question 1

Qu’est-ce que les revues?

Answer 1

• Méthodes d’évaluation
  
  • Méthodes de tests
  • Méthodes de revues (aussi appelées révisions)
• La revue
  
  • Une façon de réviser votre travail.
  • Technique de contrôle plutôt que de test.
  • Objectif est de détecter et de réparer les erreurs le plus tôt possible dans le cycle de développement.
• Types de revue de code
  
  • Formelle ou informelle,
  • pré ou post commit
  • Walkthrough, inspection, Pair programming, etc.

Question 2

Finalité des revues et des tests
* Fiabilité du logiciel : taux de disponibilité pour les utilisateurs

Answer 2

• MTTR : Mean Time To Repair. Temps moyen mis pour réparer un système en panne
• MTTF : Mean Time To Failure. Temps moyen que met un système à tomber en panne. C’est une sorte d’unité de mesure de la fiabilité d’un système.
• MTBF : Mean Time Between Failures. Temps moyen écoulé entre deux pannes, y compris le temps de réparation : MTBF = MTTF + MTTR (La francisation en « Moyenne des Temps de Bon Fonctionnement » est donc fausse).
• MTBE : Mean Time Between Errors. Temps moyen entre deux erreurs
• Taux de disponibilité pour l’utilisateur : MTTF / MTBF

Question 3

Qu’est-ce que les revues?
Examen détaillé d’une spécification, d’une conception ou d’une
implémentation par une personne ou un groupe de personnes, afin de
déceler des fautes, des violations de normes de développement ou
d’autres problèmes.
IEEE 729
* Mécanisme pour:

Answer 3

• Valider le design et l’implémentation des changements
• Assurer une cohérence entre modules et développeurs au niveau du design et
  des pratiques de développement
• Partager, former et se former

Question 4

Avantages * Directs:

Answer 4

• Meilleure qualité du produit
• Moins de fautes dans le produit
• Meilleure communication dans l’équipe
• Formation des nouveaux arrivants et juniors * Retour sur investissemen

Question 5

Avantages* Indirects

Answer 5

• Cycle de développement/test plus court
• Moins d’impact sur le support technique
• Clients plus satisfaits
• Meilleure maintenabilité du code
• Meilleure architecture du code

Question 6

Revue informelle

Answer 6

• Revue informelle d’un élément du livrable
• en général du code
• But
• Trouver des problèmes, améliorer la qualité
• Participants
• Auteur, pairs, modérateur
• Déroulement
• Élément distribué à l’avance
• Rencontre, discussion libre
• Procès- verbal des problèmes constatés
• Suivi

Question 7

Revue formelle

Answer 7

• Revue de morceaux du livrable avant acceptation
• partie des spécifications, de la conception, du code
• Buts
• Découvrir des erreurs
• Vérifier la conformité avec les spécifications et les normes
• Participants
• Auteur, président de séance, inspecteurs (experts)
• Déroulement
• Distribution du morceau à inspecter
• étude par les participants
• Rencontre
• Décision
• – Acceptation, acceptation avec réserve, rejet
• Rapport de l’inspection

Question 8

Difficultés à la mise en œuvre

Answer 8

• Les egos des participants
• La difficulté d’intégrer la revue dans le cycle de développement
• Rassembler la documentation,
• gérer l’historique,
• gérer les réunions,
• etc.
• Manque de soutien de la hiérarchie

Question 9

Pourquoi faire des revues?

Answer 9

• Les revues sont plus efficaces que les tests pour détecter des fautes.
• les tests détectent de 2 à 4 fautes par heure.
• les revues détectent en moyenne 10 fautes par heure.
• les réviseurs expérimentés peuvent détecter 70% des fautes.
• les tests peuvent rarement dépasser un taux de 50%.
• Les revues détectent de 2 à 5 fois plus de fautes par heure que les tests

La correction des fautes trouvées pendant la phase des tests est plus
couteuse que la correction des fautes trouvées pendant les revues

• Pendant les tests d’intégration, il faut de 10 a 40 heures/personne pour
  détecter et réparer chaque faute.
• les inspections prennent moins d’une heure/faute
• Elimination des fautes le plus tôt possible
• chaque revue, inspection, compilation, et test détecte seulement une fraction des fautes
• plus le code est propre a l’entrée d’une phase et plus il sera propre en sortant de cette phase
• Elimination tôt des fautes permet une économie de temps et d’argent
• plus le processus de développement est avancé et plus il est couteux de détecter et de réparer les fautes

Question 10

Pourquoi les revues sont efficaces
* Lors des tests

Answer 10

• vous débutez avec un problème
• alors vous devez détecter la faute
• ensuite, vous concevez une solution
• finalement, vous implantez et vous testez la solution

Question 11

Pourquoi les revues sont efficaces
* Avec les revues et les inspections

Answer 11

• vous voyez la faute
• alors vous concevez une solution
• finalement, vous implantez et vous révisez la solution

Question 12

Pourquoi les revues sont efficaces
* Si le système produit un résultat incorrect Iors des tests, alors vous devrez

Answer 12

• détecter ce qui est incorrect
• résoudre le problème au niveau théorique
• détecter l’endroit dans le programme ou implanter la solution
• résoudre la faute qui a causé un tel comportement
• Vous êtes la recherche de ce qui n’a pas été planifié et cela peut prendre du temps

Question 13

Pourquoi les revues sont efficaces
* Avec les revues et les inspections

Answer 13

• vous suivez votre propre logique
• Lorsque vous détectez une faute, vous savez exactement ou vous êtes
• vous savez ce que le programme fait et ce qu’il ne devrait pas faire
• donc, vous savez pourquoi c’est une faute
• vous êtes dans une bonne position pour concevoir une solution complète et efficace

Question 14

La stratégie de revue

Answer 14

• L’objectif est de produire des programmes ayant un haut niveau de
  qualité a chacune des phases du cycle de développement
• La stratégie de revue qui permet d’atteindre cet objectif consiste a
  
  • rassembler les données sur vos revues
  • étudier les données
  • juger quelles données sont utiles pour vous
  • ajuster votre processus en conséquence
• Processus d ‘apprentissage continue

Question 15

Principes de revue

Answer 15

• Suivre un processus rigoureux avec
  
  • des critères d’entrée et des critères de sortie
  • une structure de revue
  • des directives, des listes de contrôle et des normes
• Le but est de détecter chaque faute avant le premier test
• Pour atteindre cet objectif, il faut
  
  • utiliser des normes de programmation
  • utiliser des critères de conception
  • mesurer et améliorer votre processus de revue

Question 16

Les considérations de la revue

Answer 16

• Les listes de contrôle
• Réviser avant de faire un commit
• Les relations entre les revues et les inspections

Question 17

Les listes de contrôle

Answer 17

• Lors de la réalisation d’une tâche précise, il est difficile de bien faire
  plus d’une chose a la fois
• La liste de contrôle définit les étapes a suivre lors de la révision
• En cochant chaque item, vous vous assurez de réviser correctement
• Vous pouvez établir une liste de contrôle en considérant votre
  expérience personnelle ou les statistiques sur l’historique des fautes
• Commentaires
• Taux
• Intérêt du commentaire
• Instructions de tracing d’exécution
• Structure du code
• Principes SOLID
• Références aux données
• Variables non initialisées
• Pointers fantômes
• Gestions de indices de tableaux
• Libération de allocations
• Calculs
• Conversions de types
• Overflow
• Division par zéro
• Précédence des opérateurs
• Forme des décisions
• Complexité des conditions
• Utilisation de comparaison <> dans une boucle
• Définition de constantes
• Comparaisons
• Entre types consistants
• Vérifier opérateurs < <= et > >=
• Contrôle
• Terminaison des boucles
• Sortie des procédures et fonctions
• conditions initiales
• Une itération en trop (ou en moins)
• Toutes les possibilités d’un case testées
• Taille des modules
• Mesures de complexité
• Cohésion
• Couplage
• Le plan qualité prévoit en général l’utilisation de règles
  de programmation qui doivent également être
  vérifiées.

Question 18

Réviser avant de faire un commit

Answer 18

• demande une révision du code avant le premier commit
• Les raisons sont
  • le temps requis pour la révision du code est le même qu’elle soit faite avant
    ou après le commit
  • les revues de code vont permettre de détecter des fautes de syntaxe que le
    compilateur va manquer
  • les revues de code compilé ont tendance à être beaucoup moins efficaces
  • la compilation est également efficace avant ou après la revue du code

Question 19

Différence entre l’inspection et la révision pas
à pas (Walkthrough)

• Étapes du processus d’inspection :

Answer 19

• Planification : L’inspection est planifiée par le président de séance.
• Réunion préparatoire (au besoin) : l’auteur et le président de séance décrivent le
  contexte du produit du travail et l’objectif de la revue (Peut être un simple courriel).
• Préparation : Chaque inspecteur examine le produit du travail pour identifier les
  défauts possibles.
• Réunion d’inspection : Lors de cette réunion, l’auteur présente le produit du travail,
  élément par élément et les inspecteurs signalent les défauts pour chaque élément.
• Corrections : L’auteur apporte des modifications au produit du travail selon la
  réunion d’inspection.
• Suivi : Les modifications apportées par l’auteur sont vérifiées pour s’assurer que tout
  est correct.

Question 20

Les mesures de la revue

Answer 20

• Des mesures explicites.
• Des mesures dérivées

Question 21

• Des mesures explicites

Answer 21

• la grandeur du programme qui est révisé
• le temps de révision
• le nombre de fautes trouvées
• le nombre de fautes non trouvées

Question 22

• Des mesures dérivées

Answer 22

• Nombre de LOC revue par heure
• Nombre de Fautes trouvées par KLOC
• Nombre de Fautes trouvées par heure de révision
• Rendement – « Yield »
• DRL – « Defect Removal Leverage »

Question 23

Rendement de la revue

Answer 23

• Le rendement - Yield
  
  • mesure de la qualité du processus
  • pourcentage de fautes trouvées dans un produit à un temps de revue
  • mesure l’efficacité de chaque étape du processus
  • peut être calculé seulement si toutes les fautes ont été identifiées par les tests et par l’utilisation du produit

Rendement (pour une étape) = 100*(fautes trouvées)/(fautes trouvées + non trouvées)

Question 24

«Defect Removal Leverage» - DRL

Answer 24

• DRL est le ratio de productivité de la revue par rapport un processus de base (exp. Tests)
• DRL mesure l’efficacité relative d’une étape d’un processus à corriger les fautes
• DRL est le nombre de fautes corrigées par heure pour une étape d’un processus
  relativement à un processus de base.
  • la base habituelle est I’unité de tests
  • DRL(X/UT) est le DRL pour la phase X par rapport à I’unité de test

DRL(X/UT) = (fautes par heure pour la phase X) / (fautes par heure pour l’unité de test)

Question 25

Rendement et DRL

Answer 25

• Le rendement et le DRL sont très utiles, mais ils sont disponibles seulement
  à la fin du processus
• Nous avons besoin d’autres mesures en corrélation avec le rendement et
  disponibles durant l’exécution du processus pour le contrôler

Question 26

• Ces mesures de contrôle pour le rendement sont

Answer 26

• Le nombre de LOC revue par heure
• Le nombre de fautes trouvées par heure
• Le nombre de fautes trouvées par KLOC
• Le meilleur paramètre de contrôle est le nombre de LOC revue par heure

Question 27

Outils de revues

Answer 27

• Code Collaborator de SmartBear
• Intégration avec les gestionnaires de code source et avec les gestionnaires des anomalies
• Atlassian Crucible
• Intégration avec JIRA et les autres outils Atlassian
• IDE + Logiciel de suivi de problèmes (Jira, Trello, Bugzilla) + Gestionnaire de sources (CVS, SVN, Git)
• Intégration avec l’IDE, possibilité de faire plus que juste regarder le code
• Gerrit Code Review
• Revue de code et gestion des projets Git en-ligne
• Rietveld
• Code Review pour Subversion hébergé sur Google App Engine– Code Review pour Subversion, hébergé sur Google App Engine
• Review Board
• Interface web sous licence MIT

Question 28

Meilleures pratiques – Revue du code

Answer 28

1. Passez en revue moins de 200 à 400 lignes de code à la fois.
2. limitez la revue à 300-500 LOC / heure.
3. Prenez le temps pour une revue correcte et lente, mais pas plus de 60-90m.
4. Les auteurs doivent annoter le code source avant le début de la révision.
5. Établissez des objectifs quantifiables pour la revue du code et capturez et
   analysez vos métriques de revue afin d’améliorer vos processus.
6. Les listes de vérification (check-list) améliorent la revue pour les auteurs et les réviseurs.
7. Vérifiez que les défauts sont réellement corrigés!
8. Les gestionnaires doivent encourager et considérer positivement la revue du
   code.
9. Méfiez-vous de l’effet “Big Brother”.
10. Encouragez l’Effet ego.
11. Les révisions de code doivent être allégées et non contraignantes.

Question 29

Conclusion

Answer 29

• L’objectif principal des revues doit être de détecter les problèmes
• Lorsque les programmes ont plusieurs petits problèmes, les inspecteurs
  sont distraits et ils manquent les problèmes les plus important
• Par conséquent, il faut réviser votre code avant de le faire inspecter, car
  cela
• Assure un produit de qualité pour l’inspection
• Démontre un respect pour le temps de I ’inspecteur
• Produit des inspections de meilleure qualité

*Les revues de conception et de code vont
* améliorer la qualité de votre programme
*faire économiser du temps de développement

*Pour faire des revues efficaces, vous devez
* établir les objectifs de revue
*suivre un processus stricte de revue
*mesurer et améliorer la qualité de vos revues