Faire réviser le code par TOUS les développeurs


13

Je suis développeur de logiciels dans une équipe de 7 à 8 développeurs. Nous faisons des révisions de code depuis un certain temps maintenant et la qualité du code s'est améliorée au fil du temps.

Cependant, j'ai récemment remarqué que certains développeurs sont invités à plus de révisions de code que les autres. Je crains que ce soit à cause de leur attitude flexible.

À mon avis, ce n'est pas ainsi que les révisions de code devraient être effectuées: toute l'équipe devrait en être responsable et les réviseurs de code ne devraient pas être choisis pour leur volonté d'accepter facilement les modifications.

Comment gérez-vous ce problème dans votre équipe?

Avez-vous établi des règles pour choisir les réviseurs de code?

Pensez-vous que les réviseurs de code devraient être récompensés pour le temps qu'ils passent à faire de (bonnes) révisions de code? Et comment devraient-ils être récompensés?

Merci pour vos réponses / idées.


7
Avez-vous envisagé de créer un système de tournoi à la ronde où le codeur est laissé dans l'ignorance sur qui passe en revue et le réviseur est laissé dans l'ignorance sur qui est le codeur?
Neil

1
Je ne l'ai pas fait, mais j'aime cette idée! Merci!
guillaumegallois

1
Qui est responsable et pourquoi ne font-ils pas leur travail, ce qui devrait impliquer de s'assurer que tout le monde fait le leur?
JeffO

Dans mon équipe, les relecteurs sont automatiquement affectés chaque fois qu'une demande de tirage est ouverte. Les examinateurs sont sélectionnés dans le tournoi à la ronde par équipe. Nous avons un webhook pour chacun de nos référents qui attribue automatiquement les réviseurs à chaque ouverture du RP. Il conserve essentiellement une liste de tous les développeurs, et qui a été affecté en dernier, et se fraye un chemin à travers la liste.
Dan Jones

Réponses:


12

Nous ne choisissons pas de réviseurs.

Dans notre équipe:

  • Toutes les modifications de code doivent être examinées avant la fin de la demande d'extraction
  • Au moins un développeur doit réviser le code (deux réviseurs ou plus sont meilleurs et avoir des testeurs, des analystes et d'autres membres de l'équipe faisant la révision du code est également extrêmement bénéfique)

Les revues de code ne sont pas attribuées, les gens les récupèrent quand cela fonctionne pour eux. Il est entendu que nous ne pouvons pas diffuser d'histoires dans le pipeline. À l'occasion, quelqu'un mentionne qu'ils attendent un CR dans le standup, mais c'est à peu près tout.

J'aime ce modèle, il donne aux gens de ramasser ce qu'ils peuvent et évite de «donner des emplois aux gens».


6

Introduisez une règle selon laquelle un bogue peut être attribué pour la correction, non seulement à ceux qui ont commis la modification, mais uniquement à ceux qui l'ont révisée. Cela devrait créer une perspective correcte pour la révision du code.

Pour ce qui est de,

Pensez-vous que les réviseurs de code devraient être récompensés pour le temps qu'ils passent à faire de (bonnes) révisions de code?

Eh bien, je ne sais pas dans quelle mesure les développeurs sont généralement récompensés pour leur travail, à l'exception du simple fait de recevoir un salaire et d'être un peu fiers de ce qu'ils ont fait. Mais comme la révision du code fait partie de leur travail, le réviseur devrait avoir du temps pour la révision et partager le crédit d'une manière ou d'une autre.


2
C'est une idée intéressante, mais la plupart du temps, lorsqu'un bug survient, 90% du travail détermine exactement la cause du bug et 10% du travail le corrige. Faire un post-mortem pour comprendre exactement quel changement a introduit le bogue peut même ne pas se produire, à moins que cela aide à comprendre ce qui se passe ou comment faire une correction sûre.
DaveG

Vous avez fait un bon point sur le crédit que les réviseurs de code devraient recevoir. C'est certainement un problème qui devrait être résolu. Merci pour votre réponse!
guillaumegallois

Je pense que cela pourrait amener les gens à essayer de ne pas faire du tout de révision de code ou peut-être que vous n'aurez aucun travail à faire parce que les gens commenceront à tergiverser.
Mateusz

5
Cette réponse suppose que l'objectif des révisions de code est de trouver des bogues. Ce n'est pas le cas, l'objectif principal est de garder le code dans un état maintenable et évolutif (et si vous êtes chanceux, certains bugs sont également trouvés).
Doc Brown du

@DocBrown pour éviter les bogues et aussi pour s'assurer que la future correction du bogue sera plus rapide (à la fois en familiarisant l'autre développeur avec le code et en s'assurant que le code est bien écrit)
max630

4

Le principal problème que vous rencontrez n'est pas technique, mais certains outils peuvent réduire la quantité d'efforts qu'exigent les révisions de code. Il y a quelques défis à surmonter:

  • Comprendre ce qu'est le changement. Les requêtes Git Pull sur les branches de fonctionnalité aident vraiment ce processus.
  • Faire de la révision du code un événement où les gens doivent être dans la même pièce. Cela ajoute le stress de la planification, des ressources de réunion, etc. GitHub, GitLab et BitBucket autorisent les révisions asynchrones afin qu'elles puissent se produire lorsque l'homologue est prêt.
  • La possibilité de fournir une rétroaction significative lors de l'examen du code. Pour être honnête, la fonction de commentaire ligne par ligne dans GitHub, GitLab, les demandes d'extraction Bitbucket est vraiment plus utile qu'une réunion en face à face. Cela semble moins politique.

Cela ne veut pas dire que vous ne pouvez pas utiliser SubVersion ou d'autres outils (comme Fisheye) pour vous aider, mais l'intégration intégrée dans le pipeline Git avec des branches de fonctionnalités rend vraiment le travail moins compliqué.

En dehors de l'outillage, vous devez regarder plus de défis sociaux:

  • Demandez à vos développeurs de commencer leur journée en examinant toutes les demandes de tirage ouvertes pour les approuver.
  • Demandez à vos développeurs d'examiner toutes les demandes d'extraction ouvertes avant de commencer une nouvelle tâche
  • Exigez l'approbation de plusieurs personnes pour vos demandes d'extraction.

Il pourrait également être utile de vérifier quels types de tâches sont en cours de révision du code par les personnes les plus engagées. Ils pourraient saisir toutes les critiques faciles, ce qui rend les choses plus douloureuses pour tout le monde.


Le dernier point est bon. J'ai déjà travaillé avec un développeur d'une petite équipe qui ne révisait que les modifications apportées aux logiciels qu'il avait écrites, ce qui a provoqué des goulots d'étranglement importants ailleurs dans l'équipe.
Robbie Dee

Dans ce cas, il semble que quelqu'un essaie de protéger son «territoire». Dans la mesure du possible, vous souhaitez favoriser un sentiment d'appartenance communautaire au code. En d'autres termes, il n'y a pas de sanctuaires protégés dans le code qu'aucun autre développeur, sauf les "bienheureux", ne peut toucher. Je comprends s'il y a un écart de spécialité et que vous ne pouvez pas réviser les mathématiques, mais vous pouvez au moins vérifier dans quelle mesure le code correspond à son intention.
Berin Loritsch

2

Une bonne idée est de le faire sur une base de tournoi à la ronde - vous choisissez quelqu'un qui a fait le moins de commentaires pour votre code. Au fil du temps, tous les membres de l'équipe auraient dû faire à peu près le même nombre d'examens. Il diffuse également les connaissances.

Évidemment, il y aura des exceptions occasionnelles comme les vacances où il y aura des pics et des creux.

Il ne devrait pas y avoir de distinction entre juniors et seniors / leads. Les révisions de code doivent être effectuées pour le code de chacun - peu importe leur niveau de responsabilité. Il réduit la friction et permet de partager différentes approches.

Si vous êtes toujours préoccupé par la qualité des révisions après tout cela, envisagez d'introduire un ensemble de normes minimales pour une révision de code à passer. Ce que vous incluez est entièrement à vous, mais certaines choses que vous voudrez peut-être considérer sont la couverture du code, les tests unitaires, la suppression du code commenté, les métriques, les commentaires suffisants, la qualité de la construction, les principes SOLID, DRY, KISS, etc.

En ce qui concerne les revues de code incitatives, le code de qualité est la récompense. Nous avons tous, je suis sûr, travaillé sur des bases de code sous-optimales où la douleur aurait pu être considérablement réduite si un autre développeur venait de donner le code une fois depuis le début et a suggéré des changements constructifs.


0

Il semble que l'équipe ne dispose pas d'un processus formel pour les révisions de code.

Je ne parle pas de créer un document Word de 350 pages, mais simplement de simples puces sur ce que le processus implique.

Les bits importants:

  1. Définissez un ensemble principal de réviseurs. Pas de déclarations générales. Nommez des gens.

    Ceux-ci devraient être vos développeurs seniors.

  2. Exiger que plus d'un examinateur principal se déconnecte de l'examen.

  3. Identifiez au moins 1 autre examinateur non principal à chaque sprint ou version qui est un examinateur principal temporaire. Exiger leur signature sur toutes les révisions de code pendant cette période.

L'élément n ° 3 permet aux autres développeurs de se tourner vers le groupe principal de réviseurs. Certaines semaines, ils passeront plus de temps sur les évaluations que d'autres. C'est un équilibre.

Quant à récompenser les gens? Souvent, reconnaître l'effort qu'une personne fait lors de la révision du code devant toute l'équipe peut fonctionner, mais ne vous inquiétez pas.

En cas de doute, définissez le processus et dites à l'équipe qu'elle doit s'y tenir.

Et il y a une dernière chose que vous pouvez essayer - aussi controversée soit-elle: laissez le @ # $% frapper le ventilateur, si je peux utiliser un idiome.

Laissez l'équipe échouer, car le processus de révision du code n'est pas suivi. La direction s'impliquera, puis les gens changeront. Ce n'est vraiment qu'une bonne idée dans les cas les plus extrêmes où vous avez déjà défini un processus et où l'équipe a refusé de le respecter. Si vous n'avez pas le pouvoir de licencier des personnes ou de les discipliner (comme la plupart des développeurs principaux ne le font pas ), vous devez impliquer quelqu'un qui peut faire ce genre de choses.

Et il n'y a rien de tel que l'échec à faire changer les choses. Malgré ce que les gens pourraient dire, vous pouvez diriger le Titanic - mais pas avant qu'il n'atteigne le burg de glace.

Parfois, il suffit de laisser le Titanic frapper le burg de glace.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.