Comment éviter les goulots d'étranglement de révision de code lorsque certains du programme de paire d'équipe
Il y a un école de pensée qui décrit les revues de code comme l'activité prioritaire numéro un pour tous les développeurs dans un sprint car ils sont soit:
a) Une source de valeur non réalisée
b) Une source de bugs
Bien que je ne sois pas sûr de m'abonner à la vue en noir et blanc, je suis d'accord avec le sentiment.
Mais assez de fond.
Nous avons un problème persistant où les avis restent dans la file d'attente pendant plusieurs jours. Les goulots d'étranglement sont invariablement causés par les développeurs principaux, car ils sont plus en demande. De plus, en raison de la nature importante de leur travail, ils ont tendance à associer des programmes afin de ne pas exiger que leurs propres révisions de code soient effectuées en tant que telles. Il n'y a donc aucune réelle incitation pour eux à procéder à des examens en contrepartie.
La plainte la plus souvent utilisée est qu’ils perdront leur fil d’esprit lors de la programmation. Il y a du vrai là-dedans, mais ils pourraient sûrement juste passer en revue après le déjeuner ou à la première heure du matin?
Y a-t-il des moyens de contourner cela? Sur les projets précédents, nous avons appliqué un SLA d'une journée qui fonctionnait bien pour la plupart, mais encore une fois, la règle avait tendance à être violée par les programmeurs de la paire.
Les développeurs se relaient pour effectuer des révisions de code afin que la charge soit déjà partagée équitablement.
Les équipes devraient être autorisées à revoir leur propre code, après tout, il n'y a personne de mieux qualifié.
Les requêtes GIT Pull implémentent l'un des modèles les plus simples et les plus robustes pour cela:
- Le code ne peut pas être fusionné avec master tant qu'il n'a pas été revu par X (deux est recommandé) par d'autres personnes, généralement il y a une stipulation d'un développeur et d'un testeur
- Tout le monde peut réviser le code. Un junior posant des questions peut avoir le même effet qu'un critique senior. Il s'agit de ramasser la complexité et les cas Edge.
Il y a quelques choses que vous pouvez faire pour vous faciliter la tâche:
- La programmation par paires compte comme une révision de code (après tout, elle a été développée ensemble)
- Gardez les changesets petits, il y a beaucoup de raisons pour lesquelles c'est une bonne idée
- Ne pas attribuer automatiquement à vos personnes les plus expérimentées et les plus occupées. Laissez les autres membres de l'équipe récupérer le code et laissez-les être fiers de la base de code
- Envisagez de créer un état supplémentaire (ou de l'inclure dans la définition de Terminé) pour vos tableaux debout. Comme tous les goulots d'étranglement, rendez-le visible pour que les gens puissent voir le travail qui doit être fait pour débloquer les gens
- Envisagez d'utiliser des outils de révision de code automatisés pour que les gens puissent se concentrer sur les choses importantes, pas sur les règles automatisables
Si vous effectuez une programmation en binôme (ou mob), avez-vous besoin d'un examen par les pairs?
J'ai précédemment écrit une réponse sur les raisons pour lesquelles on voudrait effectuer des examens de code par les pairs en premier lieu. Cependant, tous ces éléments sont également traités par la programmation par paires. Essentiellement - la programmation par paires est une révision de code en temps réel et hautement interactive.
Il peut être plus facile de dire que votre code doit être programmé par paire (et mettre en place des normes d'équipe ou des lignes directrices sur les techniques de couplage efficaces) ou passer par une révision du code, mais les deux ne sont pas requis. Bien sûr, vous pouvez toujours ajouter une révision de code pour obtenir un troisième (ou quatrième) regard sur un changement, mais si vous avez simplement besoin de vous assurer que deux personnes regardent et de garantir la qualité de chaque changement, la programmation par paires est vous que.