Dans les révisions de code, le réviseur doit-il toujours présenter une solution aux problèmes?
Lors de l'examen du code, j'essaie normalement de faire des recommandations spécifiques sur la façon de résoudre les problèmes. Mais en raison du temps limité que l'on peut consacrer à l'examen, cela ne fonctionne pas toujours bien. Dans ces cas, je trouve cela plus efficace si le développeur propose lui-même une solution.
Aujourd'hui, j'ai examiné du code et j'ai constaté qu'une classe n'était évidemment pas bien conçue. Il avait un certain nombre d'attributs facultatifs qui n'étaient attribués qu'à certains objets et laissés vides pour d'autres. La manière standard de résoudre ce problème serait de diviser la classe et d'utiliser l'héritage. Cependant, dans ce cas précis, cette solution semblait trop compliquer les choses. Je n'ai pas participé moi-même au développement de ce logiciel et je ne connais pas tous les modules. Par conséquent, je ne me sentais pas suffisamment informé pour prendre une décision précise.
Un autre cas typique que j'ai rencontré à plusieurs reprises est que je trouve une fonction, un nom de classe ou de variable manifestement dénué de sens, voire trompeur, mais que je ne suis pas en mesure de trouver un bon nom moi-même.
Donc en général, en tant qu'évaluateur, est-ce bien de dire "ce code est défectueux parce que ..., faites-le différemment" ou devez-vous trouver une solution spécifique?
En tant que réviseur, votre travail consiste à vérifier si un morceau de code (ou un document) répond à certains objectifs qui ont été convenus avant la révision.
Certains de ces objectifs impliquent généralement un appel au jugement, que l'objectif ait été atteint ou non. Par exemple, l'objectif selon lequel le code doit être maintenable nécessite généralement un appel de jugement.
En tant qu'évaluateur, c'est votre travail de signaler où les objectifs n'ont pas été atteints et c'est le travail de l'auteur de s'assurer que son travail répond réellement aux objectifs. De cette façon, il ne vous appartient pas de dire comment les corrections doivent être apportées.
D'un autre côté, le simple fait de dire à l'auteur "cela est défectueux. Réparez-le" ne mène généralement pas à une atmosphère positive dans l'équipe. Pour une atmosphère positive, il est bon d'indiquer au moins pourquoi quelque chose a des défauts dans vos yeux et de fournir une meilleure alternative si vous en avez une.
. avec moi, mais je n'ai pas d'alternative claire. Pouvons-nous en discuter? " puis essayez de faire quelque chose de mieux ensemble.
Quelques bonnes réponses ici, mais je pense qu'il manque un point important. Cela fait une grande différence dont le code que vous examinez, le niveau d'expérience de cette personne et la façon dont elle gère ces suggestions. Si vous connaissez bien votre coéquipier et que vous attendez une note comme "ce code est imparfait parce que ..., faites-le différemment" pour être suffisant pour lui ou elle pour trouver une meilleure solution, alors une telle un commentaire peut convenir. Mais il y a certainement des personnes où un tel commentaire n'est pas suffisant et qui doivent savoir précisément comment améliorer leur code. Donc, à mon humble avis, c'est un jugement que vous ne pouvez faire que pour le cas individuel.
Donc, en général, en tant qu'évaluateur, est-ce bien de dire "ce code est défectueux, faites-le différemment" ou devez-vous trouver une solution spécifique?
Aucun des deux n'est idéal pour l'OMI. La meilleure chose à faire est de parler à l'auteur et de résoudre le problème en collaboration.
Les révisions de code ne doivent pas nécessairement être asynchrones. De nombreux problèmes seront débloqués si vous cessez de les voir comme un processus bureaucratique et prenez un peu de temps pour une communication en direct.
Dans les révisions de code, le réviseur doit-il toujours présenter une solution aux problèmes?
Non. Si vous faites cela, vous n'êtes pas un réviseur, vous êtes le prochain codeur.
Dans les révisions de code, le réviseur doit-il jamais présenter une solution aux problèmes?
Non. Votre travail consiste à communiquer le problème en question. Si la présentation d'une solution rend le problème clair, faites-le. Ne vous attendez pas à ce que je suive votre solution. La seule chose que vous pouvez faire ici est de faire un point. Vous n'avez pas à dicter la mise en œuvre.
Quand un réviseur doit-il présenter une solution aux problèmes?
Quand c'est le moyen le plus efficace de communiquer. Nous sommes des singes codés et non des majors anglaises. Parfois, la meilleure façon de montrer que le code est nul ... est moins qu'optimale ... est de leur montrer du code qui craint moins ... est plus opt ... oh diable vous voyez ce que je veux dire.
Le problème principal est que si les gens savaient mieux écrire le code, ils l'auraient généralement fait en premier lieu. Le caractère suffisamment précis d'une critique dépend en grande partie de l'expérience de l'auteur. Des programmeurs très expérimentés pourraient être en mesure de prendre une critique comme "cette classe est trop compliquée" et de revenir à la planche à dessin et de trouver quelque chose de mieux, car ils ont juste eu un jour de congé en raison d'un mal de tête ou étaient bâclés parce qu'ils étaient Pressé.
Habituellement, cependant, vous devez au moins identifier la source de la complication. "Ce cours est trop compliqué car il enfreint la loi de Déméter partout." "Cette classe mélange les responsabilités de la couche de présentation et de la couche de persistance." Apprendre à identifier ces raisons et à les expliquer succinctement fait partie de devenir un meilleur examinateur. Vous devez rarement entrer dans beaucoup de détails sur les solutions.
Il existe deux types de mauvais programmeurs: ceux qui ne suivent pas les pratiques standard et ceux qui "ne" suivent que les pratiques standard.
Quand j'ai eu un contact professionnel limité/fournissant des commentaires à quelqu'un, je ne dirais pas: "C'est une mauvaise conception." mais quelque chose comme "Pouvez-vous m'expliquer ce cours?" Vous découvrirez peut-être que c'est une bonne solution, le développeur a sincèrement fait de son mieux ou même reconnaître que c'est une mauvaise solution, mais c'est assez bon.
Selon la réponse, vous aurez une meilleure idée de la façon d'aborder chaque situation et chaque personne. Ils peuvent rapidement reconnaître le problème et découvrir le correctif par eux-mêmes. Ils peuvent demander de l'aide ou vont simplement essayer de la résoudre par eux-mêmes.
Il existe des pratiques suggérées dans notre entreprise, mais elles ont presque toutes des exceptions. Si vous comprenez le projet et la façon dont l'équipe l'aborde, cela peut être le contexte pour déterminer le but de la révision du code et comment aborder les problèmes.
Je me rends compte qu'il s'agit plus d'une approche du problème que d'une solution explicite. Il y aura trop de variabilité pour couvrir toutes les situations.
Lorsque je passe en revue le code, je ne fournis une solution aux problèmes que j'identifie que si je peux le faire avec peu d'effort. J'essaie cependant d'être précis sur ce que je pense être le problème, en me référant à la documentation existante lorsque cela est possible. Attendre d'un réviseur qu'il apporte une solution à chaque problème identifié crée une incitation perverse - cela découragera le réviseur de signaler les problèmes.
Mon opinion va de plus en plus vers le fait de ne pas fournir de code dans la majorité des cas, pour un certain nombre de raisons:
- Si l'explication seule ne suffit pas, ils peuvent toujours demander un échantillon de ce à quoi vous pensez.
- Vous ne perdez pas votre temps en essayant de vous familiariser avec du code que vous n'avez pas touché depuis longtemps, juste pour le modifier légèrement, tandis que quelqu'un d'autre vient de passer son temps à le faire.
- S'ils sont déjà familiers avec le morceau de code et que vous ne l'êtes pas, donner uniquement les commentaires peut entraîner un meilleur code que celui que vous écririez. Donner à quelqu'un une solution prête à l'emploi l'amènera souvent à l'utiliser, sans envisager de l'améliorer davantage.
- Toujours proposer une solution est à la limite de la condescendance. Vous travaillez avec quelqu'un, si tout va bien parce qu'ils étaient assez bons pour être embauchés. Si vous avez réussi à comprendre pourquoi quelque chose est une mauvaise idée, pourquoi ne l'apprendraient-ils pas en écoutant les commentaires et en le faisant eux-mêmes?
- Toujours proposer une solution est tout simplement bizarre. Imaginez que vous programmez en binôme à leur bureau: ils viennent de terminer quelques lignes que vous pensez ne pas être géniales. Dites-leur simplement ce que vous avez repéré et pourquoi, ou saisissez-vous leur clavier et montrez votre version immédiatement? C'est ce que peut toujours donner la solution à d'autres personnes.
- Vous pouvez toujours dire ce que vous feriez à la place, sans passer le temps de l'écrire. C'est exactement ce que vous avez fait en décrivant le premier problème de la question.
- Ne distribuez pas de nourriture, apprenez à pêcher;)
Bien sûr, il y a des cas où vous songez à une alternative spécifique, et cela vaut la peine de l'attacher. Mais c'est vraiment rare dans mon expérience. (beaucoup de critiques, de grands projets) L'auteur original peut toujours vous demander un échantillon s'il en a besoin.
Même dans ce cas, pour la troisième raison, lors de la présentation d'un échantillon, il peut être utile de dire, par exemple, "utiliser x.foo() rendrait cela plus simple" plutôt qu'une solution complète - et laisser l'auteur l'écrire. Cela vous fait également gagner du temps.
Je pense que la clé des révisions de code est de convenir des règles avant la révision.
Si vous avez un ensemble de règles claires, il ne devrait pas être nécessaire de proposer une solution. Vous vérifiez simplement que les règles ont été respectées.
La seule fois où la question d'un remplaçant se poserait serait si le développeur d'origine ne pense pas à un moyen de mettre en œuvre la fonctionnalité qui correspond aux règles. Supposons que vous ayez une exigence de performances, mais la fonctionnalité prend plus de temps que votre seuil après plusieurs tentatives d'optimisation.
Toutefois! si vos règles sont subjectives "Les noms doivent être approuvés par moi!" alors, oui vous venez de vous nommer namer en chef et vous devez vous attendre à recevoir des listes de noms acceptables.
Votre exemple d'héritage (paramètres facultatifs) est peut-être meilleur, dans la mesure où j'ai vu des règles de révision de code qui interdisent les méthodes longues et les paramètres de fonction "trop nombreux". Mais normalement, ceux-ci peuvent être résolus trivialement en se séparant. C'est la partie "cette solution semblait compliquer les choses" où votre objectivité fait intrusion et nécessite peut-être une justification ou une solution alternative.
Si une solution potentielle est rapide et facile à taper, j'essaie de l'inclure dans mes commentaires d'examen par les pairs. Sinon, j'énumère au moins ma préoccupation et pourquoi je trouve cet élément problématique. Dans le cas des noms de variables/fonctions où vous ne pouvez pas penser à quelque chose de mieux, je reconnais généralement que je n'ai pas de meilleure idée et je termine le commentaire sous la forme d'une question ouverte au cas où quelqu'un le pourrait . De cette façon, si personne ne propose une meilleure option, l'examen n'est pas vraiment retardé.
Pour l'exemple que vous avez donné dans votre question, avec la classe mal conçue. Je voudrais laisser quelques commentaires sur le fait que bien qu'il semble que cela puisse être exagéré, l'héritage serait probablement le meilleur moyen de résoudre le problème que le code essaie de résoudre, et en rester là. J'essaierais de formuler d'une manière qui indique que ce n'est pas un show-stopper et que c'est à la discrétion du développeur de réparer ou non. Je voudrais également commencer par reconnaître que vous n'êtes pas particulièrement familier avec cette partie du code, et inviter des développeurs et/ou des réviseurs plus compétents à clarifier s'il y a une raison pour laquelle cela a été fait tel quel.
Allez parler à la personne dont vous examinez le code. Dites-leur, d'une manière amicale, que vous avez trouvé cela un peu difficile à comprendre, puis discutez avec eux de la façon dont cela pourrait être clarifié.
La communication écrite conduit à de grandes quantités de temps perdu, ainsi qu'au ressentiment et aux malentendus.
Face à face, la bande passante est beaucoup plus élevée, et on a le canal latéral émotionnel pour éviter l'hostilité.
Si vous parlez réellement au gars, c'est beaucoup plus rapide, et vous pourriez vous faire un nouvel ami et découvrir que vous aimez tous les deux votre travail davantage.