Revues de code, quels sont les avantages? [fermé]

Dans mon équipe, nous ne faisons pas de revues de code formelles. Nous avons tendance à penser que cela suffit souvent avec la programmation par paires et la rotation des paires.

Devrions-nous envisager de faire des revues de code formelles? Quels en seraient les avantages?

Nous faisons des revues de code un peu différentes (peut-être).

Nous réunissons tous les programmeurs ensemble (tous les vendredis) et regardons ce que nous avons fait en une semaine. Ensuite, nous avons choisi les projets que nous voulons examiner afin que chaque projet terminé / en cours ait au moins une ou quelques personnes. Ensuite, en une heure environ, nous examinons les changements qui ont été apportés, recherchons les erreurs, comment fonctionnent les autres projets, etc. et spammer le code avec FIXME). Dans l'ensemble, cela prend habituellement environ 2 heures pour nous (10 programmeurs).

Les avantages:

• Chaque membre sait ce qui se passe dans l'entreprise
• Les bogues sont détectés plus rapidement
• Cela nous oblige à écrire du code lisible (code qui peut être lu sans explication ni introduction!)
• Les méthodes / astuces / programmes productifs d'optimisation se propagent plus rapidement
• Le programmeur en tant que spécialiste "évolue" plus rapidement
• C'est marrant

Ce que j'ai contre la programmation par paires, comme mentionné (bien sûr, ce n'est que mon opinion personnelle), c'est que plus l'équipe travaille longtemps - plus vite cela devient.

J'espère que cela apportera matière à réflexion. Bonne chance.

Vous voudrez peut-être lire ce livre gratuit:

http://smartbear.com/best-kept-secrets-of-peer-code-review/

Bien sûr, ils ont un produit à pousser, mais il y a encore beaucoup d'informations utiles.

Ils expliquent également comment la programmation par paires offre certains des mêmes avantages, donc si vous êtes en programmation par paires, vous n'aurez peut-être pas besoin du tout de revoir le code.

Je n'ai pas beaucoup d'expérience en révision dans votre environnement. Nous ne faisons pas beaucoup de programmation par paires ici, nous faisons des révisions de code pour diffuser les connaissances du logiciel dans l'équipe, avons une autre paire d'yeux pour détecter les erreurs et avons un point formel pour vérifier si le logiciel respecte nos directives de codage .

Les 2 premiers points sont assez bien couverts par la programmation de la paire, le troisième est très dépendant de la paire et pourrait s'améliorer grâce à une révision formelle du code.

Devez-vous faire des revues de code formelles?

Absolument

Juste une petite note, j'ai très peu d'expérience avec la programmation en binôme, mais je ne pense pas que les critiques entreraient en conflit avec ces méthodes.

J'introduirais deux formes de revues de code:

Revues de code par les pairs

Même si la programmation en binôme fonctionne pour vous, cela ne fait jamais de mal d'avoir un autre regard sur le code. Les avantages à cela sont:

1. Cela permet de jeter un regard neuf sur le code, quelqu'un qui peut avoir une connaissance plus intime des zones de la base de code que vous (et / ou votre partenaire) ne connaissez peut-être pas aussi bien. Cela peut exposer des problèmes d'entraînement.
2. Cela vous fait (la paire) revalider votre solution avant la soumission. Comme le réviseur ne sait rien de ce que vous avez écrit, vous devez l'expliquer dans son intégralité. Cela peut exposer des cas marginaux auxquels vous n'aviez pas pensé ou une logique invalide.

Des examens de code par les pairs (dans mon monde) sont effectués avant chaque soumission. Comment cela se poursuit dans le monde de la programmation par paires, je n'en suis pas sûr.

Revues de code de groupe

Ceux-ci se produisent moins fréquemment que les revues de code par les pairs. Je tirais généralement mon groupe (ou une sous-section de mon groupe) dans une salle de réunion pour un examen informel du code. Je choisirais généralement du code qui a été écrit par une personne aléatoire de l'équipe, de préférence du code qui a été écrit à partir de zéro - le code refactorisé n'expose pas des problèmes comme le nouveau code.

Assurez-vous que tout le monde sait que ces avis ne sont pas destinés à la braise et ne sont pas utilisés pour refléter les performances. Ils visent simplement à garantir le respect des normes de codage de votre équipe et à aider tout le monde à devenir de meilleurs ingénieurs et, ainsi, à devenir plus utiles à l'équipe (et à la poursuite de la croissance de carrière, etc.) - et à vous assurer que c'est la véritable intention des examens. . Si quelqu'un soupçonne quelque chose de différent, ceux-ci deviendront redoutés et moins productifs.

Je passerais en revue le code de manière quelque peu informelle, laissant quiconque dans la salle indiquer les différentes solutions qu'il pourrait avoir ou les défauts de logique qu'il rencontrait. Ceci est censé être plus une discussion de groupe qu'un leader assis là disant à tout le monde comment ils devraient coder.

J'ai constaté que l'utilisation de ces deux méthodes augmente la vitesse à laquelle les ingénieurs progressent ainsi que le nombre de bogues considérablement :)

Je n'ai jamais fait de programmation par paires dans la pratique (je l'espérais seulement), donc je ne peux pas comparer directement les deux pratiques. Cependant, je peux raconter mes expériences avec des revues de code formelles.

J'avais l'habitude de diriger des revues de code formelles dans un projet précédent, sur le code hérité. Le projet était dans un désordre complet et la direction a accueilli toute initiative dans l'espoir de mettre de l'ordre dans le chaos. À cette époque, je pensais que la révision formelle du code était une bonne idée. Nous avons trouvé des bogues et nous avons constaté que la qualité du code fraîchement écrit était bien meilleure que celle de l'ancien code. J'ai collecté des statistiques, le nombre de bogues, etc. pour le prouver.

Nous avons fait une session par semaine en moyenne, impliquant 3-5 personnes. Chaque session a duré environ 3 à 4 heures par personne (préparation comprise) et a examiné 200 à 300 lignes de code (LOC) *. À ce rythme, pendant une période de plus de 6 mois, nous avons réussi à revoir environ 5K LOC, sur environ 50K.

Rétrospectivement, je pense que c'était très coûteux. Avec ce rythme, il nous aurait fallu 5 ans pour revoir l'intégralité de la base de code héritée. OTOH ayant plus d'une session par semaine aurait enlevé des ressources au développement. Bien sûr, c'est le dilemme typique avec le code hérité. Mais même l'examen formel de tout le code fraîchement écrit prendrait beaucoup de temps, ralentissant considérablement le développement.

Ma conclusion est que les revues de code formelles sont mieux faites sur du code nouvellement écrit, concentré sur les parties les plus critiques du code. Le reste est mieux géré de manière plus informelle, éventuellement via la programmation par paires. Ce n'est que mon opinion actuelle, qui pourrait changer. Je ne prétends pas être un gourou de la révision de code ou quoi que ce soit.

* Il s'agit du rythme normal des révisions de code formelles.

Les taux de révision de code typiques sont d'environ 150 lignes de code par heure. L'inspection et l'examen de plus de quelques centaines de lignes de code par heure pour les logiciels critiques (tels que les logiciels embarqués critiques pour la sécurité) peuvent être trop rapides pour trouver des erreurs.

Cité sur Wikipedia (souligné par moi).

La raison sous-jacente des revues de code existe parce que les programmeurs isolés doivent se rencontrer et discuter de leur code et vérifier qu'il est conforme à leur norme.

Vous ne mentionnez aucun problème de qualité, il semble donc que votre équipe effectue déjà suffisamment de révisions de code via la programmation de leur paire. Impressionnant!

Une programmation de paires correctement effectuée rend les revues de code formelles superflues. Mais essayez-le pendant quelques semaines et voyez comment cela fonctionne, mais je pense que vous ne remarquerez aucune amélioration.

Gardez à l'esprit que les révisions de code sont un processus fatigant et coûteux et non quelque chose à prendre à la légère. Il introduit essentiellement un transfert dans votre projet qui est coûteux et ralentit tout . Il est préférable de s'assurer que le code est correct en premier lieu, plutôt que d'essayer de trouver des problèmes plus tard.

Peut être. Les révisions de code prennent du temps. Ils ne valent que si le temps pris par l'examen est enregistré à un autre moment du processus. Quelles économies attendez-vous des revues de code? Vous rencontrez des difficultés qui pourraient être évitées par des révisions de code?

Si vous faites de la programmation par paires, la nécessité d'une révision de code diminue considérablement, mais vous bénéficierez certainement d'une révision par les pairs. Pour que cela soit bénéfique, cela doit être fait par une personne âgée et plus expérimentée que les membres de la paire.

Quels sont les bénéfices? Eh bien, ce serait mieux si vous considérez les risques de ne pas le faire.

• La paire pourrait faire quelque chose de mal ou peut-être le faire de manière sous-optimale
• Peut-être que vous ne suivez pas les normes de codage ou ne documentez pas le code correctement. Un examen par les pairs est vraiment bon pour trouver ces
• Personne d'autre que la paire ne comprend un morceau de code particulier. Alors, que se passe-t-il si les deux membres de la paire sont partis et que le code est mal documenté? D'autres perdront du temps à essayer de comprendre les choses. Le fait d'avoir une troisième personne qui sait ce que vous avez fait réduit le risque.

Je suis amusé que les gens aient dit que la révision du code est une perte de temps. Oui, cela prend du temps. Peut-être que cela ne produira aucun changement dans le code, mais cela ne signifie pas qu'il est gaspillé. C'est comme dire que vous n'avez pas besoin de vérifier régulièrement votre système d'incendie car c'est une perte de temps.

Pour moi, le principal avantage des revues de code est qu'elles permettent aux gens d'écrire un meilleur code.

Le fait de savoir que votre code sera lu et révisé vous rend plus conscient de la lisibilité et de la «bonne» nécessité de votre code. Lorsque vous savez que le code va directement dans le référentiel et que personne d'autre ne le lira à moins qu'il ne corrige les défauts, vous avez tendance à laisser les choses glisser comme ne pas refactoriser les noms de champ lorsque leur utilisation change, laissant les méthodes inutilisées traîner au cas où elles pourraient être pris en compte, etc., etc.