Comment surveiller efficacement la révision du code?


28

Je soupçonne une importante révision de code dans mon équipe. Trop de revues de code sont fusionnées sans aucun commentaire.

Il me semble qu'il n'y a pas de révision de code sans un seul commentaire.

Comment puis-je en tant que chef d'équipe contrôler correctement que mon équipe effectue un processus de révision de code approprié et comment puis-je les aider à maximiser les avantages du processus?

Mise à jour

Je pensais que les gens pourraient vouloir être informés de toute mise à jour. J'ai essayé beaucoup de suggestions qui ont été faites ici. la plupart étaient déjà utilisés. certains ont aidé un peu. Cependant, le problème est resté - certaines personnes ont continuellement reçu un mauvais code lorsque je ne regardais pas.

J'ai trouvé que la surveillance de la révision du code n'est pas aussi utile que de donner à mon équipe des outils pour améliorer leur code au départ.

J'ai donc ajouté une bibliothèque nommée "jscpd" pour détecter les pâtes de copie. La construction a échoué sur les pâtes de copie. Cela a éliminé un problème immédiatement.

nous allons ensuite essayer le codeclimat.

Je fais également une revue manuelle des anciennes revues de code une fois par sprint pendant une demi-journée. Je convertis les todos en problèmes / tickets - car j'ai découvert que les gens les écrivaient, mais ils ne sont jamais traités ultérieurement. Je fais également des rencontres avec l'ensemble des équipes pour revoir le code quand c'est approprié.

en général, on a l'impression que nous allons dans la bonne direction.


1
Si vous utilisez TFS, vous pouvez le configurer pour incorporer le nom du réviseur de code.
Krishnandu Sarkar


11
@gnat je ne suis pas d'accord. Il y a une différence entre quelqu'un qui n'aime pas les revues de code et ce que cette question demande. Cette question peut être attaquée du point de vue de la traçabilité (relier les modifications du code source à la révision, ou les défauts / améliorations / histoires aux révisions de cette implémentation, etc.) ou du point de vue de la qualité du processus et de l'audit. Les deux ont des implications, même si les gens n'ont généralement pas de problème lors de la révision du code.
Thomas Owens

3
Assistez-vous à l'un de ces examens? Peut-être qu'il est temps d'en passer un? Montrez vous-même certaines choses et demandez à chaque critique individuellement pourquoi il les a toutes manquées?
Mawg

2
Trouvez-vous que des problèmes évidents n'ont pas été décelés par l'examen? Auriez- vous ajouté des commentaires (importants)?
usr

Réponses:


70

Je vais proposer un point de vue différent de mes collègues répondeurs. Ils ont raison - impliquez-vous si vous voulez voir comment les choses se passent. Si vous voulez plus de traçabilité, il existe des outils pour cela.

Mais d'après mon expérience, je soupçonne qu'il se passe autre chose.

Avez-vous considéré que votre équipe peut penser que le processus est interrompu / stupide / inefficace pour la plupart des commits? N'oubliez pas que le processus consiste à documenter ce qui fonctionne bien, et non les règles à respecter . Et en tant que chef d'équipe, vous êtes là pour les aider à faire de leur mieux, pas pour appliquer les règles.

Donc, dans vos rétrospectives (si agiles) ou en tête-à-tête (si vous êtes un manager) ou dans des réunions de couloir impromptues aléatoires (si vous êtes un chef d'équipe non agile et qu'il y a un autre manager qui fait un sur un), faites-le . Demandez ce que les gens pensent du processus de révision du code. Comment ça marche? Comment est-ce pas? Disons que vous pensez que cela ne profite peut-être pas autant à l'équipe. Assurez-vous d' écouter .

Vous pouvez faire du plaidoyer pour la révision du code lors de ces réunions, mais il est préférable d'écouter les commentaires. Très probablement, vous constaterez que votre équipe pense que le "bon" processus doit être ajusté, ou qu'il y a une cause profonde (pression du temps, manque de réviseurs, Bob valide simplement son code, alors pourquoi ne pouvons-nous pas) .

Forcer un outil au-dessus d'un processus interrompu n'améliorera pas le processus.


5
+1 pour la bonne approche de ce problème (et bien d'autres!)
Olivier Dulac

7
+1 pour la dernière phrase. C'est quelque chose que presque personne ne comprend, mais qui est extrêmement important.
JohnEye

1
Bonne réponse. J'ai essayé .. Mon équipe dit "la société fait des choses dans le mauvais sens. Nous avons besoin de plus de qa ... et laissons les développeurs se développer" tandis que la société dit "nous voulons que les développeurs soumettent un code de bonne qualité. Nous visons à disperser l'équipe de qa car une fois que le code est de bonne qualité, les qa ne sont plus nécessaires .. "... Ce qui s'est finalement produit, c'est que les gens qui ont obtenu un mauvais code ont été renvoyés en continu et j'ai reconstruit mon équipe.
guy mograbi

43

Je n'aime pas publier des réponses sur une seule ligne, mais celle-ci semble appropriée:

Participez au processus.


15
Je n'aime pas non plus les réponses d'une ligne. Heureusement, vous avez pris deux lignes - et ma réponse. +1
Mawg

1
Je suis. mais quand je ne le suis pas ... des trucs arrivent. c'est exactement ce qui m'a rendu suspect en premier lieu. J'ai commencé à revoir la critique des autres et j'ai découvert des trucs désagréables.
guy mograbi

6

Obtenez un outil, comme ReviewBoard ou le plugin de révision de code de Redmine . Ensuite, chaque revue est créée comme une tâche qui doit être fermée ou commentée par quelqu'un (tout comme un ticket de bug). Ensuite, vous avez la traçabilité de qui a créé le ticket de révision et qui l'a fermé. Vous pouvez lier les tickets de révision aux enregistrements de code source, c'est-à-dire créer le ticket à partir d'une révision.


2

Quelques choses (pour être honnête, la plupart d'entre elles sont couvertes dans les réponses, mais je voulais les mettre en un seul endroit)

  • Vous pouvez mettre en place un processus et des règles pour vous assurer qu'une révision de code se produit, mais il est assez impossible de les mettre en place afin que la révision de code soit en réalité plus qu'un exercice de sélection de cases. En fin de compte, l'équipe doit voir les avantages du processus, si elle veut l'approcher utilement

  • Mener par l'exemple. Participez aux revues. En tant que développeur, je me sens mal si mon manager (un non-développeur maintenant) repère des choses que je ne vois pas. Mettez en évidence les problèmes qui auraient dû être pris en compte (de manière non responsable). Si un problème de production se produit, si des problèmes surviennent pendant l'AQ (si vous avez un processus d'AQ distinct), mettez en évidence les endroits où ils auraient pu être détectés lors de la révision du code. Discutez avec l'équipe de la façon dont nous pouvons nous assurer que de futurs problèmes comme celui-ci sont détectés

  • Discutez avec l'équipe de ce qu'elle souhaite que le processus fasse. S'ils n'y voient aucun intérêt (comme cela peut arriver au début), utilisez les problèmes de production et les refixes nécessaires comme preuve de son avantage

  • Utilisez un logiciel de vérification de code automatisé comme Sonarqube afin que les révisions de code puissent se concentrer sur des problèmes tels que le code incompréhensible, les erreurs logiques, le manque de documentation, etc. qui ne peuvent pas être détectés automatiquement.


2

Vous pouvez documenter ce que l'équipe souhaite dans les revues de code dont vous avez discuté et convenu avec les développeurs. Certaines choses que vous pourriez considérer dans le cadre des revues de code sont:

  • Vérifiez que le code fait ce qu'il est censé faire, c'est-à-dire qu'il répond aux exigences

  • Style de code pour garantir que les développeurs codent selon un style cohérent

  • Optimisation, par exemple nombre d'appels de fonction

  • Architecture et réutilisabilité

  • Gestion et journalisation des exceptions

  • Dette technique: le code est-il en meilleur état que lorsque le développeur a commencé à travailler dessus

  • Découvrez et construisez le code (je trouve cela utile mais d'autres développeurs de mon équipe préfèrent laisser cela aux testeurs)

  • Utilisation d'un outil automatisé (j'ai utilisé SonarQube ). Je trouve utile d'intégrer cela dans votre processus de construction pour appliquer des améliorations au code, par exemple en augmentant la couverture des tests

Certaines des étapes ci-dessus peuvent être couvertes par un outil automatisé, mais pendant que vous essayez d'améliorer la façon dont les révisions de code sont effectuées, cela vaut probablement la peine d'utiliser l'outil et la révision du globe oculaire. Cependant, les étapes les plus importantes pour prévenir la dette technique (architecture et réutilisabilité) ne peuvent pas être entièrement automatisées.

Si votre équipe n'est pas cohérente dans son application, vous pouvez essayer de n'autoriser que les développeurs qui effectuent correctement les révisions de code à avoir des droits de fusion. Par exemple, vous voudrez peut-être commencer par le développeur principal de l'équipe. Le compromis avec cette approche est que ces développeurs pourraient devenir un goulot d'étranglement dans le processus de développement, donc vous et l'équipe devez décider si vous le souhaitez. Personnellement, j'accepterais ce compromis et, grâce aux révisions de code, augmenter la discipline dans le reste de l'équipe, puis lorsque vous serez prêt, vous pourrez augmenter le nombre de développeurs avec des droits de fusion.

Enfin, cela vaut la peine de revoir les critiques. Donc, une fois par semaine, réunissez-vous avec les développeurs et discutez de manière constructive des critiques et des moyens de les améliorer.


Est-ce une annonce pour SonarQube? Je l'ai essayé - je ne le recommanderais pas, beaucoup trop douloureux pour commencer et alors que "l'open source" coûte pour tous les bits utiles.
gbjbaanb

Cela fonctionne bien dans mon équipe actuelle et n'était pas trop difficile à configurer et cela aide - ce n'est pas une publicité, mais c'est le seul outil de ce type dont j'ai l'expérience. Diriez-vous la même chose pour Redmine codereview et ReviewBoard?
br3w5

Nous utilisons SonarQube dans nos équipes, servant environ 70+ projets, allant de 10k à 3M LOC. Bien que certaines équipes ignorent simplement ses rapports, la plupart l'utilisent pour diriger des processus de refactorisation. Cela fonctionne bien, même si personnellement je préfère des outils simples et non intégrés, tels que Findbugs.
Dibbeke

Et ici, je pensais que la révision du code impliquait de vérifier si le code correspondait au document de conception: - /
Mawg

1
Merci, c'est ce que je fais en attendant. Je mettrai à jour dans quelques semaines comment cela a affecté.
guy mograbi

0

Je vais vous dire comment mon équipe a rapidement intégré la révision de code dans son flux de travail.

Tout d'abord, permettez-moi de vous poser une question. Utilisez-vous un système de contrôle de version (par exemple Mercurial, Git)?

Si votre réponse est oui, continuez.

  1. interdire à tout le monde de pousser quoi que ce soit (même de petites corrections) directement vers la branche principale (tronc) *
  2. développer de nouvelles fonctionnalités (ou correctifs) dans des branches distinctes
  3. lorsque les développeurs estiment que la branche est prête à être intégrée dans master, ils créent une "pull request"
  4. interdire à tout le monde de fusionner sa propre demande de tirage *
  5. demander à un autre développeur d'évaluer la demande d'extraction et d'examiner le nouveau code
  6. si le code réussit l'examen, bon, la demande d'extraction peut être fusionnée, sinon des correctifs peuvent être appliqués
  7. répétez l'étape 6 jusqu'à ce que le code arrive à maturité (peut être fait sans recommencer) **
  8. fait, tout votre nouveau code est examiné (au moins sommairement), par quelqu'un avec un nom

Vous avez maintenant un point précis dans votre flux de travail où la révision du code est effectuée.

Agis là-bas.

* peut être appliqué automatiquement, avec des crochets côté serveur

** cette procédure est entièrement prise en charge par GitHub (entre autres), et est assez facile à utiliser, consultez-la


2
Même avec un tel processus (qui, je suppose, se produit en fait à partir de la description de la question), certains développeurs pensent parfois "ah, j'ai suffisamment confiance en mon collègue et j'ai trop à faire moi-même, donc je vais simplement le fusionner sans vraiment lire les détails, voire les commenter ". (Nous avons un processus similaire dans notre équipe, avec deux approbations nécessaires (de la part de personnes autres que l'auteur des relations publiques), avant qu'il ne puisse être fusionné. Il arrive encore parfois que des changements soient effectués sans un examen approfondi.)
Paŭlo Ebermann

1
@ PaŭloEbermann je vois. Je crains que ce soit une conséquence inévitable des circonstances, si vous n'avez pas assez de temps pour faire tout ce dont vous avez besoin, la qualité en souffrira, d'une manière ou d'une autre. Sill, si ça ne marche pas "parfois", ça veut dire que ça marche "la plupart du temps", non?
Agostino

1
Oui, cela a aidé un peu en autorisant la fusion uniquement pour un ensemble limité de personnes, qui avaient pour tâche de vérifier si l'examen réel avait été effectué correctement.
Paŭlo Ebermann

J'avais une interdiction similaire, et il va sans dire: le développement a presque cessé. Cette règle a duré 2 semaines entières, après quoi les gestionnaires ont dû ajuster leurs plans.
BЈовић

@ BЈовић votre équipe faisait-elle régulièrement des révisions de code auparavant ? Cette technique est utilisée par beaucoup, en particulier dans l'écosystème Open Source. Le fait que cela n'ait pas fonctionné pour votre équipe ne signifie pas que cela ne peut pas fonctionner pour les autres.
Agostino

-2

Je pense que vous devez créer un modèle et demander aux membres de votre équipe de le mettre à jour chaque fois qu'ils effectuent une révision du code. Mais même dans ce cas, vous devriez participer au processus d'examen au départ.

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.