Le code passe-t-il en revue les bonnes pratiques?

Lorsque l'entreprise dans laquelle je travaille a embauché de nouveaux managers, ils nous ont proposé de consulter le code de quelqu'un à chaque réunion. Nous avons des réunions toutes les deux semaines, donc chaque fois qu'un des développeurs devait montrer son code sur le projecteur, et d'autres allaient en discuter.

Je pensais que ce serait génial: chaque développeur serait plus prudent lors de l'écriture de code et nous pourrions mieux partager notre expérience. Mais d'une manière ou d'une autre, nous avons oublié cela et l'offre est restée une offre.

Quels en sont les avantages et y a-t-il des inconvénients?

Les révisions de code sont une excellente pratique.

C'est probablement la meilleure façon d'apprendre des erreurs et de voir comment certains problèmes sont résolus par d'autres. C'est également l'un des meilleurs moyens de maintenir la qualité dans une base de code.

Les revues de code ont lieu dans de nombreuses entreprises, bien qu'il soit difficile de dire qu'il existe un processus spécifique qu'elles suivent toutes.

Dans le cadre d'une révision plus formelle du code, une personne âgée (ou plusieurs personnes âgées) s'assiéra avec un développeur pour revoir son code, proposer des suggestions et enseigner en même temps.

Les avantages supplémentaires des revues de code (comme commenté pour cette question) incluent:

• Une excellente façon d'enseigner et d'apprendre
• Ils sont l'un des meilleurs moyens d'améliorer et de conserver la cohérence d'une base de code (style et idiomes)
• Ils aident à s'assurer que tous les membres de l'équipe comprennent le style et les idiomes utilisés dans le projet et comment les utiliser.
• Les révisions de code accéléreront le développement car elles détectent rapidement les bogues et les défauts de conception (ainsi, bien qu'elles puissent ralentir le développement initial, elles rapportent des dividendes dans les cycles de développement ultérieurs)
• La prise en charge des outils permet de rationaliser le processus de révision du code

Les révisions de code sont un outil très utile pour l'apprentissage , surtout lorsque vous avez un nouveau membre d'équipe à bord. Eh bien, il est également connu sous le nom de processus d'examen par les pairs :)

Il existe différents types de revues de code:

• Au-dessus de l'épaule - où un développeur regarde par-dessus l'épaule de l'auteur du code pendant que ce dernier parcourt le code.
• Transmission des e- mails - Le système de gestion du code source envoie automatiquement le code par e -mail aux réviseurs une fois l'enregistrement effectué. Extrait du commentaire: Ayant échoué à convaincre la direction d'allouer du temps pour toute sorte de révision de code formelle, j'ai pris en charge les modifications de mes collègues chaque fois que je retirais de nouvelles révisions du contrôle de code source à l'aide des outils d'historique / diff intégrés à Tortise
• Programmation par paires - Deux auteurs développent du code ensemble sur le même poste de travail, tel est le cas dans la programmation extrême.
• Révision de code assistée par outils - Les auteurs et les réviseurs utilisent des outils spécialisés conçus pour la révision de code par les pairs.

Il n'y en a qu'un associated disadvantageoù les révisions de code formelles ont nécessité un investissement considérable dans la préparation de l'événement de révision et du temps d'exécution.

D'autres références sont répertoriées ci-dessous (pour des lectures plus approfondies)

• MSDN - Révision du code
• Recherchez et corrigez les vulnérabilités avant l'envoi de votre application
• Lien Wiki

Cette pratique particulière semble inefficace et susceptible d'être embarrassante - qui veut que ses erreurs soient signalées à tout un groupe de personnes. Donc, s'ils ne peuvent pas choisir ce qui doit être examiné et que le code n'est pas encore en production, cela risque de mettre les gens mal à l'aise.

Selon le moment où le code est révisé, cela peut faire une grande différence si les commentaires de révision du code le font ou non. Si le développeur peut choisir et choisir uniquement du code de production, il est peu probable que les commentaires de révision soient implémentés. C'est agréable d'avoir des réunions où les développeurs peuvent montrer une technique astucieuse dont ils ont appris que d'autres personnes seraient intéressées, mais ce n'est pas de la révision de code. C'est la formation.

Nous procédons à la révision du code de chaque morceau de code avant qu'il ne soit déplacé en QA. Chaque pièce. Il implique généralement uniquement le réviseur de code et le développeur. Il ne passe pas au contrôle qualité tant que le réviseur de code ne l'a pas officiellement transmis. Le développeur doit donc apporter les modifications. Nous avons trouvé et corrigé rapidement de nombreux problèmes que le contrôle qualité n'a peut-être pas trouvés (ils trouvent également des choses que nous ne voyons pas dans la révision du code). De plus, cela réduit le codage Cowboy et identifie rapidement les personnes qui ne fonctionnent pas bien afin que nous puissions résoudre leurs problèmes et les former ou les éliminer avant qu'elles n'endommagent notre application. Le temps de révision du code fait partie de notre estimation du temps lors de la planification des travaux afin qu'il n'ait aucun impact sur la date limite. Et en fait, cela fait gagner du temps à long terme, car plus un problème est détecté tôt, plus il est facile à résoudre.

Personnellement, j'ai enseigné aux développeurs moins expérimentés de bien meilleures techniques grâce à la révision de code et j'ai moi-même appris de meilleures techniques en examinant le code d'autres personnes ainsi que leurs commentaires sur mon code. Un examen plus approfondi du code garantit que quelqu'un d'autre comprend le code, ce qui contribue grandement à le rendre plus maintenable. Parfois, le code fonctionne, mais les questions de la révision indiquent clairement qu'il y aura des problèmes de maintenance car le code est difficile à comprendre. Mieux vaut refactoriser dans ces cas alors que tout est encore frais dans votre esprit qu'un an plus tard, même lorsque l'auteur du code se gratte la tête et se demande pourquoi le code fait tel ou tel.

Le problème avec ce type de révision de code, un développeur toutes les deux semaines, la progression sera lente. Il pourrait s'écouler des mois avant que tout le monde ne se retourne sous les projecteurs.

Bien que les révisions de code puissent être bonnes, il doit y avoir une raison derrière elles et derrière la procédure pour les faire.

Plusieurs questions devraient être tranchées:

• Qui choisirait le développeur et combien de temps leur serait-il donné? Aucun avis n'est un piège.
• Qui choisirait la partie du code en cours de révision: la direction, le développeur principal du projet ou le développeur en cours de révision.
• Est-ce le but d'apprendre à la personne dont le code est sur le projecteur comment faire quelque chose de mieux, ou est-ce le but pour la personne dont le code est sur le projecteur d'enseigner à tous les autres autour de la salle comment améliorer leur code.
• Quel pourcentage de code sera revu de cette façon, cela fera-t-il partie du processus d'AQ?

Si les personnes qui ont proposé ce plan n'ont pas déjà de réponses à ces questions, il est possible qu'elles lisent un article sur la façon dont toutes les grandes entreprises effectuent des revues de code, nous devons donc les faire également, sans comprendre le but derrière elles.

La révision de code est une excellente pratique, uniquement lorsque l'idée de révision de code vient de l'équipe de développement. Les développeurs n'ont pas besoin de projecteurs et de présentations pour se revoir mutuellement le code. S'ils le souhaitent, ils préféreront aller à la conférence.

Lorsque l'idée de révision de code vient de la direction - cela peut ressembler à une enquête sur la faible qualité du logiciel et peut démoraliser l'équipe de développement. Je ne pense pas que l'équipe de gestion devrait être impliquée dans le processus de révision du code. Examen du code côte à côte avec l'équipe de gestion - très mauvaise pratique meurtrière et destructrice.

La révision de code est une excellente pratique, en particulier si elle est effectuée par des développeurs pour partager des connaissances, et les règles de base sont définies à l'avance pour que les suggestions et les critiques soient censées être CONSTRUCTIVES et ne pas utiliser un développeur individuel pour la pratique cible.

Les gestionnaires qui ne sont pas des développeurs seront accueillis avec suspicion par les développeurs s'ils décident de faire des révisions de code. La plupart des types de gestionnaires ne voudront pas entrer dans les détails dans lesquels les développeurs entrent par nature lorsqu'ils regardent du code. La plupart des gestionnaires ne comprendront pas non plus pourquoi les développeurs critiquent une approche plutôt qu'une autre.

Si vous voulez montrer le bon travail que les développeurs font à la gestion, la «révision de code» a une signification différente et ne devrait pas être aussi détaillée que les révisions de code qui sont effectuées pour informer / améliorer la qualité du code parmi les développeurs. Ce type de présentation pourrait être utile pour démontrer ce que font les développeurs si la présentation peut être de niveau supérieur et moins spécifique au code, en se concentrant sur ce que les gestionnaires comprennent (valeur, retour sur investissement, etc.). Cela pourrait faire comprendre aux managers que Joe a ajouté une valeur significative à l'entreprise en construisant X, ce que nous pouvons montrer économise Y temps, ou Z dollars par commande, etc. Je pense que cela vaut la peine de montrer la valeur de l'individu les membres de votre équipe. N'oubliez pas, cependant, que vous devez faire attention à ne pas submerger votre public avec du jargon ou trop de niveaux de détail.

Bien que je convienne pleinement que les revues de code sont très constructives pour l'enseignement, je voudrais souligner, pour moi en tout cas, c'est pour s'assurer que les modèles de conception de l'équipe sont correctement suivis.

Nous écrivons un petit travail de prototype et nous refactorisons des morceaux de code et bien que nous nous sentions à l'aise avec le produit à la fin, la lisibilité a été endommagée - les gens ne peuvent pas le regarder et voir aussi clairement ce qui se passe.

Les yeux indépendants sont toujours bénéfiques, je trouve que vous êtes coincé dans certains modes de pensée et cela à tous les niveaux d'expérience. Vous avez investi des heures dans la conception et le code et les révisions de code sont donc difficiles à gérer lorsque vous craignez que vos efforts ne soient abandonnés. Pourtant, à la fin, vous vous retrouvez avec une application plus propre, plus légère et plus facile à gérer et l'expérience est enracinée en vous.

Pour notre équipe, nous faisons comme @ElYusubov l'a mentionné et utilisons un outil spécifiquement pour la révision du code - Crucible. Les gens examinent, commentent et signent le code. Chaque semaine, nous nous asseyons et passons en revue des morceaux de code intéressants et / ou complexes.

En tant que stagiaire en génie logiciel, j'ai trouvé les revues de code extrêmement utiles.

Au sein de mon équipe, une révision du code est requise pour chaque commit (les gros changements finissent par être formels, les petits changements finissent par être «rapides»). J'ai vraiment l'impression que mes côtelettes d'ingénierie / conception ont été stimulées par cela, d'autant plus que je suis plus susceptible de retirer le tableau blanc que le terminal tout de suite, car je sais que je suis `` surveillé ''. :)

En effet, je pense qu'il produit un code bien meilleur avec le seul léger inconvénient étant un temps de développement légèrement plus lent (ce qui, à mon avis, en vaut la peine à long terme lorsque vous n'avez pas à corriger / étendre du code terriblement conçu). De plus, je pense que si vous avez des juniors / stagiaires dans l'équipe, ils apprécieront la chance d'avoir de précieux commentaires. Je sais que je fais!

D'après mon expérience, la révision de code est vraiment une bonne chose si vous la réalisez bien. Lorsque vous avez des membres et des managers professionnels / matures. En tant que programmeurs, nous sommes des "résolveurs de solutions". Notre travail n'est pas de créer des lignes de "texte". C'est pourquoi nous devons partager des idées, des erreurs, des problèmes, des expériences. La révision du code est vraiment une bonne pratique pour y parvenir.

Malheureusement, cela semble génial, mais il est vraiment difficile à mettre en œuvre dans la plupart des entreprises. Votre équipe a besoin de beaucoup "d'autonomie". Convaincre vos managers ou votre service financier que ne pas créer de nouvelle fonctionnalité est rentable semble difficile.

Dans mon entreprise, nous essayons de faire un examen du code. Mais trop de temps est consacré à «chasser le lapin» (création de fonctionnalités).

La plupart des vérifications de style et de type de syntaxe de base sont détectées à l'aide d'outils de nos jours (FXCop, etc.).

Cependant, les revues de code sont bonnes, en particulier avec les nouveaux membres d'une équipe, des choses complexes ou à fort impact (par exemple, quelque chose qui sera perceptible par des personnes importantes s'il échoue ou a un impact commercial) et surtout lors de l'externalisation ou du recours à des entrepreneurs à court terme (surtout à nouveau quand ils ne sont pas natifs, les erreurs de traduction / problèmes de langue peuvent permettre au logiciel de passer tous les tests mais de ne pas faire ce qu'il est censé faire).

Je ne suis pas un fan de mettre du code sur un projecteur pour une équipe à choisir - beaucoup mieux d'avoir une réunion de révision de code où un autre membre de l'équipe (chef d'équipe, etc.) passe par une liste avec le développeur. Cela affecte moins de personnes - arrête beaucoup de temps perdu sur les arguments de style - et est moins gênant pour le développeur. Il est plus constructif et plus facile pour le développeur d'absorber les vrais problèmes et de ne pas être aveuglé par des commentaires "j'aurais fait ça ...".

Je pense également que les révisions de code non appliquées - comme mettre du code sur un partage ou l'envoyer par courrier électronique dans l'espoir que quelqu'un abandonne son déjeuner pour le parcourir - est une perte de temps.

Un asseoir avec une pile de listes, un marqueur et une tasse de café dans la zone de café est idéal pour cela.

Ce genre de show et de dire de groupe serait bon pour les nouvelles technologies ou pour obtenir plusieurs jr. devs up to speed, mais je ne pense pas que ce soit aussi bon qu'un examen cohérent du nouveau code. Il est plus efficace de devoir le faire individuellement.

La révision du code permet de voir "l'ensemble". Les développeurs séparés ont tendance à ne voir que leurs besoins / problèmes. CR découvre des idées et des solutions dans toute la perspective. CR aide principalement à éliminer le gaspillage de travail inutile. L'ensemble du produit est moins cher et de meilleure qualité.