Qui devrait faire des révisions de code?

Dans mon entreprise, l'architecte effectue principalement des révisions de code. C'est un logiciel très expérimenté et intelligent, il est donc très bon dans ce domaine. Lorsque les développeurs font les revues de code, ils ne le font pas aussi à moitié. Nous avons essayé de donner aux développeurs de faire plus de révisions de code, mais la qualité des révisions de code n'était pas bonne. Nous utilisons Scrum for comme méthodologie de développement.

Cependant, avec le système actuel, il y a deux problèmes:

1. L'architecte devient un goulot d'étranglement

2. Les développeurs ne prennent pas la responsabilité de la qualité du code et de l'architecture (ce qui entraîne toutes sortes de problèmes).

Comment pouvons-nous résoudre ces problèmes? Devrions-nous changer qui révise le code?

Les développeurs doivent effectuer des révisions de code. Ils devraient faire des revues de code, car ils devraient connaître le code, les normes et les pratiques de style d'entreprise. En faisant réviser le code par quelqu'un d'autre, vous dites à vos développeurs qu'il n'est pas de leur responsabilité de s'assurer que le code respecte les normes de l'entreprise.

Si vous pensez qu'ils ont besoin de formation sur la révision des codes, faites-le leur. Compte tenu de votre situation actuelle, vous pouvez demander à un développeur de réviser le code, puis de le faire commenter par votre architecte.

Dans cette situation, vous avez besoin de la connaissance de ce développeur expérimenté pour aider le reste de l'équipe à grandir. La qualité d'une équipe n'est pas définie par les compétences du meilleur développeur; il est défini par les compétences des pires. Vous pouvez essayer des choses comme:

• Examens collaboratifs. Cela a très bien fonctionné dans ma dernière équipe. Nous avons mis toute l'équipe dans une pièce avec un projecteur et commencé à examiner certains éléments. Peut-être qu'au début l'architecte est celui qui guide l'examen, mais dans quelques semaines (nous avons réservé une ou deux heures tous les vendredis), toute l'équipe commence à parler et à comprendre les concepts clés que seul l'architecte semble connaître actuellement.

• Programmation en binôme. Pour moi, c'est le meilleur outil pour diffuser les connaissances en équipe.

Bien que je puisse voir l'intérêt de faire en sorte que l'architecte système / logiciel approuve tous les changements / validations, les développeurs de logiciels devraient pouvoir effectuer des révisions sans impliquer l'architecte - sauf pour l'arbitrage.

Mes procédures de révision [*] préférées sont:

• Changements de groupe par exigence / problème.
• Invitez tous les développeurs, l'architecte logiciel et l'auteur de l'exigence / problème à réviser. (Ils ne sont pas tous tenus de faire un examen.)
• Envisagez un examen terminé lorsque:
  • Deux développeurs ont examiné.
  • Tous les commentaires sont répondus. (Peut-être en demandant à l'architecte logiciel de prendre une décision.)
  • Une journée de travail s'est écoulée sans autre discussion (ou toutes les parties invitées ont passé en revue).

Donc, ma réponse courte à votre question est la suivante: les développeurs devraient modifier les avis.

[*] Malheureusement, ce n'est pas toujours ainsi que fonctionnent les projets auxquels je participe.

J'aime la pratique des révisions de code d'équipe occasionnelles qui incluent toute l'équipe des architectes, mais ensuite beaucoup, beaucoup et beaucoup de révisions de code entre deux ou trois membres de l'équipe.

Si le code est vraiment délicat ou sensible, faites appel à l'architecte ou aux membres supérieurs de l'équipe.

Honnêtement, cependant, cela semble un peu ridicule de demander à un architecte de réviser le code. Il devrait faire des revues de conception ou des revues occasionnelles de code de façon informelle pour partager son expertise. L'équipe d'ingénierie devrait prendre la responsabilité du code. S'il y a des problèmes, ils s'amélioreront avec le temps.

Je suis d'accord, si une seule personne fait des critiques, le reste des gars ira probablement avec "Je ne sais pas, cela semble fonctionner, mais laissez ce gars intelligent comprendre si c'est ok ou pas". Je peux penser à ce qui suit:

• rendre votre code public afin que tout le monde puisse voir sur quoi tout le monde travaille; mettre des noms au début de chaque fichier contenant du code; peut-être les imprimer et les tamponner dans, euh, la salle de bain ou partout où vous sentez que cela attirera l'attention
• programmation en binôme; avec un autre cerveau à côté de vous, vous y réfléchirez à deux fois avant de nommer votre variablei
• prenez votre concierge et expliquez-lui comment fonctionne cet héritage (oh, oui, ça ne marche pas). Expliquer votre code à quelqu'un d'autre aide. Peut-être qu'il compile, peut-être qu'il fait les bonnes choses, mais vous n'avez pas vraiment compris pourquoi. C'est maintenant votre chance
• avoir un ensemble de directives et obliger tout le monde à les suivre; quelle que soit la ligne directrice, c'est mieux que pas de ligne directrice