Processus de révision du code ?

Question

Je cherche à formaliser la façon dont nous faisons les revues de code au sein de mon département car pour le moment c'est un peu désorganisé.

Disposez-vous d'un processus formel de révision du code ? Si oui, quel est-il et comment pensez-vous qu'il pourrait être amélioré ?

Je travaille dans une équipe de 5 développeurs, ce qui signifie qu'il n'y a pas beaucoup d'expérience dans ce type de processus au sein de l'entreprise.

UPDATE Pour clarifier :

Je dis que je travaille dans une équipe de 5 personnes, typiquement nous travaillons tous sur des projets différents, 5 personnes c'est la taille du département de développement. Ce qui, dans mon expérience, est minuscule (dans mon dernier emploi, nous étions 40 et jusqu'à 6 personnes travaillaient sur un projet donné).

Answer 1

Dans mon entreprise, nous définissons les rôles suivants pour une réunion de révision du code :

• Modérateur - il/elle est chargé(e) de veiller à ce que la réunion d'examen du code soit efficace et axée sur les objectifs.
• Auteur - Le développeur qui a écrit le module/code qui est examiné ;
• Réviseur - Un ou plusieurs développeurs qui révisent le module.

Le nombre minimum de personnes pour une revue de code efficace est d'au moins 3 : l'auteur évident, un modérateur et au moins un réviseur. Cela élargit les probabilités de trouver des bogues potentiels.

La procédure officielle est la suivante :

1. Le développeur crée le code

2. Le développeur crée un DRR - Document Review Report - dans lequel il indique le code qui fait l'objet de la révision.

   • Les classes et les révisions du SVC qui sont en cours d'examen ;
   • Les rôles pour l'examen du code et les personnes assignées à chaque rôle ;
   • L'étiquette CVS qui marque le code en cours de révision sur le système de contrôle de la source.
   • L'étiquette CVS qui marquera le code après que les modifications résultant de la révision du code aient été appliquées par l'auteur.

3. La réunion de révision du code est programmée par l'auteur.

4. La réunion de révision du code est terminée. Les défauts trouvés sont enregistrés dans le DRR.

5. L'auteur corrige les défauts et signe la RRC pour indiquer que la modification a été effectuée.

6. L'auteur marque le système CVS avec la balise de sortie de la revue de code déclarée dans le DRR.

7. L'auteur remet le DRR au modérateur.

8. Le modérateur vérifie si les modifications ont été effectuées et peuvent être trouvées sur le système de contrôle de la source.

9. Le modérateur signe le DRR pour indiquer que la modification a été confirmée.

10. Le modérateur remet le DRR au service qualité pour archivage. Si aucun département qualité n'est en place, le chef de projet doit enregistrer une copie papier du DRR dans le dossier du projet.

---

Ejemplo:

Le développeur John Doe crée une classe de mathématiques qui additionne deux nombres. Il fait de son mieux pour mettre quelques bogues à l'épreuve du processus de révision du code.

public static class MyMath {
    public static int Add(int a, int b) {
        return a - b;
    }
}

Il place son code dans le système de contrôle des sources et la classe MyMath.cs obtient la révision 1.1.

Ensuite, il va rédiger le RDR - Rapport d'examen des documents.

Modules/Classes

MyMath.cs myproject/implementation/common/MyMath.cs (1.1)

Rôles

Moderator - Jill Goner jill.goner@example.com
Author - John Doe john.doe@example.com
Reviewer #1 - Matt Groening math.groening@example.com

Tags

Input - PROJECT\_0\_0\_1\_INPUT\_REVIEW
Output - PROJECT\_0\_0\_2\_OUTPUT\_REVIEW

John Doe marque la révision actuelle 1.1 de MyMath.cs avec le tag PROJECT_0_0_1_INPUT_REVIEW sur le système de contrôle de source.

John Doe programme la réunion.

La réunion a lieu et les défauts sont marqués sur le DRR. Le nombre total de défauts est également indiqué.

John Doe va faire les changements sur le code source et livrer la révision modifiée au système de contrôle de la source.

John Doe applique le tag de révision de sortie PROJECT_0_0_2_OUTPUT_REVIEW.

John Doe signe le DRR et le remet à l'animatrice Jill Goner.

Jill Goner continue et vérifie que les modifications ont été effectuées et que la balise de sortie a été créée.

Jill Goner signe le DRR et le remet à l'ingénieur SQA (Software Quality Assurance).

Indice d'appartenance - Maintenez les revues de code à une durée maximale de deux heures. Les humains ont tendance à négliger les choses importantes lors de la révision du code lorsque les sessions de révision du code sont longues. Il est préférable de répartir une révision sur plusieurs sessions plutôt que d'essayer de tout faire en une seule fois.

Answer 2

Quand je travaillais à l'on launchpad.net J'ai aimé le processus de révision du code là-bas. Il est très structuré, s'appuie sur divers instruments ad hoc, est assez dépendant de l'utilisation de la technologie de l'information et de la communication (TIC). DVCS et est lié à d'autres pratiques agiles. Mais je vais essayer de saisir l'essentiel de la pratique de la révision du code.

Chaque tâche de développement (généralement associée à un bogue ou à une spécification) est effectuée sur une nouvelle branche basée sur le tronc. Toutes les tâches doivent produire un diff unifié d'une longueur maximale de 400 lignes. Si une tâche produit un changement plus important que cela, elle doit être décomposée en tâches plus petites en utilisant des techniques de refactoring. Bien sûr, des exceptions peuvent être accordées à l'occasion.

La règle des 400 lignes a été établie parce que le temps de révision du code n'est pas linéaire par rapport à la taille du patch. Les petits patchs sont donc importants pour préserver la vélocité.

Lorsqu'une tâche est terminée, la branche est publiée sur un wiki, où un robot génère le diff pour révision. Un réviseur de code (il y a un groupe spécifique de réviseurs de code au sein de l'équipe de développement) choisit la branche, et écrit un email qui ressemble à une réponse au patch. L'e-mail doit inclure une marque telle que "merge-approved" (vous pouvez l'intégrer tel quel), "merge-conditional" (des changements triviaux sont nécessaires avant l'intégration, mais une autre révision ne sera pas nécessaire), ou un autre marqueur dont je ne me souviens pas pour le moment qui signifie "réparez ce que j'ai demandé, puis nous aurons un autre tour de révision".

Toutes les révisions de code étaient enregistrées sur une liste de diffusion, afin que d'autres réviseurs et développeurs puissent les voir, et que les normes de code puissent être diffusées plus efficacement. Un wiki des meilleures pratiques et des normes de codage était également activement maintenu.

Dans mon poste actuel, je commence à faire des revues de code avec des collaborateurs qui ne sont pas des programmeurs professionnels (plutôt des personnes orientées mathématiques) et qui n'ont aucune expérience du langage de programmation (Python) ou des revues de code. J'ai trouvé que le fait de passer en revue le courriel de revue de code dans le style de programmation en binôme a permis de désamorcer le sentiment d'attaque personnelle qui est souvent ressenti par les personnes qui n'ont aucune expérience préalable des revues de code.

Answer 3

Un processus de base de révision du code est le suivant :

1. Faites un changement
2. Laissez un autre membre de votre équipe vérifier le changement.
3. S'il est approuvé, validez le changement. Sinon, effectuez une meilleure modification et passez à l'étape 2.

Cela fonctionne bien pour les petites équipes, mais les grandes organisations exigent plus de contrôle et de réunions. Si vous voulez aller à l'extrême avec votre équipe, vous pouvez tout aussi bien commencer à programmer en binôme.

Si vous souhaitez commencer modestement et utiliser un outil intelligent, je vous conseille d'ajouter un outil de suivi des problèmes (tel que Trac , redmine , Bugzilla et ainsi de suite). Un gestionnaire de problèmes facilite l'examen des modifications parce que vous pouvez vous référer au jeu de modifications ou au commit d'un problème/caractéristique particulier. Vous pouvez demander à un collègue développeur d'examiner une fonctionnalité en attente enregistrée et de jeter un coup d'œil au code modifié (via le jeu de modifications) pour voir si quelque chose ne va pas.

Answer 4

C'est ce qui a fonctionné avec succès pour mon équipe dans le passé. Une combinaison de revues de code en face à face et par courriel.

Le contexte :

Une équipe de 10 développeurs. 1 grand projet. 1 chef de projet/développement. Tous basés physiquement dans le même bureau. Basé sur le principe qu'aucun développeur ne possède son propre code. Il peut être responsable de son codage au départ, mais pas de la correction des bogues par la suite. Le processus de révision du code a été facilité par le système d'équipe de Visual Studio. Nous pouvions mettre notre code sous clé et quelqu'un d'autre pouvait le retirer pour le réviser sans avoir à le valider dans la branche de développement.

Processus de révision du code :

1. Conception : nous avons fourni une vue d'ensemble de haut niveau de la manière de résoudre un problème. Pas de code à ce stade. Discutez avec un autre développeur disponible et avec le responsable du développement. L'avantage d'un examen précoce de la conception est d'obtenir des informations qu'un développeur seul aurait pu manquer. Reconception, etc. si nécessaire.
2. Codez-le.
3. Soumettez le code/le lien vers les modifications du code à un autre développeur pour une révision par les pairs par e-mail/électronique. Le mieux est de le soumettre à un développeur qui n'a pas été impliqué dans la révision de la conception. Notez que le réviseur doit examiner le code sans l'intervention du développeur initial. Ceci est important. Nous l'abordons de cette façon pour plusieurs raisons.

Si le code peut être compris par quelqu'un qui ne l'a pas écrit, on peut dire qu'il est maintenable si le développeur original n'est plus là pour le demander (il a quitté l'entreprise ou autre) ou même s'il est toujours là.

Si le réviseur de code ne peut pas comprendre le code, il le renvoie au développeur qui le rend plus compréhensible, soit en augmentant la documentation, soit en remaniant le code. Cela peut être aussi simple que d'ajouter plus d'informations à la description du bogue auquel le changement de code est lié. En soi, cela permet de gagner beaucoup de temps à l'avenir.

La capacité à saisir le code de quelqu'un d'autre et à le comprendre rapidement est très avantageuse.

1. Le développeur et le réviseur de code se réunissent et discutent du code et des améliorations.
2. Le développeur apporte des modifications si nécessaire.

Les revues de code sont à mon avis très importantes et avantageuses pour le processus de développement. Vous apprenez en lisant le code des autres. Votre capacité à lire le code des autres augmente. Vous apprenez sur d'autres domaines du système que vous développez. C'est une autre personne qui sait comment quelque chose fonctionne, donc une autre ressource pour coder dans ce domaine si nécessaire. C'est la diffusion de la connaissance. Il n'est pas facile de s'asseoir et d'écouter quelqu'un pointer les défauts de son code, ce qui éloigne naturellement les gens des revues de code.

Answer 5

1.) Les revues de code doivent être planifiées et intégrées dans le calendrier.

2.) Nous procédons à une vue d'ensemble/prévisualisation du code, c'est-à-dire que l'auteur du code explique d'abord la fonctionnalité du code qu'il veut faire examiner. Niveau algorithmique. Cela donne une bonne idée et le contexte pour l'examinateur et il obtient diverses perspectives vers le code au cours de l'examen du code réel, à savoir : la fonctionnalité perspective, l'optimisation (temps d'exécution / mémoire) perspective, la portabilité, la lisibilité.

3.) Lors d'une réunion, seules deux heures de code doivent être examinées. Nous avons découvert par essai et erreur que 2 heures est une sorte de limite (ni trop, ni trop peu) pour conserver la qualité des revues et des commentaires.

4.) Envoyez le code aux réviseurs 2 à 3 jours à l'avance, en fonction de la complexité/du contenu du code, après que la pré-vision ait eu lieu.

5.)Les réviseurs l'examinent hors ligne et viennent à la réunion avec leurs commentaires.

6.)Lors de la réunion, l'auteur écoute chaque commentaire, l'accepte ou le rejette avec la raison correspondante.

Ce processus m'a bien servi jusqu'à présent.

-AD