Comment rejeter une révision de code que vous jugez inutile?

89

Je suis dans une position où on m'a demandé de réviser du code qui corrige un problème que je ne crois pas exister.

Le réparateur, qui est plus expérimenté que moi, insiste sur le fait que sa solution est nécessaire, mais il me semble qu’il ne s’agit que d’un sophisme C ++. Une partie de notre processus de déploiement consiste en une révision du code. En tant que deuxième ingénieur en importance dans une petite entreprise, je suis censé examiner les modifications.

Je pense que les relecteurs sont tout aussi responsables des modifications de code que le codeur d'origine et je ne suis pas disposé à accepter la responsabilité de ces modifications. Comment feriez-vous pour rejeter cette critique?

James
la source
113
Cela me semble évident. Vous indiquez dans la revue que le code est une masturbation intellectuelle C ++ ayant pour but de résoudre un problème qui n'existe pas. Et puis, dans le cadre du processus de révision, vous refusez le code.
user16764
86
N'utilisez pas les mots "masturbation intellectuelle" lorsque vous le refusez. Si vous utilisez cette formulation, vous le contrarierez et il ne verra pas ce que vous avez à dire comme une critique technique potentiellement correcte, il y verra une attaque personnelle. C'est peut-être une masturbation intellectuelle, mais vous pouvez être absolument certain qu'il ne le voit pas de cette façon.
Michael Shaw
15
James - J'ai retiré votre émotion de votre question afin de permettre à la communauté de se concentrer sur votre question principale. Comme d'autres l'ont fait remarquer, l'utilisation d'une terminologie complexe dans votre analyse ne fera qu'aggraver une situation qui est clairement délicate.
8
C et C ++ sont pleins de choses qui semblent fonctionner mais qui sont en réalité un comportement non défini. UB est un réel défaut, même si vous ne pouvez pas écrire un test indiquant qu'il ne fonctionne pas correctement. Par exemple, de nombreux compilateurs utilisent UB comme opportunité d'optimisation, en supposant que le cas non défini ne se produise jamais. Par exemple, si vous aviez l'habitude size > size+1de vérifier le dépassement de capacité sur un entier signé, le compilateur peut simplement remplacer cette expression par false, car le dépassement de capacité des entiers signés n'est pas défini. Voir blog.llvm.org/2011/05/…
CodesInChaos
5
@MichaelShaw "il le verra comme une attaque personnelle." ce qui me semble être le libellé de la question, une attaque personnelle contre un développeur plus âgé avec qui OP a une divergence d’opinion qu’il peut maintenant «gagner» parce qu’il a été mis en position de pouvoir.
Jwenting

Réponses:

274

Demandez un scénario de test qui échoue sans le changement qui réussit avec le changement.

S'il ne peut pas en produire un, vous l'utiliserez comme justification.

S'il peut en produire un, vous devez expliquer pourquoi le test est invalide.

Craig
la source
245
Ou peut-être que s'il peut en produire un, vous réexaminez vos hypothèses et considérez qu'il aurait pu avoir raison après tout. Vraisemblablement, le but de l'exercice est d'améliorer le code, pas de gagner le débat.
Caleb
99
Ce n'est pas parce que vous ne pouvez pas écrire un test qu'il n'est pas cassé. Comportement indéfini qui fonctionne habituellement comme prévu (C et C ++ en sont remplis), conditions de
compétition
29
Aussi, qu'en est-il de la refactorisation standard? Comment écrivez-vous un test qui échoue pour un travail de refactoring?
Mike Weller
62
"Demandez-lui de prouver pourquoi c'est nécessaire ..." Peut-être lui demander de vous apprendre pourquoi c'est nécessaire.
Mike Sherrill 'Cat Recall'
8
@RhysW: mauvaise hypothèse. Le code existant, avec la condition de concurrence critique, ne peut pas non plus être testé à cet égard. Le nouveau code est donc théoriquement meilleur et empiriquement équivalent. Votre hypothèse ne tient que si l'ancien code est empiriquement meilleur.
MSalters
152

Les réviseurs doivent être objectifs.

Il est clair que vous avez formé une opinion sur le code en question avant même de l'avoir revu, et il semble que le fixateur et vous avez pris position. Si tel est le cas, alors vous aurez du mal à paraître objectif, et encore plus difficile à être objectif. Rien de tout cela n’aide le processus, et il se peut que la meilleure chose, et la plus objective que vous puissiez faire, c’est de vous retirer sous prétexte que vous êtes trop près du problème.

Considérons une approche d'équipe.

S'il n'est pas possible de supprimer vous-même, vous pouvez peut-être demander à plusieurs autres ingénieurs de réviser le code en même temps. Soit ils conviendront avec vous que le code devrait être rejeté, soit ils ne le seront pas. S'ils sont d'accord avec vous, alors ce ne sera plus juste vous contre le fixateur, et vous serez en mesure de prouver que l'équipe a examiné le correctif de manière objective et a décidé de ne pas l'accepter. Par contre, s’ils décident d’accepter le correctif, ce sera également une décision de l’équipe. Il va sans dire que vous devez participer avec la plus grande ouverture d'esprit possible et que vous ne devez pas essayer d'influencer les opinions des autres membres de l'équipe autrement que par une discussion rationnelle. Important: s'il y a un mauvais résultat plus tard, ne jette pas l'équipe sous le bus en disant : « Eh bien , je a toujours dit que c'était un mauvais code, mais les autres membres de l'équipe m'ont dépassé en nombre. "

Les rejets font naturellement partie du processus de révision du code.

Le processus de révision du code n'est pas là pour endosser les correctifs de correctifs de la part de personnes plus expérimentées; il est là pour protéger et améliorer la qualité du code. Il n'y a rien de mal à rejeter un correctif à condition que vous le fassiez pour la bonne raison, c'est-à-dire que le correctif n'améliore pas le code. Si, après un examen ouvert du code, vous estimez toujours que le correctif ne réduit pas le risque et / ou l'ampleur d'un problème pouvant être démontré, vous devez le rejeter. Ce n'est pas personnel, juste votre opinion honnête. Si le fixateur n’est pas d’accord, c’est bien aussi, et à ce moment-là, la direction a du mal à résoudre le problème. Assurez-vous simplement de rester honnête, ouvert et professionnel.

La responsabilité va dans les deux sens.

Vous avez dit que vous ne voulez pas être responsable de ce changement, apparemment parce que vous ne croyez pas qu'il y a un problème. Cependant, vous devez comprendre que si vous vous trompez et qu'il y a un problème, vous pouvez être responsable du rejet du code, ce qui l'aurait évité.

Prendre des notes.

Tenir un journal écrit du processus d’examen vous aidera à garder les faits exacts. Ecrivez vos pensées et vos préoccupations lors de l'examen, la description et les résultats de tous les tests que vous pourriez exécuter pour mesurer le problème allégué, le correctif, etc. Si le problème s'aggrave, vous aurez une trace de ce que vous avez fait pour soutenir votre position. Si le problème se reproduit à l'avenir (cela le sera probablement si le fixateur est attaché à sa propre vue), vous aurez quelque chose à rafraîchir pour votre mémoire.

Caleb
la source
24
+1 c'est bien plus utile que la réponse acceptée
Simon Bergot
2
Absolument. La réponse acceptée est spécifique à un cas, clairement pas aussi générale et bien pensée que celle-ci.
Florian Margaine
40

Ecrivez vos raisons de rejet et vos moyens de défense pour les contre-arguments probables. Discutez ensuite de manière rationnelle avec le réparateur et, si nécessaire, dirigez-le vers la direction.

Si vous avez suffisamment de documentation (y compris des listes de codes, des résultats de tests et des arguments objectifs ), vous serez bien couvert.

Vous ferez preuve de mauvaise volonté avec le correctif, alors assurez-vous que le problème en vaut la peine (c’est-à-dire, le non-correctif cause-t-il un préjudice?)

De plus, si le correctif a un lien quelconque avec les propriétaires, oubliez cette réponse.

Dan Pichelman
la source
9
Je voterais deux fois pour la dernière partie de votre réponse seulement. Réponse très solide.
31

Récemment, dans les nouvelles de LinkedIn, il y avait un article sur la résolution des conflits sur le lieu de travail et le fait d'être humble plutôt que d'avoir l'air arrogant. Malheureusement, je ne trouve pas le lien maintenant, mais l'essentiel était d'essayer de poser des questions de manière non conflictuelle. S'il vous plaît, ne prenez pas cela pour moi, ce qui implique que vous êtes arrogant, c'est simplement la manière dont l'article a été écrit.

Quoi qu'il en soit, dire au programmeur principal qu'il se trompe dans son hypothèse ne le conduira qu'à adopter une approche défensive et à vous réattaquer dans sa réponse. Cependant, si vous lui demandez pourquoi, à son avis, le problème existe, du fait de votre manque de compréhension, il sera probablement plus ouvert pour discuter de la question.

Donc, plutôt que de dire "Le problème n'existe pas, je ne devrais donc pas être obligé de l'examiner", demandez peut-être quelque chose comme "Pour l'examiner correctement, j'ai besoin de comprendre le problème. Pouvez-vous s'il vous plaît l'expliquer à partir de votre point de vue?"

À titre d'exemple, l'article décrivait un test donné à des enfants lorsqu'un adulte tenait un cube dont les faces étaient toutes d'une couleur, à l'exception de celle qui faisait face à l'adulte. Lorsqu'on demandait aux enfants de quelle couleur était le visage de l'adulte, ceux de moins de 5 ans disaient presque toujours la couleur qu'ils pouvaient voir, car ils ne pouvaient pas comprendre que l'adulte pouvait avoir une vision différente de la leur.

Le Chevalier Noir
la source
8
Excellent point, mais je n'arrive pas à comprendre comment l'exemple au bas est lié (je ne prétends pas qu'il est sans lien, bien sûr, soulignez simplement mon manque de compréhension de la relation).
Ugoren
8
@ugoren ha ha, j'aime ce que tu as fait là!
TheDarkKnight
1
@ugoren la relation est "à moins que vous ne puissiez voir le tableau dans son intégralité, ne
formez
2
J'aime toujours l'approche modeste, je rejette le changement parce que je ne comprends pas et que je ne suis donc pas qualifié pour le donner.
PhilDin
2
@PhilDin Il y a de l'humilité et il y a des rumeurs disant que vous n'êtes pas qualifié pour le poste. S'il est en mesure de réviser le code, je pense que les personnes qui l'ont mis dans cette position s'attendent à ce qu'il soit suffisamment qualifié pour le faire.
Andy
9

C / C ++ peut être plein de comportements non définis. D'une part, c'est mauvais car cela peut conduire à des comportements inattendus. D'autre part, cela permet une optimisation agressive et généralement lorsque vous utilisez C / C ++, la vitesse vous intéresse.

Écrire un cas de test qui se casse peut être difficile - cela peut impliquer une architecture étrange ou un compilateur qui n'existe plus. En outre, sur n'importe quelle architecture sensible, cela peut sembler "cela ne devrait poser aucun problème".

Cependant, à un moment ou à un autre, vous changerez de plate-forme (par exemple, vous voulez passer au mobile pour pouvoir effectuer un portage sur ARM ou vous souhaitez accélérer les choses et utiliser le processeur graphique). À ce stade, les choses peuvent commencer à casser et vous devrez le déboguer. Cela peut être aussi simple que de mettre à jour le compilateur vers une version plus récente (et vous pourriez le vouloir / en avoir besoin).

Le code problématique était:

int d[16];

int SATD (void)
{
   int satd = 0, dd, k;
   for (dd=d[k=0]; k<16; dd=d[++k]) {
     satd += (dd < 0 ? -dd : dd);
   }
   return satd;
 }

Au cours de la dernière itération d[++k] => d[++15] => d[16]est accessible. Comme d'habitude l'élément suivant était la mémoire légale (en termes de pagination et non de modèle de mémoire C), même les compilateurs triviaux ne produisaient aucun exécutable avec un comportement étrange. La seule façon d'écrire le scénario de test consistait à rechercher une plate-forme avec exactement le même modèle de mémoire que C (probablement une machine virtuelle).

Cependant, la version préliminaire de gcc 4.8 d[++k]est exécutée dans toutes les boucles. Ainsi , k < 16sinon l'accès serait illégale et la légalité du programme nourri au compilateur fait partie du contrat. Donc, la condition de boucle est toujours vraie compte tenu des hypothèses, donc c'est une boucle infinie. Cela peut sembler étrange, mais il s’agissait d’une optimisation tout à fait légale: l’émission system("dd if=/dev/zero of=/dev/sda"); system("format c:")remplacerait également la boucle. Vous pouvez choisir d’adopter des comportements de manière plus subtile. Par exemple, lors d'une conférence sur la mémoire transactionnelle, je me souviens que le présentateur a tenté à plusieurs reprises d'obtenir une valeur erronée lorsque 2 threads incrémentaient la même valeur.

Cependant, comme C / C ++, contrairement à certains langages, est normalisé, un tel différend peut être fait en référence à une source objective:

  • Si vous pensez que ce n’est pas un problème, essayez de le prouver en utilisant la norme C / C ++ (c’est-à-dire que cela conduit à une valeur et à un comportement définis).
  • S'il pense que c'est un problème, demandez-lui de le prouver en utilisant le standard C / C ++ (c'est-à-dire que cela conduit à une valeur ou à un comportement indéfini)

En général, si votre équipe écrit en C / C ++, il est utile d’avoir le standard à portée de main - même les experts de l’équipe peuvent y trouver quelque chose d’étrange.

Maciej Piechotka
la source
4

Cela ressemble plus à un problème lié à la stratégie de votre équipe qu’à cet examen spécifique. Lorsque je travaillais dans un grand magasin de logiciels avec une équipe de neuf personnes, un critique avait totalement le droit de veto sur le code et c'était un standard que nous respections tous. Nous étions assez talentueux et avertis - à savoir. "mature", mais plus dans le sens de "pas puéril" que de "chevronné" - notre responsable d'équipe pouvait raisonnablement s'attendre à ce que nous puissions toujours parvenir à un accord sans passer par des arguments dans un délai raisonnable.

En me basant simplement sur votre langue dans votre message, je pourrais vous avertir qu'il semblerait que vous abordiez cette situation d'une manière qui pourrait conduire à un argument dévolu. C'est peut-être une "masturbation intellectuelle", mais il y a probablement une raison pour laquelle il l'a faite, et le fardeau qui vous incombe sera de trouver un moyen plus simple de résoudre ce problème - et si tel n'est pas le cas, expliquez pourquoi. le code masturbatoire était en fait nécessaire.

Djechlin
la source
1
"... mais il y a probablement une raison pour laquelle il ou elle l'a fait ..." - C'est une grosse supposition que vous faites. Et vous oubliez également que la question indique (de l'avis du PO) qu'il n'y a pas de problème. C’est sûrement à la personne qui propose un «correctif» qu’il incombe de démontrer qu’il existe un problème réel à résoudre. Il est inutile de proposer une "solution plus simple" à un problème qui n'existe pas.
Stephen C
4
@StephenC oui, et je maintiens l'opinion selon laquelle le PO devrait donner le bénéfice du doute dans ce cas. Ou alors ça va être un examen vraiment conflictuel.
Djechlin
3

Faites en sorte que l’émetteur prouve que son code corrige son problème. S'il peut tester et vous montrer des preuves, alors vous êtes celui qui a tort et vous devriez juste cesser de vous plaindre et vous en occuper. S'il ne peut pas prouver ses preuves à l'appui de son affirmation, il y a un problème et montrer que son correctif résout le problème, je le renverrais au tableau des tirants.

Bien sûr, il pourrait y avoir une politique interne sensible autour de cela. Mais c’est comme ça que j’allais (délectablement).

SnakeDoc
la source