Comment amener les développeurs à effectuer des révisions de code en temps opportun

La société pour laquelle je travaille exige que tout le code soit examiné par d'autres développeurs avant d'être validé. Les membres de mon équipe sont souvent frustrés car les autres développeurs sont trop occupés à coder pour faire une revue, surtout si elle est très longue. Comment incitez-vous d'autres développeurs à effectuer des révisions de code en temps opportun?

(Nous utilisons git-svn afin que nous puissions continuer à coder en attendant une révision. Cependant, je trouve toujours frustrant de devoir attendre longtemps avant de pouvoir valider mon code.)

Regardez comment Facebook le fait avec leur propre application, appelée phabricator: http://phabricator.org/

Ils s'engagent essentiellement pour chaque problème, et pour chaque problème, le code est affiché, qui doit être examiné par quelqu'un. Le code ne va pas dans leur référentiel principal jusqu'à ce que le réviseur ait dit que c'est ok pour le faire.

Je suppose que cela le rend plus amusant.

De plus, un code devrait peut-être être attribué à deux personnes: une qui le fait et une qui le révise.

Bien que vos coéquipiers ne croient peut-être pas en cette critique.

Personnellement, en l'absence de réviseurs, j'ai utilisé des tests unitaires pour les fonctions de niveau inférieur et "le test du concierge" pour tout le reste: le test du concierge est appelé ainsi, car même le concierge devrait être capable de comprendre votre code.

J'ai généralement supprimé certaines parties mineures, comme les crochets de portée de bloc / fonction, les notations de visibilité, parfois même les types, et je l'ai montré aux gestionnaires, aux experts de domaine, aux partenaires, à la personne qui a demandé le code: "est-ce ce que vous voulez?"

De plus, y aller personnellement et ne pas partir tant que la révision n'est pas terminée aide.

Ou, au cas où vous ne seriez pas d'accord avec l'équipe, ou qu'ils ne vous conviendraient pas, vous savez, "si vous pouvez 'changer l'entreprise, changer d'entreprise" ...

Je vais baser cela sur quelques hypothèses:

1. Tout le monde semble vouloir écrire du code (sinon, il y a des gens qui doivent y aller.).
2. Tout le monde veut que son propre code soit archivé.

Autorisez uniquement ceux qui ont terminé leurs évaluations à faire enregistrer leur code.

Peut-être qu'un certain bloc de temps peut être consacré aux revues de code dans l'espoir d'éviter le problème de l'interruption.

L'objectif doit être de vérifier le code de qualité. Vous ne voulez pas punir / forcer les critiques au point que tout le monde lui donne simplement une approbation "tampon en caoutchouc".

Si vous avez différents niveaux (jr., Sr. Etc.), la promotion et le maintien d'un titre doivent dépendre de votre travail.

Chez deux ou trois employeurs précédents, nous avons alterné ceux qui étaient quotidiennement en révision de code. Habituellement, 3 personnes partageaient une journée CR et chaque CR devait être approuvé par deux des examinateurs. Cela a fait en sorte que lorsque c'était votre journée, vous saviez que CR était attendu de vous, quels que soient vos autres projets. Donc, tous les cinq jours environ, c'était votre tour et vous pouviez ajuster vos tâches de développement en conséquence.

Actuellement, un chef d'équipe fait un CR rapide sur le code de son équipe. Selon le domaine de l'application qui a été mis à jour, une fois le CR terminé, il peut être renvoyé à l'équipe d'examen global, où nous vérifions les éléments qui ont un impact global sur les applications, au lieu des éléments qui sont liés à une seule fonctionnalité. Quand il y a un grand examen à faire, nous le séparons généralement entre quelques personnes afin que personne ne doive faire face aux changements dans un nombre ridicule de fichiers.

Cela dit, nous ne révisons que le code qui a été validé pour la branche / variante de développement actuelle. Le code doit passer un examen du code, un examen global, un examen de la base de données et un examen de l'interface utilisateur (chacun selon les besoins) avant de pouvoir être promu dans le prochain environnement (par exemple Alpha).

Enfin, nous convenons d'un SLA sur la rapidité avec laquelle les avis sont retournés. Presque rien n'est en attente depuis plus de 48 heures et la plupart des examens sont effectués en moins de 24 heures.

La société pour laquelle je travaille exige que tout le code soit examiné par d'autres développeurs avant d'être validé. Les membres de mon équipe sont souvent frustrés ...

À moins que vous n'utilisiez des logiciels critiques ou des correctifs critiques pour la production de code candidat, il n'y a aucune raison impérieuse de s'en tenir rigoureusement à un type particulier de révision de code.

• ^{L'idée sous-jacente aux exigences de votre entreprise semble raisonnable à première vue (code révisé à 100%), mais les moyens qu'ils ont décidé d'utiliser sont contre-productifs - car, comme vous le signalez, cela conduit les développeurs à la frustration.}

En marchant dans vos chaussures, je voudrais tout d'abord signaler à la direction que les revues de code post-commit sont considérées comme aussi respectables que les revues pré-commit . Ces termes sont consultables sur le Web - si nécessaire, trouvez des références pour les sauvegarder. On n'a pas nécessairement besoin de révisions avant validation pour obtenir un code révisé à 100%.

Sur la base de ce qui précède, je leur suggérerais ensuite de laisser tomber l' attitude de microgestion et de laisser les développeurs essayer la manière qui leur semble la plus pratique. Il est préférable de laisser les programmeurs avant ou après la validation des choix. Si l'entreprise sait mieux que les programmeurs, pourquoi n'écrivent-ils pas eux-mêmes le code?

Vous avez un certain nombre de problèmes à résoudre - vous devez gagner les cœurs et les esprits et vous devez vous assurer que du temps est disponible pour les révisions de code.

La deuxième partie est probablement la plus simple - vous convenez (collectivement et cela doit inclure la direction) que la première chose qu'un développeur fait chaque matin est ses révisions de code - c'est simple, compréhensible, efficace et vous donne un bon bâton clair pour battre les gens avec s'ils ne se conforment pas. Mieux, vous n'interrompez rien, vous ne leur demandez pas d'arrêter de travailler sur leur code, vous ne demandez pas aux gens de mettre quelque chose dans leur liste de choses à faire ...

La première partie est le vrai problème - les participants au processus de révision doivent le voir comme ayant de la valeur sinon ils ne feront jamais de révision de code (qui est perçu comme n'ayant pas de valeur) quand ils pourraient écrire du code ou corriger des bogues (ce qui est sûrement plus important ...?).

Si vous pouvez combiner les deux - tout d'abord en vous assurant que tout le monde croit (ou comprend) qu'il y a de la valeur dans les revues de code - au plus basique, cela devrait signifier moins de bogues, ce qui signifie plus de nouveau code qui est généralement plus amusant - et ensuite en organisant les choses afin qu'il y ait un espace clair dans le calendrier pour les révisions de code à faire, alors j'espère que de bonnes choses se produiront ... cela fera partie de la culture.

Une fois que cela fait partie de la culture, il n'est peut-être plus nécessaire de dire "la première chose tous les jours" - mais cela étant dit, je pense que cela correspond bien au modèle, on veut probablement qu'un développeur travaille.

Dans la plupart des entreprises pour lesquelles j'ai travaillé, vous avez 3 jours pour effectuer une évaluation. Il n'est pas acceptable de ne pas faire les évaluations. Cela fait partie de votre travail. Si vous ne faites pas de critiques décentes à temps, cela affecte votre évaluation des performances. Et oui, les revues semblent toujours se produire aux moments les plus inopportuns. Dommage, apprenez à inclure le temps de révision dans vos estimations. Quoi qu'il en soit, si la direction croit vraiment que les examens sont importants (c.-à-d. Qu'elle exige que tout le code soit examiné), elle préconisera une politique similaire. De plus, si les gens ne terminent pas l'examen dans le temps imparti, cela va de pair avec leur acceptation du matériel.

Pensez à utiliser un outil comme Review Board . C'est très utile, surtout pour les longues critiques.

Vous pouvez télécharger vos différences et attendre qu'un réviseur ait terminé sa révision. Si vous avez des critiques ouvertes qui vous empêchent de poursuivre votre travail, vous pouvez le signaler lors de vos réunions quotidiennes (votre équipe souhaite que les nouvelles fonctionnalités soient enregistrées afin qu'elles puissent être testées dès que possible, n'est-ce pas?).

Quelques points à ajouter qui ne figurent pas dans les autres réponses.

Le code à réviser doit être archivé

• afin que vous examiniez une version stable.
• Il peut être sur la branche principale de développement si une version est suffisamment éloignée
• Il peut être sur branche s'il y a une bonne raison de ne pas polluer

Les tâches de blocage sont prioritaires, les révisions de code doivent donc avoir priorité sur les autres travaux (mais en essayant de ne pas interrompre votre flux). En tant que développeur, vous devriez souhaiter que d'autres révisent votre code (car vous visez à l'améliorer). Dans cette connaissance, vous devez effectuer rapidement des révisions pour les autres.

Les questions les plus difficiles sont de savoir quand et comment bien réviser le code.

Une règle qui a fonctionné pour nous sur le moment est que le code partagé doit être révisé car il a un impact plus large alors que dans le code pour une seule application (surtout étant donné que nous utilisons le développement piloté par les tests), c'est moins important.