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

我被要求查看一些代码来解决我认为不存在的问题。

这个比我更高级的修复程序坚持认为自己的修复程序是必要的，但对我而言，它似乎不过是C ++诡辩。我们的部署过程的一部分是代码审查，作为一名小公司的第二高级工程师，我希望审查变更。

我相信审稿人对代码更改的责任与原始编码员一样，并且我不愿意对此更改负责。您将如何拒绝此评论？

要求一个失败的测试用例，而没有成功的更改。

如果他不能生产一个，您可以以此为理由。

如果他能提供一个，那么您需要解释为什么测试无效。

审稿人应客观。

显然，您在审查代码之前就已经对所讨论的代码形成了看法，这听起来像是您和修复者已经放样了。如果真是这样，那么你将有困难的时候出现的目标，一个更加困难的时间是客观的。这些都无助于该过程，可能您可以做的最好，最客观的事情就是以太接近问题为由拒绝了。

考虑一个团队方法。

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

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

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

责任是双向的。

您说您不想为此更改负责，这显然是因为您不相信有问题。但是，你需要认识到，如果你错了，有是一个问题，那么你可能最终被负责该拒绝本来可以避免该问题的代码。

做笔记。

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

写下您可能拒绝的理由和抗辩理由。然后与修复者进行合理讨论，如有必要，请升级为管理者。

如果您有足够的文档（包括代码清单，测试结果和客观参数），则将充分了解。

您将对定影液造成不适，因此请确保该问题值得（即，非定影液是否会造成伤害？）

另外，如果修复程序与所有者有任何关系，请忘记此答案。

最近在LinkedIn新闻中，有一篇关于工作场所解决冲突，谦虚而非自大的文章。不幸的是，我现在找不到链接，但是总的目的是试图以一种非对抗性的方式提出问题。请不要以为我暗示您自大，这只是本文撰写的方式。

无论如何，告诉高级程序员他的假设是错误的，只会导致他采取防御性方法，并在他的回应中向您发起攻击。但是，如果您提出一个为什么他认为问题存在的问题，从您缺乏理解的角度来看，他/他可能会更愿意讨论此事。

因此，与其说“问题不存在，就不必复审”，不如问“为了正确复审，我需要理解问题。请您从您的角度进行解释”观点看法？”

例如，文章描述了一项针对儿童的测试，其中一个成年人举起一个立方体，除了面对成年人的那个立方体外，其他物体的所有面都是一种颜色。当询问孩子们成年人看到的是什么颜色时，五岁以下的孩子几乎总是说出他们能看到的颜色，因为他们不理解成年人可能对自己的看法有所不同。

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 prerelase看到d[++k]在每个循环中执行。因此，k < 16否则访问将是非法的，并且馈给编译器的程序的合法性是合同的一部分。因此，给定假设，循环条件始终为真，因此它是无限循环。这听起来可能很奇怪，但这是完全合法的优化-发出system("dd if=/dev/zero of=/dev/sda"); system("format c:")也将是loop的正确替代。您可以选择更多微妙的方式来表现行为。例如，在关于事务性内存的讲座中，我记得当两个线程增加相同的值时，演示者尝试了几次以获取错误的值。

但是，与某些语言相对的C / C ++已标准化，因此可以参考客观来源来解决此类争议：

• 如果您认为这不是问题，请尝试使用C / C ++标准进行证明（即，它会导致定义的值和行为）
• 如果他认为这是一个问题，请他使用C / C ++标准进行证明（即，它导致未定义的值或行为）

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

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

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

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

当然，围绕此可能会有敏感的内部政治性。但是，这就是我的选择方式。