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

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?

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.

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.

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.

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.

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.

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.

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).