Comment incitez-vous les gens à accepter la révision de code?
Tous les programmeurs ont leur style de programmation. Mais certains styles sont disons ... disons pas. Vous avez donc une révision du code pour essayer d'imposer certaines règles pour une bonne conception et de bonnes techniques de programmation.
Mais la plupart des programmeurs n'aiment pas la révision de code. Ils n'aiment pas que d'autres personnes critiquent leur travail.
Qui pensent-ils qu'ils se considèrent mieux que moi et me disent que c'est une mauvaise conception, cela pourrait être fait d'une autre manière. Cela fonctionne bien? Quel est le problème? C'est quelque chose qu'ils pourraient dire (ou penser mais pas dire ce qui est tout aussi mauvais sinon pire).
Alors, comment faites-vous pour que les gens acceptent la révision du code sans déclencher une guerre?
Comment pouvez-vous les convaincre que c'est une bonne chose; cela ne fera qu'améliorer leurs compétences en programmation et évitera beaucoup de travail plus tard pour réparer et patcher un million de fois une chose qui hé ... "ça marche"?
Les gens vous diront comment effectuer une revue de code (programmation par les pairs, inspections formelles, etc.) ce qu'il faut rechercher dans une revue de code, des études ont été faites pour montrer le nombre de défauts qui peuvent être découverts avant que le logiciel ne frappe la production, etc. Mais comment convainquez-vous les programmeurs d'accepter une révision de code?
J'ai trouvé que les gens qui n'aiment pas les revues de code feront de leur mieux pour contourner tout ce que vous mettez en place.
La meilleure façon de vous assurer que le code avec lequel vous travaillez est correctement revu est de travailler quelque part qui traite cela comme la manière normale de coder, et qui n'embauche que des développeurs susceptibles de bien s'intégrer dans cet environnement.
Si vous ne pouvez pas changer avec qui vous travaillez, vous pourriez réussir si vous donnez d'abord votre propre code pour révision. Encouragez-les à trouver des défauts (oserais-je suggérer d'ajouter quelques erreurs délibérées?) Afin que vous puissiez démontrer que c'est pas censé être un moyen de critiquer le développeur en question. C'est le principal problème, OMI: les gens prennent les revues de code trop personnellement.
Simple: attribuez les projets importants aux programmeurs qui acceptent les revues de code. C'est un message clair: ce projet est trop important pour être laissé aux amateurs.
Les programmeurs qui ne coopèrent pas peuvent effectuer des travaux de maintenance. Votre entreprise en aura beaucoup si les revues de code n'étaient pas largement effectuées. Expliquez clairement qu'il s'agit d'une rue sans issue. Ces produits perdront de leur importance, seront supprimés ou remplacés par de nouveaux produits dont le code a été révisé.
Précisez lors de l'embauche que les revues de code sont la norme dans votre entreprise. Attribuez les nouveaux employés qui acceptent les révisions de code aux nouveaux projets.
Dans l'ensemble, cela indiquera à vos développeurs que l'entreprise adopte des revues de code. Ils peuvent choisir: partir ou sortir. Il n'y a pas d'avenir dans une entreprise pour les gens qui combattent l'entreprise.
Eh bien, vous ne pouvez pas vraiment, si quelqu'un refuse catégoriquement et que vous n'êtes pas son patron.
Mais la principale raison d'adopter un autre style est ...
Cohérence
Je pense que, quel que soit le style fou, il doit être cohérent. Donc, si un projet est construit dans ce style, il doit généralement rester dans ce style, sauf s'il existe une raison exceptionnellement convaincante de le modifier. Donc, si leur style ne correspond pas; c'est un fait qu'il devrait être fait pour correspondre. Pas de question ici.
Il y a d'autres problèmes qui peuvent être notés qui sont tout simplement faux. Sécurité, "erreur générale", etc. Ceux-ci sont incontestables et doivent être modifiés.
Si quelqu'un refuse de reconnaître quelque chose comme une mauvaise conception, une fois que vous lui avez montré la bonne façon et lui avez montré tous les risques et problèmes avec ce qu'il fait, je pense que vous devez alors décider par vous-même comment agir. Mais vous espérez que vous ne travaillez pas avec des gens si déraisonnables.
Je suis programmeur et j'aime les revues de code. La clé de bonnes revues de code dans mon expérience est d'améliorer le code.
Quand je fais une revue de code avec un collègue et qu'il/elle souligne des améliorations potentielles ou des bugs cachés, je suis heureux. Le code s'améliore et nous devenons probablement tous les deux un peu plus intelligents. Pourquoi ne voudrais-je pas ça?
Malheureusement, certaines personnes voient les revues de code comme un moyen de souligner le fait que votre code doit avoir 4 indentations d'espace au lieu de 3 indentations d'espace ou d'autres détails non vitaux.
Assurez-vous que les personnes qui effectuent des révisions de code peuvent et fourniront des informations utiles. Si les seules révisions de code d'entrée fournissent quelque chose qui peut facilement être accompli en utilisant un outil, alors les révisions de code sont une perte de temps.
Assurez-vous que les révisions de code ne sont pas une perte de temps, et la plupart des développeurs les apprécieront.
Quand je gère un projet, si je dis que nous allons faire des revues de code, nous allons faire des revues de code. Je fournirai bien sûr de bonnes raisons de les faire, mais au bout du compte, c'est ma responsabilité et ma décision de les mettre en œuvre.
Et si les programmeurs ne l'aiment pas, ils peuvent trouver un autre emploi. La plupart des projets qui échouent peuvent être utilement améliorés en se débarrassant de la moitié des développeurs de toute façon, et d'après mon expérience, ce sont les développeurs les plus pauvres qui s'opposent le plus aux révisions de code.
La seule raison pour laquelle j'ai adhéré au processus de révision du code, c'est qu'il y a un an environ, la personne qui a essayé de les imposer a retiré la carte de supériorité et nous a fait réviser le code de l'autre pour un projet donné. À la fin de ce projet, je pouvais voir l'énorme avantage et j'essaie maintenant d'instaurer des revues de code sur mes projets.
"Ça marche" ne suffit pas. Le code est écrit non seulement pour les machines à exécuter, mais aussi pour les personnes à lire, à adapter et à améliorer. Si les gens ne peuvent pas trouver leur chemin dans le code, ils ne peuvent pas faire toutes ces tâches qui font partie intégrante de la programmation.
Si Joe Programmer dit: "Ne regardez pas mon code, je suis la seule personne qui a besoin de le comprendre" j'en doute. Ce n'est que dans de rares cas que le code est touché par une seule personne. Et même si c'est le cas: Joe comprend-il son propre code la semaine prochaine, le mois prochain, l'année prochaine? Probablement pas.
Dans presque tous les établissements commerciaux (et la plupart des établissements non commerciaux, venez à cela) les programmeurs ne possèdent pas le code qu'ils écrivent, leur employeur le fait.
Dans presque tous les établissements commerciaux (et la plupart des établissements non commerciaux, venez à cela) la plupart des programmeurs semblent penser qu'ils faites possèdent le code qu'ils écrivent.
Cela provoque énormément de problèmes avec l'acceptation de la révision du code comme technique d'amélioration de la conception ...
Les moyens de réduire la résistance peuvent inclure:
- introduction programmation par paire : aucun code n'est écrit à moins que deux programmeurs ne le regardent. Révision instantanée du code en temps réel. Assurez-vous que les paires changent régulièrement.
- trouver un moyen "d'anonymiser" les revues de code, afin qu'il ne puisse pas être personnel
- examen en petits morceaux, afin que personne ne soit confronté à de longues listes d'améliorations
- n'autorisez aucun code à être archivé tant qu'il n'a pas été examiné (et que les points d'action n'ont pas été mis en œuvre et examinés)
- introduire une composante discrétionnaire à payer, en fonction de l'acceptation des revues de code
Je ne recommande aucun (enfin, peut-être le premier) de ce qui précède spécifiquement.
Ce qui importe, c'est d'avoir une vraie compréhension de ce que sont les - réels objections aux critiques, pas ce que vous entendez à la surface. Peut-être appliquer 5 pourquoi pour approfondir?
Je n'aime pas la révision de code lorsque je suis développeur.
Mais je veux vraiment revoir le code si je suis un leader. Nous savons pourquoi.
Cependant, certains développeurs n'aimeront certainement pas la révision de code, tout comme moi.
Que diriez-vous de tring anonyme revue de code?
Nous pouvons écrire des exemples de morceaux de code ou des conseils après examen du code pour trouver la meilleure façon.
Un exemple simple:
pièce originale:
s=objGotFromSomewhere.doSomething()
meilleure pièce:
if(objGotFromSomewhere!=null){
s=objGotFromSomewhere.doSomething()
}
mémo:
Dans certains projets, nous avons eu ... problème, causé par .. raison
conseils:
vérifiez toujours ...
Nous pouvons mettre cela sur wiki ou quelque part, puis en parler lors de la réunion hebdomadaire de l'équipe. Tech Leader le fera et encouragera les développeurs seniors et tous les membres de l'équipe à le faire également.
Je pense que anonyme est important, cela signifie que personne ne sait qui a généré le mauvais code.
Les gens peuvent ne pas aimer la révision du code, mais aimeront savoir quelle est la meilleure façon.
J'ai fait de bonnes expériences avec les critiques de paires. Deux personnes examinent le code source de l'autre tandis que les deux sont assis devant le même moniteur. Nous nous assurons que ce ne sont pas toujours les mêmes personnes et qu'il est clair et convenu à l'avance de ce qu'elles recherchent toutes les deux.
Mais toujours - faire des révisions de code nécessite des gens ouverts d'esprit qui sont prêts à accepter la critique.
La mise en place d'un processus d'examen par une autorité supérieure devrait fonctionner. Même ceux qui se rebellent contre l'idée au début devraient, espérons-le, venir voir ses avantages. S'ils ne le font pas ... eh bien, ça ne peut pas vraiment aider.
Si vous n'êtes qu'un combattant isolé parmi des pairs désintéressés, vous aurez beaucoup plus de mal. Cependant, la clé dans les deux scénarios est de faire comprendre aux personnes évaluées qu'il ne s'agit pas d'une attaque personnelle contre leurs compétences, mais plutôt d'un effort d'équipe pour écraser tout le monde bogues plus efficacement.
Comment incitez-vous les gens à accepter votre révision de code?
Vous ne pouvez pas, donc vous ne le faites pas. Et vous n'êtes pas responsable du travail de quelqu'un d'autre jusqu'à ce qu'on vous demande d'en assumer la responsabilité.
Vous pouvez vous rapprocher de votre "avis", il s'agit donc plutôt de "commentaires". Ce n'est pas vous qui êtes le patron à la recherche de ce que quelqu'un d'autre a fait de mal, ce sont deux professionnels qui discutent des différentes approches du même problème.
IMO, deux programmeurs trouveront différentes façons de résoudre un problème, et ils peuvent tous les deux avoir raison.
Demandez à la personne évaluée: "Quel est, selon vous, l'avantage d'une telle approche? Fournissez également les inconvénients que vous voyez et les avantages de votre approche alternative. Demandez la reconnaissance des AD que vous avez signalés: "Êtes-vous d'accord que cela pourrait être un problème avec le code que vous avez?
Je pense que la plupart des conflits de programmation proviennent de différences de valeur et de deviner ce qui pourrait arriver à l'avenir. Les gens peuvent passer des heures à se disputer sur quelque chose de complètement indéterminé. Concentrez-vous sur les problèmes réels maintenant, moins sur (mais n'évitez pas) les choses qui pourraient arriver plus tard.
Le meilleur moyen est que la décision vienne des programmeurs qui la prennent.
Je suggérerais d'utiliser certaines compétences humaines et commencerais par une discussion sur la façon de s'assurer que le groupe peut travailler ensemble, je parlerais également des moyens de s'assurer que les compétences professionnelles des programmeurs restent à jour.
Une façon d'aller de l'avant est bien sûr de faire des revues de code, mais il existe également d'autres avenues qui pourraient être couronnées de succès, par exemple la lecture et la discussion d'un livre sur la façon de programmer. Je recommande "Clean Code: A Handbook of Agile Software Craftsmanship" ( http://www.Amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 ).
Une autre chose est de laisser chaque programmeur présenter ses projets devant le groupe quand il a fini de faire quelque chose. Cela garantira naturellement que les choses les plus laides ne soient pas écrites et que tout le monde se sent fier d'avoir accompli quelque chose.
Personnellement, je pense qu'un programmeur qui n'aime pas la révision de code n'est qu'un très mauvais programmeur. Si vous écrivez du bon code, vous n'avez rien à craindre d'une revue. Vous pourriez en fait être félicité pour votre style. Mais si vous prenez l'habitude d'écrire du mauvais code, je peux imaginer pourquoi quelqu'un n'aime pas une critique. Mais avoir quelqu'un d'autre pour signaler les erreurs dans votre style est juste utile pour améliorer votre propre expérience! Vous devriez apprendre d'une critique, ne vous en détournez pas. C'est un énorme coup de pouce à la qualité du code.
Lorsque vous effectuez des révisions de code, indiquez clairement que vous le faites pour améliorer la qualité du code, et non pour punir les mauvais développeurs. Assurez-vous que vos programmeurs considéreront ces évaluations comme pédagogiques et non comme un moyen de mesurer leurs performances.
J'ai eu beaucoup de revues de code et je me suis spécialisé dans les algorithmes complexes, donc mon code a tendance à sembler un peu complexe pour les autres. Mes collègues programmeurs me considèrent très bien dans ce que je fais et adorent revoir mon code, en raison de sa valeur éducative. Et bien sûr, de temps en temps, ils trouvent quelques petites erreurs dans mon code, mais en général, ces révisions de code sont améliorant la qualité du travail de la personne qui examine le code!
Nous utilisons ReviewBoard pour faire des critiques. Dans notre entreprise, les révisions sont volontaires: si vous faites quelque chose d'intéressant (ajouts ou modifications substantiels), nous attendons de vous que vous créiez une demande de révision à faire par les collègues de votre équipe. Les membres de l'équipe sélectionnés peuvent ensuite approuver la révision ou demander d'autres modifications.
Si vous avez besoin de forcer les révisions parce qu'un programmeur ne joue pas, il peut être nécessaire que toutes les validations dans le SCM soient fournies avec un ID de vérification qui est vérifié pour être marqué comme approuvé avant d'être accepté.
Ne présumez pas toujours que le problème est à sa fin. Peut-être que vous vous trompez.
Découvrez pourquoi ils ne l'aiment pas et au lieu de supposer automatiquement qu'ils sont un `` mauvais programmeur '', examinez d'abord s'ils peuvent avoir un point et que vous pouvez être un mauvais réviseur de code, ou simplement communiquer mal. C'est possible.
Si vos règles de révision/style de code ne sont pas subjectives, arbitraires ou folles, il sera facile d'expliquer leur justification à tout programmeur professionnel compétent. Si vous ne le pouvez pas, vous devrez peut-être repenser ce que vous faites ou comment vous le présentez.
Sinon, si le problème concerne seulement une ou deux personnes, il s'agit probablement d'un problème RH plus profond avec ces personnes et rien à voir avec la révision de code en particulier, la révision de code n'est qu'un symptôme de ce problème plus important.
Si vous êtes en charge du projet depuis le début ou si vous êtes le développeur principal, vous devriez être en mesure d'effectuer des revues de code en les instituant dans le cadre de la méthodologie de votre projet. Assurez-vous que les examens sont effectués en les dirigeant vous-même, si nécessaire. Si vous êtes en charge et que certaines personnes ne suivent pas votre exemple, vous devez soit les persuader de suivre le programme, soit les remplacer par des personnes qui le feront.
Si vous n'êtes pas en charge, vous devez persuader les membres de l'équipe qu'il est avantageux pour eux d'effectuer des révisions de code. Commencez par persuader les autres membres de l'équipe de réviser votre code. Documentez votre conception et vos interfaces et parcourez-les dans votre code. Ensuite, rédigez vous-même un résumé de la publication et des éléments d'action et distribuez-le aux membres de votre équipe. S'il y a un avantage à cela, cela deviendra rapidement évident pour l'équipe.
S'il y a de la résistance, vous devez savoir quelles sont les objections des gens. Ils pourraient être valides. Par exemple, le projet peut être suffisamment petit et toute l'équipe peut être suffisamment expérimentée pour que tous les membres du projet examinent efficacement tout le code du projet, même sans examens formels.
Je trouve que les revues de code sont les plus utiles sur les très gros projets où il n'est pas possible pour une personne de vraiment fouiller tout le code, où il y a des développeurs inexpérimentés qui ont besoin de la rétroaction pour développer leurs compétences de codage et d'analyse ou où il n'y a pas de codage les membres de l'équipe qui doivent comprendre la conception et le code. Je trouve les évaluations essentielles ou même obligatoires en cas de conséquences juridiques ou pire en cas de défaillance du code (par exemple, les systèmes de contrôle de vol des avions). Je les trouve redondants lorsque je travaille avec des programmeurs chevronnés, où tout le monde dans l'équipe produit du code, où le projet est petit et où les membres de l'équipe lisent et critiquent le code tout le temps de toute façon.
Vous devez accepter que vous ne pouvez pas "obliger" les gens à accepter la révision du code.
Vous pouvez faire un compilateur faire ce que vous voulez, mais avec les humains, le mieux que vous puissiez viser est:
"Comment puis-je être plus influent lors de l'examen du code d'une autre personne?"
... et c'est une autre question entièrement.
Je pense que le plus gros problème avec les revues de code est que certaines personnes ne peuvent pas les faire correctement. Par exemple, mettre final devant la classe/méthode/paramètre/n'importe quoi n'a pas d'importance et ne devrait pas être dans une revue de code. Un autre exemple utilise la mauvaise boucle car seul foreach est correct. Exiger de tout commenter. Optimisations String +/StringBuilder/StringBuffer. Si je recevais un examen du code avec l'une de ces choses, je penserais que ce gars est un idiot et si je n'étais pas obligé de changer le code, je ne le ferais pas.
Parfois, les outils de révision de code sont tout simplement erronés, par exemple par défaut PMD (Java) aime dire que la classe a trop de méthodes, donc ce que j'ai fait est de créer classe parent abstraite et y pousser quelques méthodes. J'aurais pu diviser la classe en 2 classes, mais je pense que l'API sera plus facile à utiliser avec toutes ces méthodes dans une classe (c'est une petite bibliothèque et ma décision de conception). Certaines personnes utiliseront toujours uniquement la valeur par défaut, donc cela ne devrait pas être merdique.
Le principe 1-3-2 s'applique ici (je parle 1ère personne, puis 3ème personne, puis 2ème - dans cet ordre).
La première priorité est de pratiquer ce que je prêche, ce qui signifie que je veux d'abord dire "j'ai" besoin de révisions de code (et de les faire).
Alors seulement si l'atmosphère ne s'adapte pas aux revues de code, je commence à dire que "les gens" ont besoin de revues de code (et énumèrent les bonnes raisons).
Seulement après cela, si tout le reste échoue (et je suis en autorité :)), j'établis la loi et dis "vous" avez besoin de révisions de code. C'est la partie que les gens ont correctement énumérée, mais je ne Twitch que lorsque la mentalité de la troisième personne n'est pas la dernière. Si je ne parle pas à la première personne et que je ne pratique pas ce que je prêche, non seulement je suis un persuadeur "inefficace", mais je suis encore plus un con.
ps. Remarquez comment j'ai dit tout cela à la première personne :)
Pour offrir une autre perspective, j'ai parfois découvert que les revues de code dérivaient vers des choses qui n'ont même pas de sens à discuter. Comme si ce type avait passé en revue mon code en disant que je n'ai pas la ponctuation correcte (un arrêt) dans l'un des commentaires que j'ai ajoutés au code. Bien qu'il soit subjectif de savoir si une telle chose est importante (si vous écrivez une documentation en ligne qui sera intégrée dans les documents publiés par exemple, cela pourrait être important), dans mon cas, ce n'était clairement pas le cas.
Je pense que les révisions de code sont obligatoires, j'ai toujours été aidé par les commentaires de révision de code, et il faut parfois un peu de temps pour qu'un nouveau membre de l'équipe comprenne pourquoi elles sont importantes. Mais il est également important que l'objectivité soit maintenue, chaque suggestion doit avoir une raison objective et ne doit pas être faite en raison des préférences subjectives d'un examinateur.
Donc, pour répondre à la question - il est bon de guider les nouveaux membres de l'équipe sur l'importance et le but de la révision du code, à un stade où ils sont susceptibles d'écouter. Et avec l'expérience, ils apprendront que ce n'est pas personnel. Il est également important que les bonnes personnes soient des examinateurs et non des personnes qui imposent leurs opinions subjectives aux autres.
Revue avec des questions, pas des commandes
Je pense qu'un problème fondamental avec votre processus d'examen est votre idée que vous devez forcer quoi que ce soit dans leur gorge. Au lieu de cela, posez des questions comme "Pourquoi avez-vous décidé d’opter pour l’approche X au lieu de Y?"
Cela les fera réfléchir à leur propre processus de codage, au lieu de les forcer à accepter votre processus de codage. Et bon, vous pourriez aussi apprendre quelque chose.
Je n'ai jamais eu la chance de participer à la révision de code, mais je pense que c'est sûrement une excellente pratique.
Pour que la révision du code soit bien acceptée, vous pouvez organiser une formation sur la manière de formuler une "critique positive".
Et, au fait, une telle formation pourrait également être l'occasion de rappeler aux gens les principes de développement de l'entreprise/projet et de faire du team building.
Tout d'abord, comme pour tous les problèmes, commencez à résoudre celui-ci vous-même. Assurez-vous que vous faites tout pour rendre les revues de code aussi productives et non conflictuelles que possible.
- N'utilisez pas les revues de code pour appliquer les meilleures pratiques lorsque vous pouvez utiliser une automatisation quelconque. Ayez des bibliothèques standard à portée de main pour accomplir les tâches les plus courantes: chiffrement, accès à la base de données, etc. "façon, il suffit de le rendre plus facile à faire. Nous sommes paresseux, nous allons donc prendre le chemin de la moindre résistance.
- Ne passez pas en revue les noms de variables, les blocs de commentaires normalisés et autres détails épineux. À moins que le nom de la variable soit difficile à comprendre, ça va. La "cohérence" n'est qu'une excuse pour exercer l'autorité et tout le monde peut voir à travers elle.
- Ne demandez pas au gars le plus grognon de votre groupe de faire les revues. Ou faites attention à ce que les personnes ayant des conflits de personnalité ne passent pas en revue le code de l'autre.
- Prenez des collations et des boissons à chaque révision du code. Tout le monde aime les collations et les boissons.
D'après mon expérience, la paire programmation a bien plus d'avantages que de simples critiques. Non seulement il trouve plus de bugs, mais il encourage des solutions plus créatives, le partage des connaissances, le renforcement d'équipe, la communication ouverte et permet à une équipe d'affiner en permanence un style de programmation naturel.
À chaque fois, je fais partie d'une équipe qui a essayé les critiques, cela devient conflictuel, puis s'essouffle quand une échéance difficile se profile.
Il peut être difficile pour un développeur chevronné de s'adapter à l'idée des avis, mais quand il clique, l'élan reprend vraiment. Essayez-le pendant quelques semaines et voyez si cela fonctionne pour vous.
Essayez de les vendre sur l'aspect d'apprentissage . Presque tous les programmeurs que j'ai rencontrés aiment apprendre, et personnellement, j'ai appris quelque chose à chaque revue de code (que j'aie été le critique ou le critique).
Cependant, une fois que vous avez commencé les évaluations, il vous incombe de vous assurer qu'elles valent la peine. Ne vous embourbez pas dans des arguments de mise en forme mesquins (mettez-les hors ligne). Utilisez des outils d'analyse statique (comme FindBugs pour Java), recherchez les TODO, passez en revue chaque avertissement du compilateur, vérifiez l'exhaustivité de la documentation, etc.
Plus les informations recueillies seront précieuses, plus les évaluations seront couronnées de succès.
Les révisions de code sont un élément essentiel de la prévention précoce d'une catastrophe majeure. Beaucoup de grands magasins de développement EXIGENT des revues de code sur leurs projets.
Pour faciliter l'acceptation par les gens, il devrait y avoir des directives à suivre par le réviseur. Si la personne a l'impression d'être isolée ou que l'examinateur pourrait en vouloir, elle peut être réticente à passer en revue. Si à l'avance tout le monde est informé des directives et de ce que l'examinateur recherchera, vous obtiendrez peut-être un meilleur accueil. Personne n'aime la subjectivité lorsqu'elle reflète sa carrière ou ses performances.
Parlant d'expérience, j'ai travaillé avec un certain nombre de développeurs sur des contrats gouvernementaux de haut niveau qui étaient une révision anti-code. Où cela nous a-t-il conduit? Beaucoup de retard et beaucoup plus que le budget. Les développeurs qui ont quelque chose à cacher vont être résistants aux personnes qui traversent leur travail car ils sont bien conscients de leurs lacunes.
D'après mon expérience, ceux qui ne veulent pas ou résistent aux critiques sont également les mêmes personnes qui ne veulent pas apprendre et adapter leur style de pensée au problème en cours, ce qui peut être une pente glissante pour un projet lorsque le la personne est dans un rôle de prise de décision.
Autre chose à penser; si le budget et l'entreprise peuvent le rendre disponible, demandez à quelqu'un qui est uniquement chargé des révisions de code ou même de faire venir quelqu'un d'un autre projet pour effectuer la révision. S'il n'y a pas de relation préalable, cela peut être plus facile pour les deux parties.
Si tout le reste échoue et que vous vous inquiétez, l'attitude des personnes peut créer des problèmes pour le projet dans son ensemble, documentez-le et transmettez le problème à un supérieur de manière respectueuse. Aller à la poursuite de quelqu'un ou souligner ses lacunes va vous paraître mauvais et peut attirer l'attention sur votre propre travail.
J'ai été étonné que personne n'ait encore mentionné la pratique agile appelée "The Perfection Game", qui fait partie des Core Protocols . Les protocoles principaux suggèrent une sorte de révision de code plus facile à accepter pour les programmeurs.
En résumé, voici comment cela fonctionne:
- le programmeur demande à un critique potentiel s'il est d'accord pour jouer à un jeu de perfection
- si le réviseur est OK, le réviseur vérifie le code et donne une valeur de 1 à 10, selon la valeur qu'il croit peut ajouter au code (par exemple, s'il dit 1, cela peut signifier que c'est une merde, mais je le fais ne pas en comprendre un peu, ne sera d'aucune aide, ou cela peut signifier que c'est presque parfait, je ne pourrais pas faire mieux. Si le critique dit 10 d'autre part, cela signifierait: votre code est un morceau de merde , mais vous avez de la chance: je peux vous aider car je suis un expert de ce genre de merde).
- le réviseur explique ce qu'il aime ( pas ce qu'il n'aime pas ) dans le code révisé
- le programmeur demande ensuite ce qui serait nécessaire pour rendre ce code parfait et le réviseur l'explique.
- le programmeur remercie ensuite le réviseur et modifie son code si nécessaire.
Bien sûr, cela peut être répété jusqu'à ce que le programmeur cesse de chercher la perfection, ou que le réviseur ne puisse plus aider (il donnera une évaluation faible et le programmeur s'arrêtera là).
C'est un peu formel car cela vient des protocoles principaux, mais le programmeur est toujours responsable des changements de code et demande une révision en tant que service. Il n'utilisera généralement pas ce type de révision pour rejeter sa responsabilité, au contraire le programmeur devrait demander à un autre réviseur si une critique donnée ne pourra pas l'aider.
Perfection Game peut ne pas s'appliquer à tous les cas car il fonctionne sur une base volontaire (je comprends la question comme demandant des révisions de code obligatoires). Il a également mis en évidence que le libellé "révision de code" couvre de nombreuses pratiques différentes sous-jacentes (dans le monde agile, seuls le jeu Perfection et la programmation par paires sont par exemple deux types totalement différents de révisions de code).
Certaines pratiques sont plus faciles à accepter que d'autres et cela peut aussi dépendre de l'équipe et du programmeur individuel. En guise de postface, je répondrais également à la question d'origine en disant que les révisions de code sont plus faciles lorsqu'il y a confiance entre les membres d'une équipe.
Quelles que soient les pratiques choisies, La confiance envers les collègues est certainement au cœur de l'acceptation de la revue de code par les programmeurs.
Une autre option: nous organisons des "réflexions" périodiques sur notre processus avec tous les programmeurs d'un projet. Une partie de cette pratique consiste à effectuer une "analyse des causes profondes" sur les bogues qui ont fait surface récemment. Qu'est-ce qui a causé ça? S'agit-il d'une régression? Était-ce un manque de tests IE6? Est-ce que poser des questions à Joe à ce sujet aurait aidé? Le but étant de comprendre pourquoi nous avons ces bogues et ce que nous pouvons changer pour les éviter.
Si les revues de code sont un outil approprié, cela sortira pendant la discussion. Et ce seront les programmeurs eux-mêmes qui le présenteront, et vous obtiendrez donc beaucoup plus d'adhésion dès le début. Nous avons convenu que tout le code doit être examiné avant d'être archivé. Les développeurs le demandent généralement, mais s'ils oublient, ils l'admettent timidement ... ils savent qu'ils ne défient pas seulement la "gestion", mais vont à l'encontre de l'accord de l'équipe .
(Ou si ce n'est pas un outil approprié, les gens ont la possibilité d'expliquer pourquoi.)
J'ai une situation différente. Comme je ne suis pas un développeur très expérimenté, je voudrais faire une revue de code pour mon code avant chaque version. Mais la plupart du temps, la révision du code ne correspond tout simplement pas à notre calendrier serré. Ou, mon entreprise ne pense pas que ce soit assez important pour faire valoir le bien-fondé. Idem pour le développement piloté par les tests. Si j'ai vraiment des questions, je prendrai un développeur senior pour regarder mon code. Ce n'est pas idéal, mais cela m'aide à améliorer mes compétences en codage.
S'ils ne font pas de révision de code, alors simple ... mettez-les à pied. De toute évidence, ils ne sont pas trop soucieux d'améliorer de toute façon. Il n'est pas nécessaire de garder le poids mort.
Faites de la révision du code une partie obligatoire de la validation du code dans le référentiel principal.
C'est ce que mon équipe fait et cela augmente la qualité du code et élimine presque complètement la possibilité que le code douteux en fasse la base de code sans être spécifiquement marqué "dette technique".
Nous utilisons Git et Gitorious pour gérer nos bases de code et nos référentiels.
Il y a un référentiel mainline, personne ne s'y engage directement mais en tire vers leurs clones privés sur le serveur Gitorious.
Le travail et Push s'engagent sur leur clone côté serveur privé, puis effectuent des demandes de fusion pour demander que leurs modifications soient incorporées dans le ligne principale.
Quelqu'un d'autre répond à la demande de fusion, de préférence le responsable technique de l'équipe/du projet, et examine le code des modifications, les applique, compile et exécute les tests, et si tout va bien, pousse les modifications vers le - mainline repository et ferme la demande de fusion.
L'équipe/les chefs de projet techniques ont leurs demandes de fusion répondues à mon autre membre de l'équipe, ce qui est une excellente expérience d'apprentissage pour les membres juniors si un pair n'est pas disponible pour le faire.
Quoi qu'il en soit, plus d'une personne est désormais en attente d'un mauvais code qui est validé dans le référentiel mainline et affecte le reste de l'équipe et la société dans son ensemble. Si un membre plus expérimenté de l'équipe répond à la majorité des demandes de fusion, il est alors plus qualifié pour corriger ou rejeter des implémentations ou des conceptions médiocres avant de pouvoir affecter l'intégralité de la base de code.
Ces mini revues de code sont beaucoup plus utiles que les revues de code traditionnelles qui sont généralement une perte de temps. Revues de conception sont beaucoup plus utiles, car une bonne * mise en œuvre d'une ** mauvaise conception est bien pire qu'une mauvaise mise en œuvre d'une - conception appropriée.