Disons que l'on travaille dans une entreprise hypothétique qui a plusieurs développeurs qui ont rarement travaillé ensemble sur des projets et le patron ne pensait pas que les revues de code valaient le temps et le coût.
Quels sont les divers arguments qui pourraient être présentés dans ce scénario et qui présenteront les avantages de la révision de code? De plus, quels sont les arguments potentiels contre la révision du code ici et comment les contrer?
Réponses:
Si vous devez vous justifier pour de telles choses de base, vous avez un plus gros problème.
Vous êtes l'expert, votre équipe doit décider quelles pratiques vous utilisez. Vous devriez peut-être commencer à convaincre votre patron de ce principe très important.
Votre patron est censé décider quoi faire et, plus important encore, pourquoi le faire. Vous devez prendre soin du COMMENT le construire
(cela ne signifie pas que vous ne pouvez pas suggérer quoi et pourquoi faire les choses dans votre entreprise bien sûr). Un grand patron devrait encourager ses employés à participer à la stratégie de l'entreprise)
Cependant, voici comment je vois les revues de code des pairs:
Parce que la programmation est un travail intellectuel très intensif, une personne ne peut pas garantir que tout est parfait. Par conséquent, la révision du code garantit que:
Tout le monde en profite directement:
La révision de code peut familiariser plusieurs développeurs avec le même code. C'est une bonne chose. Et si l'auteur d'origine décide d'arrêter ou pire, quelque chose de mal lui arrive. Si des révisions de code sont effectuées régulièrement, d'autres peuvent prendre le relais rapidement.
Les pairs peuvent peut-être repérer des bogues potentiels ou des problèmes de performances lors de la révision du code. Cela réduit l'AQ et l'effort de développement. Cela peut compenser le coût supplémentaire lié aux révisions de code.
Les revues de code favorisent le partage des connaissances. Les pairs peuvent dire de meilleures façons ou d'autres façons de faire les choses. J'ai moi-même beaucoup appris de mes pairs grâce aux revues de code.
Les révisions de code aident à renforcer les directives de codage suivies par l'équipe. Si l'équipe n'en a pas, cela doit être corrigé. Le code est destiné à être écrit une fois et lu plusieurs fois. Les directives de codage sont une étape vers un code lisible. Le code est censé être lisible par les pairs. Quoi de mieux que d'avoir des revues de code pour assurer la lisibilité?
Beaucoup de bonnes réponses ici. Certaines choses que j'ajouterais:
Lorsque vous devez expliquer du code à quelqu'un d'autre, souvent au cours de l'explication, le développeur peut soudainement se rendre compte qu'il a un bogue. Je l'ai vu se produire encore et encore que le développeur s'arrête net dans ses pistes et dit "oh attendez, c'est faux" avant que le critique n'ait assez bien compris la chose pour voir le bug.
Le fait de savoir que votre code sera inspecté par quelqu'un d'autre vous incite davantage à utiliser des normes de codage (facilitant la maintenance) ou à utiliser moins de méthodes "cowboy" que personne sauf vous (et parfois même pas vous-même) ne comprendra jamais. Vous ne voulez pas être gêné lorsque vous montrez votre code à quelqu'un d'autre, vous faites donc un meilleur travail en premier lieu. En raison du facteur d'embarras, il laisse moins de code commenté avec: "Je ne sais pas pourquoi cela fonctionne mais ne le dérange pas." dans la base de code.
Les développeurs qui ont besoin d'une supervision ou d'une formation plus approfondie sont facilement identifiés. Il en va de même pour les incompétents. Plus tôt vous pourrez trouver et résoudre les problèmes de performances, mieux l'équipe dans son ensemble et meilleure sera la qualité de l'application. Il est bon de découvrir ces informations avant de prendre le nouveau gars qui a besoin de formation et de l'affecter à la partie la plus difficile et la plus critique de votre demande.
Parfois, il s'agit simplement de corriger une perception erronée qui évitera de faire la même erreur dans un tas d'autres endroits. Par exemple, nous avons récemment examiné certains codes SQL pour des rapports complexes et avons constaté que plusieurs de nos nouveaux développeurs avaient le même malentendu quant à l'endroit où trouver une information spécifique dans la base de données (il est vrai que l'endroit qu'ils ont choisi semblait logique, ce qui est un problème de conception de base de données que nous doivent également être corrigés) qui seraient essentiels pour rédiger correctement tous les rapports. En trouvant le problème et en le corrigeant dans les premiers rapports qu'ils ont écrits, il a sauvé la même erreur de se produire dans le reste des rapports. Et quelque chose que les développeurs plus âgés (en travaillant ici et non en vieillissant) étaient si habitués qu'ils ne pensaient pas qu'il fallait expliquer était sorti.
Les juniors peuvent apprendre du code plus sophistiqué écrit par les seniors (qui ont tendance à mieux comprendre le piégeage d'erreurs et les cas marginaux par exemple) et les seniors peuvent apprendre des nouvelles techniques utilisées par les juniors auxquelles ils n'ont pas encore été exposés.
Parfois, les personnes travaillant sur des parties différentes mais liées de l'application se rendent compte qu'elles vont dans deux directions différentes et mutuellement exclusives. Oups, plus facile à réparer maintenant.
Ce n'est pas si facile de se faufiler dans des valeurs codées en dur qui changeront avec le temps juste pour que la chose fonctionne maintenant. Cela évite de nombreux bugs futurs tels que des choses qui changent au début de chaque exercice.
J'ai parfois été coincé sur la façon de faire quelque chose et j'ai appris une nouvelle technique qui était exactement ce que je voulais du code en examinant les choses de quelqu'un d'autre.
Si vous savez comment les autres membres de votre équipe pensent (quel examen de code vous aidera à comprendre), il sera plus facile de résoudre les problèmes plus tard, car vous commencerez par comprendre comment Joe aurait abordé ce type de problème.
En plus du partage de connaissances mentionné par les autres, trouvez des exemples de bogues qui auraient été trouvés lors d'une révision de code et mesurez combien de temps il a fallu pour corriger - cela inclut le temps passé à rechercher le problème et à publier la version corrigée ainsi que le temps réel de correction du bug.
Prenez ce coût, qui nécessitera probablement au moins quelques jours d'effort, et comparez-le au temps que vous auriez consacré à la révision du code et à l'application des résultats.
Cela montrera à votre patron que les revues de code en valent la peine.
Les révisions de code peuvent:
Les inconvénients
Si c'est vrai, alors comment se fait-il que nous semblions toujours avoir le temps de faire les choses deux ou trois fois pour le même client, mais nous n'avons jamais assez de temps pour le faire correctement la première fois.
Si vous avez besoin de faire référence à un document, je ne chercherai pas plus loin que le «code complet» estimé. Dans ce document, le livre décrit le nombre d'erreurs détectées lors des tests unitaires par rapport à l'examen par les pairs. C'est étonnant. Les tests unitaires, si ma mémoire est bonne, n'attrapent que ~ 30% de tous les bogues tandis que les évaluations formelles par les pairs attrapent ~ 70%.
Prenez cette information, montrez-le dans le livre et faites appel à son côté financier. Il faut beaucoup plus de temps et il est beaucoup plus coûteux de laisser passer les bogues que de les attraper tôt.
Que diriez-vous d'exécuter une démo (un projet de type "mickey mouse" d'une semaine) exécutée en parallèle par deux équipes, l'une utilisant la révision de code, l'autre non.
À la fin de la semaine, pour évaluer la qualité du travail de chaque équipe, je suis sûr que les réviseurs de code s'en sortiront mieux.
De Steve Mcconnel's Construx The Business Case for Better Software Practices and Software Software Development's Low Hanging Fruit (LHF) adresse ceci. À partir de ce dernier, «LHF qui ne résistera pas à la haute direction» énumère les inspections.
Lors de la présentation, concentrez-vous sur l'image plus grande.
Énumérez les avantages (meilleur code, moins de bogues, moins de réécritures, etc.) et mentionnez la révision du code comme l' une des techniques que vous recommanderiez.
Je voudrais que cela fasse partie d'une plus grande image de l'artisanat du logiciel
Soyez prêt à faire vous-même beaucoup de travail pour promouvoir ces principes.
La plupart d'entre eux ne s'attendent pas à ce que la persuasion soit une sorte de "réunion unique".
Vous devez construire le cas au fil du temps avec calme et de manière cohérente. Lorsque vous êtes le plus ennuyé par des bogues qui auraient été corrigés par de meilleures techniques, c'est souvent le pire moment pour faire valoir votre cause, car vous êtes plus susceptible d'être trop émotif et moins rationnel. Cela peut sembler quelque peu contre-intuitif, mais c'est ce que j'ai appris au cours de 30 années de programmation. Évidemment ymmv.