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.

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.

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

Participez au processus.

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.

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.

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.

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

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.