Quel est le moyen le plus efficace de réviser le code? [fermé]

Je n'ai jamais trouvé le moyen idéal d'effectuer des révisions de code et pourtant, souvent, mes clients en ont besoin. Chaque client semble les faire de manière différente et je ne me suis jamais senti satisfait d'aucun d'entre eux.

Quel a été le moyen le plus efficace pour vous de réviser le code?

Par exemple:

• Une personne est-elle considérée comme le gardien de la qualité et vérifie-t-elle le code, ou l’équipe est-elle propriétaire de la norme?
• Examinez-vous le code en tant qu’exercice d’équipe en utilisant un projecteur?
• Est-ce fait en personne, par courrier électronique ou à l'aide d'un outil?
• Est-ce que vous évitez les critiques et utilisez des éléments tels que la programmation en binôme et la propriété collective de code pour assurer la qualité du code?

Dans mon travail, nous appliquons une règle très simple: les modifications doivent être examinées par au moins un autre développeur avant une fusion ou une validation dans le coffre . Dans notre cas, cela signifie que l’autre personne vous trouve physiquement à votre ordinateur et parcourt la liste des modifications. Ce n'est pas un système parfait, mais il a néanmoins sensiblement amélioré la qualité du code.

Si vous savez que votre code va être révisé, vous devez l'examiner en premier. De nombreux problèmes deviennent alors apparents. Dans notre système, vous devez expliquer ce que vous avez fait à l'examinateur, ce qui vous fait à nouveau remarquer des problèmes que vous avez peut-être manqués auparavant. De plus, si quelque chose dans votre code n'est pas immédiatement clair pour le relecteur, c'est une bonne indication qu'un meilleur nom, un commentaire ou une refactorisation est nécessaire. Et, bien sûr, le critique peut également rencontrer des problèmes. En outre, en plus d'examiner le changement, le relecteur peut également remarquer des problèmes dans le code à proximité.

Ce système présente deux inconvénients principaux. Lorsque le changement est trivial, il n’a pas de sens de le revoir. Cependant, nous devons absolument nous en tenir aux règles, pour éviter la pente glissante de déclarer des modifications «triviales» quand elles ne le sont pas. D'un autre côté, ce n'est pas un très bon moyen de passer en revue les modifications importantes apportées au système ou l'ajout de nouveaux composants volumineux.

Nous avions déjà essayé des revues plus formelles, lorsqu'un développeur envoyait par courrier électronique le code à réviser au reste de l'équipe, puis toute l'équipe se réunissait pour en discuter. Cela a pris beaucoup de temps à tout le monde et, par conséquent, ces examens étaient peu nombreux, et seul un faible pourcentage de la base de code a été examiné. Le message "une autre personne examine les modifications avant la validation" a beaucoup mieux fonctionné pour nous.

J'aime les critiques de code, même si elles peuvent être pénibles. La raison pour laquelle je les aime, c'est qu'ils ont plus d'attention pour le code et une perspective différente. Je crois que même avec la programmation par paires, le code devrait être revu. Il est assez facile pour deux personnes travaillant sur le même code de commettre collectivement la même erreur qu'un regard différent pourrait ne pas manquer.

Si cela est fait en groupe avec un projecteur, cela devrait vraiment être examiné individuellement avant la réunion. Sinon, c'est juste une perte de temps agaçante.

J'ai seulement passé en revue les codes par e-mail et en groupe. De manière générale, je ne pense pas que cela devrait être fait en personne. Vous sentez un peu plus de pression pour passer à travers le code avec quelqu'un qui regarde par-dessus votre épaule. Je pense qu'un outil conçu pour la révision du code serait un bon atout, car il peut aider à résoudre certains aspects banals et devrait permettre de signaler plus facilement les éléments de code qui posent problème par la suite, par courrier électronique.

Le problème avec une seule personne qui effectue toutes les révisions de code est que cela peut être un goulot d'étranglement. Avec des normes de codage bien documentées et bien conçues, cela ne devrait pas être nécessaire. En fonction de l'environnement / du calendrier de publication, il peut être judicieux de toujours avoir quelqu'un comme réviseur de code de secours.

Je pense que la possession de code est une bonne idée car cette personne peut se donner pour priorité de comprendre ce code et de jouer potentiellement un rôle de contrôleur.

Chez SmartBear, nous fabriquons non seulement un outil de révision de code , mais nous l'utilisons également au quotidien. C'est une partie essentielle de notre processus de développement. Nous passons en revue chaque changement enregistré.

Je pense que c'est une mauvaise idée d'avoir un seul réviseur de code de contrôleur d'accès pour plusieurs raisons. Cette personne devient un goulot d'étranglement et elle doit faire trop de révision de code (pour que le projet continue d'avancer) pour être vraiment efficace (60 à 90 minutes à la fois est la limite d'efficacité). Les revues de code sont un excellent moyen de partager des idées et des connaissances. Peu importe à quel point votre gardien est une superstar, ils peuvent apprendre des autres membres de l'équipe. De plus, le fait que tout le monde passe en revue le code crée également un environnement de "propriété collective de code", dans lequel les gens ont l'impression de posséder la qualité du code (il ne s'agit pas uniquement du contrôle qualité ou du gardien).

Nous avons un livre blanc gratuit intitulé « Meilleures pratiques pour la révision de code par les pairs », qui contient 11 astuces pour rendre les révisions de code efficaces. Une grande partie de ceci est le même contenu du livre que John a mentionné sous une forme plus distillée.

Pas d'excuses. Pratiquez la programmation en binôme. C'est la meilleure révision de code possible. Tout autre mécanisme aboutit à un jeu de reproches. La programmation en binôme induit l'esprit d'équipe et la propriété collective. De plus, vous débattez de vos idées avec votre paire, échouez vite, prenez des mesures correctives et seul le code codé et révisé de la paire est validé dans le système de gestion de la configuration (CMS). Bonne programmation en binôme!

Si vous travaillez sur un projet où plusieurs personnes vont contribuer à la base de code, une norme doit être établie.

À ce stade, selon mon expérience, il est préférable de désigner une personne comme le "roi" de la révision de code si vous le souhaitez et ce qu’il dit va. À cet égard, si un utilisateur ne respecte pas les normes, le roi s'en occupera.

En tant que développeur moi-même, j'examine mon code plusieurs fois pour qu'il soit lisible, raisonnable et tout le reste. Nous utilisons généralement javadoc ou similaire dans des langages donnés avec lesquels nous codons et utilisons la balise @author pour attribuer la propriété des fonctions, des classes, etc.

Si une fonction n'est pas correcte, nous discutons avec le propriétaire, idem avec la classe, etc.

Dans mon entreprise, chaque tâche est affectée à un testeur pour la tester et à un réviseur de code pour réviser le code.

Si votre produit est déjà commercialisé et que vous souhaitez vous assurer que vous ne faites rien de mal (par exemple, une fuite de poignée ou une fuite de mémoire), les révisions de code sont une excellente chose. Je pense que lors du développement initial avant la sortie de votre produit, la révision du code peut s’avérer trop compliquée.

Si votre équipe compte tous des développeurs expérimentés, la révision par des pairs reste utile. Tout le monde fait des erreurs parfois. Si votre équipe compte des seniors et des juniors, laissez les développeurs seniors effectuer les révisions de code, mais faites-le également pour le code des seniors.

Une chose importante à propos de la révision de code est qu’elle peut intercepter les erreurs que nous faisons, mais qu’elle ne remplace pas les tests.

Je recommande d'utiliser des critiques de code si vous ne faites pas de programmation en binôme.

Sans contester les avantages et les inconvénients du couplage, il est difficile de contester les effets positifs de la révision constante de votre code par (au moins) une autre personne. Le code est même écrit et conçu par (au moins) deux programmeurs - il ne peut guère être meilleur que cela. Je dis "au moins" parce que, imo, vous devriez essayer de changer beaucoup de paires afin que tout le monde ait le temps de travailler avec le code.

Une des choses que j'essaie de faire dans les revues de code auxquelles je participe est après avoir revu le code moi-même, je fais une analyse statique du code, en utilisant des outils tels que Findbugs, PMD, JavaNCCP et autres, et examine les problèmes que ces outils trouvent dans le code à revoir. Je souhaite en particulier examiner tout ce qui présente un niveau de complexité inhabituellement élevé, en leur demandant d'expliquer pourquoi ce niveau de complexité est nécessaire ou pourquoi la vulnérabilité suggérée n'est pas importante.

YMMV

Où je travaille actuellement, nous produisons des périphériques matériels et les logiciels avec lesquels ils interagissent, qui vont dans l'infrastructure critique. Par conséquent, nous accordons une très grande importance à la qualité des versions. Nous utilisons une variante de l' inspection Fagan et avons un processus de révision formel. Nous sommes certifiés ISO 9001, entre autres certifications.

Le secteur des infrastructures critiques est très intéressé par la fiabilité et la répétabilité des mêmes. :-)

Dans mon entreprise, nous avons des révisions de code obligatoires pour les programmeurs débutants et des révisions volontaires pour les aînés. Il n'y a pas de réviseur de code désigné, les demandes de révision sont envoyées à tous les développeurs.

Ce système fonctionne bien - les révisions sont effectuées dans les limites du temps imparti et les modifications peuvent être examinées par plusieurs ensembles de yeux.

L’excellent outil gratuit de conseil d’examen fonctionne très bien pour nous et s’est révélé être un excellent moyen de communiquer des avis.

Dans mon entreprise, nous n'effectuons jamais de vérification formelle du code avant les enregistrements, sauf si nous modifions une production extrêmement critique et si nous n'avons pas le temps d'effectuer notre processus d'assurance qualité standard.

Ce que nous faisons, c'est que chaque fois que nous pensons qu'une révision de code serait utile, nous ajoutons un commentaire "// todo: code review by joe" au code modifié. Habituellement, nous sélectionnons Joe car il possède le code modifié, mais si ce critère de sélection ne s'applique pas (généralement, il le fait), nous choisissons simplement quelqu'un d'autre de manière aléatoire. Et bien sûr, si Joe est disponible à ce moment-là, nous utilisons la bonne vieille méthode de révision par-dessus l'épaule.

En tant que réviseur, la seule chose à faire est de rechercher périodiquement le code entier "// todo: révision de code par moi" , de réviser les modifications et de réintégrer le code sans le commentaire "todo ..."

En cas de problème, nous revenons aux méthodes de communication traditionnelles (mail / chat / etc.).

Cette méthode nous fournit les deux qualités principales que nous recherchons dans un système de révision:

• frais généraux très légers
• traçabilité

Nous trouvons que le moyen le plus efficace de procéder à la révision de code est un sur un en utilisant github pour montrer les différences entre les branches.

• Une personne est-elle considérée comme le gardien de la qualité et vérifie-t-elle le code, ou l’équipe est-elle propriétaire de la norme?

  • Dépend de la taille de l'équipe - une équipe de 3 personnes aura un senior qui aura la meilleure connaissance des bonnes pratiques, alors qu'une équipe de 12 personnes pourra compter 3 ou 4 personnes pour remplir ce rôle.

• Examinez-vous le code en tant qu’exercice d’équipe en utilisant un projecteur?

  • En personne. 1 sur 1 pour être moins menaçant. Parfois fait dans la zone communale bien que la connaissance se répande. Dépend de la situation exacte, des personnes, du calendrier, etc.

• Est-ce fait en personne, par courrier électronique ou à l'aide d'un outil?

  • En personne. Nous utilisons git et github et il dispose d'excellents outils de révision du code et de comparaison des différences pour faciliter la révision du code.

• Est-ce que vous évitez les critiques et utilisez des éléments tels que la programmation en binôme et la propriété collective de code pour assurer la qualité du code?

  • Nous essayons de faire les deux comme il convient. Cela signifie que lorsque vous êtes coincé dans un problème particulièrement épineux, lorsque vous travaillez sur une infrastructure principale, lorsque vous vous préparez pour les vacances ou quittez l'entreprise, un jumelage peut être fait pour partager et transférer des connaissances. La plupart des codes ou des codes comportant des modifications superficielles doivent également être examinés à la fin.

Comme pour tous les éléments de codage, la bonne réponse doit prendre en compte:

• Type d'entreprise (par exemple, démarrage ou grande entreprise)
• Taille de l'entreprise
• Nombre de développeurs
• Budget
• Plage de temps
• Charge de travail
• Complexité du code
• Capacité de critique (s)
• Disponibilité du (des) critique (s)

J'ai travaillé dans de nombreuses entreprises et constaté de nombreux processus. Mon équipe actuelle gère cela du mieux que j'ai vu jusqu'à présent.

Nous utilisons un processus de développement agile et, dans ce cadre, nous avons des portes que chaque histoire doit traverser. L'une de ces portes est la révision du code. L'histoire n'est pas testée tant que l'examen du code n'est pas terminé.

De plus, nous stockons notre code sur github.com. Ainsi, lorsqu'un développeur a terminé sa modification, il publie le lien vers la ou les commissions de l'histoire.

Ensuite, nous identifions un collègue développeur. Github a un système de commentaires qui permet à quelqu'un de commenter directement sur la ligne de code en question. Github envoie ensuite un e-mail à la distribution, de sorte que nous avons parfois des yeux supplémentaires de certaines de nos autres équipes.

Ce processus a très bien fonctionné pour nous. Nous utilisons un outil de processus agile qui facilite l’enregistrement des commits et facilite la communication.

Si un problème est particulièrement délicat, nous allons nous asseoir et en discuter. Cela fonctionne parce que cela fait partie intégrante de notre processus et que tout le monde a souscrit au processus. Nous pouvons ramener les tickets en cours si la révision du code donne lieu à une retouche nécessaire. Elle peut ensuite être révisée une fois les modifications apportées ou le relecteur peut noter dans l'article que la correction des éléments est suffisante et qu'il n'est pas nécessaire de l'examiner à nouveau.

Si les tests renvoient quelque chose en arrière, ils reviennent en cours et toutes les modifications ultérieures sont également examinées.