Comment rejeter une révision de code que vous jugez inutile?
Je suis dans une position où on m'a demandé de revoir du code qui résout un problème qui, selon moi, n'existe pas.
Le fixeur, qui est plus âgé que moi, insiste sur le fait que sa correction est nécessaire mais elle ne semble être rien d'autre que de la sophistique C++. Une partie de notre processus de déploiement est une révision du code, et en tant que 2e ingénieur le plus élevé d'une petite entreprise, je suis censé examiner les modifications.
Je crois que les réviseurs sont tout aussi responsables des changements de code que le codeur d'origine, et je ne suis pas disposé à accepter la responsabilité de ce changement. Comment feriez-vous pour rejeter cet avis?
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'utilisez comme justification.
S'il peut en produire un, vous devez expliquer pourquoi le test n'est pas valide.
Les examinateurs doivent être objectifs.
Il est clair que vous vous êtes forgé une opinion sur le code en question avant même de l'avoir examiné, et il semble que vous et le réparateur ayez jalonné des positions. Si c'est le cas, alors vous allez avoir un objectif difficile à apparaître et un moment encore plus difficile à être objectif. Rien de tout cela n'aide le processus, et il se peut que la meilleure chose, la plus objective que vous puissiez faire, est de vous retirer au motif que vous êtes trop près du problème.
Envisagez une approche d'équipe.
S'il n'est pas possible de vous retirer, vous pouvez peut-être demander à plusieurs autres ingénieurs d'examiner le code en même temps. Soit ils conviendront avec vous que le code doit être rejeté, soit ils ne le feront pas. S'ils sont d'accord avec vous, alors ce ne sera plus seulement vous contre le fixateur, et vous pourrez prouver que l'équipe a examiné le correctif objectivement et a décidé de ne pas l'accepter. D'un autre côté, s'ils décident d'accepter le correctif, ce sera également une décision d'équipe. Il va sans dire que vous devez participer avec un esprit aussi ouvert que possible, et que vous ne devez pas essayer d'influencer les opinions des autres membres de l'équipe par autre chose qu'une discussion rationnelle. Important: s'il y a un mauvais résultat plus tard, ne jetez pas l'équipe sous le bus en disant "Eh bien [~ # ~] i [~ # ~] a toujours dit que c'était un mauvais code, mais j'étais plus nombreux que les autres membres de l'équipe. "
Les rejets sont une partie naturelle du processus de révision du code.
Le processus de révision du code n'est pas là pour corriger les tampons en caoutchouc de personnes plus âgé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 de le faire 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 pensez toujours que le correctif ne réduit pas le risque et/ou l'ampleur d'un problème démontrable, 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à, cela devient un problème pour la direction. 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 pensez pas qu'il y ait un problème. Cependant, vous devez vous rendre compte que si vous vous trompez et qu'il y a un problème, vous pourriez finir par être responsable du rejet du code qui aurait évité le problème.
Prenez des notes.
Tenir un journal écrit du processus d'examen vous aidera à garder vos faits droits. Notez vos pensées et vos préoccupations lors de l'examen, de la description et des résultats de tous les tests que vous pourriez exécuter pour mesurer le problème allégué et le correctif, etc. Si le problème s'aggrave, vous aurez un enregistrement de ce que vous avez fait pour prendre en charge votre position. Si la question revient à l'avenir (ce sera probablement le cas si le fixateur est attaché à sa propre vue), vous aurez quelque chose pour vous rafraîchir la mémoire.
Notez vos raisons de rejet et vos moyens de défense pour les contre-arguments probables. Discutez ensuite rationnellement avec le fixateur et, si nécessaire, transmettez-le à la direction.
Si vous avez suffisamment de documentation (y compris les listes de code, les résultats des tests et les arguments objective), vous serez bien couvert.
Vous causerez de la mauvaise volonté avec le fixateur, alors assurez-vous que le problème en vaut la peine (c.-à-d., La non-correction cause-t-elle un préjudice?)
De plus, si le fixateur est lié de quelque façon que ce soit aux propriétaires, oubliez cette réponse.
Récemment dans les actualités LinkedIn, il y avait un article sur la résolution des conflits sur le lieu de travail et l'humilité, plutôt que d'apparaître arrogant. Malheureusement, je ne trouve pas le lien maintenant, mais le général Gist devait essayer de formuler des questions de manière non conflictuelle. S'il vous plaît, ne prenez pas cela comme si j'impliquais que vous êtes arrogant, c'est juste la façon dont l'article a été écrit.
Quoi qu'il en soit, en disant au programmeur principal qu'il a tort dans son hypothèse, cela ne fera que l'amener à adopter une approche défensive et à vous attaquer en retour dans sa réponse. Cependant, si vous posez la question de savoir pourquoi il pense que le problème existe, du point de vue de votre manque de compréhension, il/elle 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 avoir à le revoir", demandez peut-être quelque chose comme "Pour le revoir correctement, je dois comprendre le problème. Pouvez-vous point de vue?"
À titre d'exemple, l'article décrit un test donné aux enfants où un adulte brandit un cube dont les visages étaient tous d'une seule couleur, à l'exception de celui faisant face à l'adulte. Lorsqu'on demandait aux enfants quelle couleur le visage de l'adulte voyait, 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 vue 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'un autre côté, il permet une optimisation agressive et généralement lorsque vous utilisez C/C++, vous êtes intéressé par la vitesse.
L'écriture d'un cas de test qui se casse peut être difficile - cela peut impliquer une architecture ou un compilateur étrange qui n'existe plus. De plus, cela peut sembler comme sur toute architecture sensible "cela ne devrait pas poser de problème".
Cependant, à un moment ou à un autre, vous changerez de plate-forme (disons - vous voulez devenir mobile afin de porter sur ARM ou vous voulez accélérer les choses et utiliser le GPU). À ce stade, les choses peuvent commencer pour casser et vous devrez le déboguer. Cela pourrait être aussi trivial que de mettre à jour le compilateur vers une version plus récente (et vous pourriez en avoir besoin/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;
}
Lors de la dernière itération, on accède à d[++k] => d[++15] => d[16]. Puisque généralement 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 n'ont produit aucun exécutable avec un comportement étrange. La seule façon d'écrire le scénario de test était de trouver une plateforme avec exactement le même modèle de mémoire que C (probablement VM).
Cependant gcc 4.8 pré-effacement vu que d[++k] Est exécuté dans chaque boucle. Donc k < 16 Sinon l'accès serait illégal et la légalité du programme alimenté au compilateur fait partie du contrat. Ainsi, la condition de boucle est toujours vraie compte tenu des hypothèses, il s'agit donc d'une boucle infinie. Cela peut sembler étrange mais c'était une optimisation parfaitement légale - émettre system("dd if=/dev/zero of=/dev/sda"); system("format c:") serait également un remplacement correct pour la boucle. Il existe des façons plus subtiles de choisir d'exposer des comportements. Par exemple lors d'une conférence sur Transactional Memory Je me souviens que le présentateur a essayé plusieurs fois d'obtenir une valeur erronée lorsque 2 threads ont incrémenté la même valeur.
Cependant le C/C++, contrairement à certains langages, est standardisé afin qu'un tel différend puisse se faire en référence à la 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 qu'il conduit à une valeur et à un comportement définis)
- S'il pense que c'est un problème lui demander de le prouver en utilisant le standard C/C++ (c'est-à-dire qu'il conduit à une valeur ou un comportement indéfini)
En général, si votre équipe écrit en C/C++, il est utile d'avoir une norme à portée de main - même les experts de l'équipe peuvent y trouver quelque chose d'étrange de temps en temps.
Cela ressemble plus à un problème avec votre politique d'équipe qu'avec cet examen spécifique. Lorsque je travaillais dans une grande boutique de logiciels avec une équipe de 9 personnes, un critique absolu avait un droit de veto sur le code, et c'était une norme que nous respections tous. Nous étions suffisamment talentueux et avertis - à savoir. "mature", mais plus dans le sens de "pas enfantin" que de "chevronné" - que notre chef d'équipe pouvait raisonnablement s'attendre à ce que nous soyons toujours en mesure de parvenir à un accord sans passer à des arguments dans une période de temps prudente.
Tout simplement en fonction de votre langue dans votre message, je pourrais vous avertir qu'il semble que vous allez aborder cette situation d'une manière qui pourrait conduire à un argument déconcentré. C'est peut-être de la "masturbation intellectuelle", mais il y a probablement une raison pour laquelle il l'a fait, et le fardeau pour vous sera de trouver un moyen plus simple de résoudre ce problème - et s'il n'existe pas de tel moyen, documentez en commentaire pourquoi le code masturbatoire était en effet nécessaire.
Faites en sorte que le demandeur prouve que son code résout son problème. S'il peut tester et vous montrer une preuve, alors vous êtes celui qui a tort et vous devriez simplement cesser de vous plaindre et y faire face. S'il ne peut pas montrer de preuves à l'appui de sa réclamation, il y a un problème et montrer que son correctif résout le problème, alors je le renvoie à la table de tirage.
Bien sûr, il pourrait y avoir une politique intérieure sensible à ce sujet. Mais c'est comme ça que j'irais (délicieusement).