如何拒绝您认为不必要的代码审查？

#1 楼

要求测试用例在没有变更的情况下失败，而变更不会成功。

如果他不能生产一个测试用例，则将其用作理由。

如果他可以生产然后您需要解释为什么测试无效。

#2 楼

审阅者应该是客观的。

很明显，您甚至在审阅它之前就已经对所讨论的代码形成了看法，这听起来像是您和修复者已经放样了。如果是这样，那么您将很难表现出客观性，而要表现出客观性则更加困难。这些都无助于整个过程，也许您可​​以做的最好，最客观的事情就是以过于接近问题为由拒绝参加。

考虑团队合作的方法。

如果无法删除自己，也许您可​​以让其他几个工程师同时检查代码。他们会同意您的意见，否则代码将被拒绝。如果他们同意您的意见，那么解决方案将不再只是您与修复者，您还可以提出更强有力的理由，要求团队客观地查看修复程序并决定不接受该修复程序。另一方面，如果他们决定接受此修复程序，那么这也将是团队的决定。毋庸置疑，您应该以开放的心态参与进来，并且除了理性的讨论之外，您不应该尝试影响其他团队成员的观点。重要提示：如果以后会有不好的结果，请不要说“很好，我一直说这是不好的代码，但是我的人数比其他团队的成员都要多。”。

拒绝是代码审查过程的自然组成部分。

代码审查过程并不适用于更多高级人士的橡皮图章修复。它可以保护和提高代码质量。如果您出于正确的原因进行了修复，那么拒绝该修复程序并没有错，即该修复程序无法改善代码。如果在对代码进行开明的检查之后，您仍然认为该修复程序并未降低可证明问题的风险和/或严重性，那么您应该拒绝它。这不是个人的，只是您的诚实意见。如果修复者不同意，那也没关系，到那时，管理人员就必须解决这个问题。只要确保保持诚实，开放和专业即可。

责任是双向的。

您说过，您不想为这种改变负责您不相信有问题。但是，您需要意识到，如果您错了并且有问题，那么您最终可能会负责拒绝可以避免该问题的代码。

做笔记。 >
保留审查过程的书面记录将有助于您保持事实的正确性。写下您的想法和疑虑，同时审查，描述和测试可能用来衡量所谓的问题和解决方案的任何测试的结果，等等。如果问题升级，则将记录您为支持自己所做的工作位置。如果以后再次出现此问题（如果将修复程序附加到他自己的视图中，则可能会出现此问题），您将有一些需要记忆的地方。

#3 楼

写下您可能拒绝的理由和抗辩理由。然后，与修复程序进行合理讨论，并在必要时上报给管理人员。
使用定影液会引起不适，因此请确保该问题值得（即，非定影液是否会造成伤害？）

此外，如果定影液存在于任何与业主相关的方式，请忽略此答案。

#4 楼

最近在LinkedIn新闻中，有一篇关于工作场所解决冲突，谦虚而非自大的文章。不幸的是，我现在找不到链接，但是总的目的是试图以一种非对抗性的方式提出问题。请不要以此为我意思是您很自大，这只是本文的写作方式。对他采取防御性方法，并在他的回应中向您发起攻击。但是，如果从您缺乏理解的角度出发，提出一个为什么他认为这个问题存在的问题，那么他/他可能会更愿意讨论此事。

所以，而不是说“问题不存在，所以我不必对此进行审查”，而可能会问类似“为了正确地对此进行审查，我需要理解该问题。请您从您的角度进行解释例如，文章描述了对儿童的测试，其中一个成年人举起一个立方体，该立方体的所有面都是一种颜色，除了面对成年人的一个。当询问孩子们成年人看到的是什么颜色时，五岁以下的孩子几乎总是说出他们能看到的颜色，因为他们不理解成年人可能对自己的看法有所不同。 >

#5 楼

C / C ++可能充满未定义的行为。一方面，这很糟糕，因为它可能导致意外的行为。另一方面，它允许进行积极的优化，通常当您使用C / C ++时，您会对速度感兴趣。存在了。同样，在任何明智的体系结构上似乎“都不会造成任何问题”。

但是，在某一点或另一点上，您将更改平台（例如-您想移动，以便移植到ARM或者您想加快速度并使用GPU）。此时，事情可能开始破裂，您需要对其进行调试。它可能像将编译器更新为较新版本一样琐碎（您可能需要/需要它）。

有问题的代码是：

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;
 }

在上一次迭代中访问了d[++k] => d[++15] => d[16]。由于通常下一个元素是合法内存（就分页而言不是C内存模型），即使是琐碎的编译器也不会产生任何具有奇怪行为的可执行文件。编写测试用例的唯一方法是找到具有与C完全相同的内存模型（可能是VM）的平台。

gcc 4.8预发布发现d[++k]在每个循环中都执行。因此，否则访问将是非法的，并且馈给编译器的程序的合法性是合同的一部分。因此，给定假设，循环条件始终为真，因此它是无限循环。这听起来可能很奇怪，但这是完全合法的优化-发出k < 16也是循环的正确替代。您可以选择更多微妙的方式来表现行为。例如，在关于事务性内存的讲座中，我记得当两个线程将相同的值递增时，演示者曾多次尝试得出错误的值。可以参考客观来源来完成：


如果您认为这不是问题，请尝试使用C / C ++标准对其进行证明（即，它导致定义的值和行为）
如果他认为这存在问题，请请他使用C / C ++对其进行证明标准（即它导致不确定的价值或行为）

通常，如果您的团队使用C / C ++编写，手头有标准很有用-即使团队专家一次可以在其中找到一些奇怪的东西一会儿。

#6 楼

这听起来更像是您的团队政策的问题，而不是此特定的审查。当我由9人组成的团队在一家大型软件商店工作时，审稿人对代码具有否决权，这是我们大家都尊重的标准。我们足够有才华和精明-即。 “成熟”，但更多的是“不幼稚”而不是“经验丰富”-我们的团队负责人可以合理地期望我们始终能够达成协议，而不会在审慎的时间段内引起争议。

仅根据您在帖子中使用的语言，我可能会警告您，这听起来像您将以某种可能导致争论的方式来对待这种情况。也许这是“智力自慰”，但他或她这样做可能是有原因的，而您的负担将是想出一种解决该问题的简单方法-如果不存在这种方法，请在注释中注明原因实际上，手淫代码是必要的。

#7 楼

使提交者证明自己的代码可以解决他的问题。如果他可以测试并向您显示证据，那么您就是错的人，应该停止抱怨并加以处理。如果他不能出示证据来支持他的主张存在问题，并且不能出示证明他的补丁可以解决问题的证据，那么我会将他送回绘图板。

当然，围绕这一点可能会有敏感的内部政治性。但是，这就是我要走的路（非常好）。