Comment introduire progressivement les revues de code?

Je dirige une équipe avec une demi-douzaine d'ingénieurs seniors. Je suis convaincu que cela nous serait très utile de faire des révisions de code pour toutes les raisons standard. Pas nécessairement tous les changements, mais au moins un flux constant de revues de fond. Alors les gens voient au moins les changements des autres et commencent à en parler.

Existe-t-il un bon moyen de présenter des avis? Je ressens une grande réticence de la part de l'équipe, car c'est juste une chose à faire et les conversations peuvent devenir douloureuses. J'ai l'impression que l'examen de chaque changement n'est pas un débutant, au moins dans un premier temps. J'aimerais que les gens entrent dans le rythme et s'entraînent à faire des révisions avec une faible fréquence avant d'amplifier la quantité.

Quelqu'un a-t-il réussi à introduire progressivement les révisions de code? Comment? J'ai pensé à exiger des révisions sur les fichiers ou les bibliothèques "chauds". Ou cueillir au hasard. Ou bien je choisis les changements à choisir. Ou est-ce que faire le grand saut et faire chaque changement est la seule voie à suivre?

Ce n'est pas un problème d'outillage ou de processus. C'est une question de culture. Vous décrivez une équipe composée de personnes sensibles aux critiques et protectrices de leur propre travail. C'est très, très courant. Mais ce n'est pas professionnel.

Mon conseil est de commencer par donner l'exemple. Proposez vos commits pour examen. Soyez ouvert pour demander aux gens de souligner les problèmes de votre approche. Soyez réceptif aux commentaires. Ne soyez pas sur la défensive, mais explorez plutôt les raisons de la rétroaction et convenez des actions en équipe. Encouragez une atmosphère de dialogue ouvert. Trouvez un ou deux champions dans votre équipe qui sont prêts à le faire également.

C'est un travail difficile.

La première étape serait de marcher vers quelqu'un et de lui dire "hé, reverrais-tu mon code?". Soyez le changement que vous souhaitez voir dans votre organisation. Si vous ne trouvez pas une seule personne disposée à le faire, vous ne pourrez pas convaincre toute l'équipe. Si vous réussissez tous les deux, informez-en l'équipe.

Une fois que vous avez trouvé quelqu'un pour réviser votre code, demandez-lui si cela vous dérange si vous révisez une partie de son code. Formulez-le comme une opportunité d'apprentissage pour vous et non comme une opportunité pour eux d'améliorer leur code.

En tant que chef d'équipe, la plus grande valeur que je retire du processus de révision du code est la connaissance de ce qui se passe. J'aime avoir la chance de voir tous les changements, même si je n'ai pas de changements ou de suggestions pour le développeur. J'appelle ces «examens de sensibilisation». Je peux les retourner en moins de 30 minutes pour qu'il n'y ait pas de goulot d'étranglement.

Je vous suggère de commencer par ceux-ci. Définissez le processus de soumission de la révision du code (il est assez simple si vous utilisez TFS) et faites en sorte que tout le monde s'engage à vous soumettre ses modifications (et vous uniquement) avant l'enregistrement. Dites-leur que c'est uniquement pour la sensibilisation et que personne ne critiquera leur code.

Après une ou deux révisions de sensibilisation, commencez à inviter les autres membres de l'équipe à réviser le code de chacun ... à nouveau, uniquement pour la sensibilisation. Croyez-le ou non, cela seul peut être utile pour la cohésion de l'équipe et l'uniformité du code.

Une fois que toute l'équipe sera engagée, vous constaterez probablement que vos développeurs ne peuvent tout simplement pas résister à faire des suggestions sur le code des autres. Cela se produira naturellement et organiquement (les ingénieurs ne peuvent pas s'aider eux-mêmes!) Demandez à l'équipe de se rencontrer pour en discuter et élaborer des directives pour offrir des commentaires constructifs les uns aux autres. Ensuite, définissez-les. Félicitations, vous êtes maintenant en mode de révision de code complet!

Existe-t-il un bon moyen de présenter des avis?

Il existe probablement plusieurs bonnes façons, selon votre équipe et les avantages que vous espérez obtenir des avis, mais toute approche aura des caractéristiques communes:

• expliquer ce que vous attendez: il s'agit d'un nouveau processus pour votre équipe, ou du moins d'un changement par rapport au processus existant, il est donc juste de faire savoir à l'équipe pourquoi vous installez le changement, comment vous vous attendez à ce que l'équipe en profite, et comment vous saurez si cela fonctionne.

• définir le processus: guidez les gens à travers le processus que vous souhaitez qu'ils suivent pour examiner le code, discuter des changements, etc., afin que tout le monde dans l'équipe sache comment procéder.

• définir les critères: Présenter les types de changements que les gens devraient et ne devraient pas appeler comme nécessitant des améliorations. Par exemple, les bogues et les améliorations significatives des performances sont bons à signaler; les problèmes de normes de codage, de lisibilité et de maintenabilité doivent être notés mais pas approfondis; les questions de goût ou de style personnels devraient être laissées de côté.

• discuter du comportement: précisez que l'objectif est d'améliorer le code et de favoriser une compréhension commune qui aidera l'équipe à écrire un meilleur code dans tous les domaines, à ne gêner personne, à régler les scores, etc. Les critiques doivent être objectives et constructives, jamais personnelles. L'établissement de quelques règles de base peut aider à soulager les scrupules concernant la révision du code.

• mettez-vous sur la sellette en premier: Que vous prévoyiez d'avoir des critiques individuelles ou des critiques de groupe, c'est probablement une bonne idée de passer en revue les premières en tant que groupe. Le premier examen devrait être de votre propre code afin que les autres membres de l'équipe puissent voir que le processus n'est pas si mauvais et que vous êtes prêt à le parcourir vous-même.

Commencez par organiser une réunion de lancement pour expliquer tout ce qui précède et répondre aux préoccupations des membres de l'équipe. Suivi par e-mail qui documente le processus.

Je ressens une grande réticence de la part de l'équipe, car c'est juste une chose à faire et les conversations peuvent devenir douloureuses.

Ce sont deux préoccupations distinctes. Si vous pensez que les évaluations seront utiles, vous devez prévoir du temps dans le calendrier pour les réaliser. Assurez-vous que les membres de l'équipe comprennent que la révision est un travail comme toute autre tâche, et non quelque chose de plus qu'ils doivent faire tout en continuant à effectuer d'autres tâches au même rythme.

Les réunions d'examen de groupe doivent être dirigées par un facilitateur qui fait avancer la discussion, limite la durée des réunions et maintient les choses constructives. Cela devrait contribuer grandement à éviter les conversations douloureuses. Au moment où vous êtes prêt à commencer les évaluations individuelles, l'équipe devrait avoir adopté des comportements qui les aideront à garder les choses constructives par elles-mêmes.

Vous devriez également revoir le processus d'examen de temps à autre. Réunissez l'équipe de temps en temps pour discuter du processus: comment il fonctionne, comment il pourrait être amélioré, quelles pratiques devraient être abandonnées, etc. Donnez à l'équipe la propriété du processus et la liberté d'essayer de nouvelles choses.

Une façon de le faire est de mener des sessions de révision du code après chaque sprint, et de passer par les changements de chacun où le code est projeté sur une sorte de grand écran afin que tout le monde dans l'équipe puisse participer. Toute amélioration peut être ajoutée en tant que dette technique au carnet de commandes.

Cette approche fonctionne, mais elle n'est pas parfaite.

Le but ultime serait d'utiliser la demande d'extraction pour fusionner le code dans le maître ou développer une branche où chaque ligne de code doit être revue.