阅读这篇博客文章后，我认为这可能是个好主意……有时。

the neurotic paranoid in me began to wonder how close of an eye they were putting on my code. Especially after a few times where I noticed bugs right before I checked in the supposedly reviewed code.
    
    So I came up the concept of Jester bugs. Jester is a unit test tester for Java. It works by making a syntactically correct change to the original source code under test, compiling it, and then running the unit test suite. If the unit test suite results in everything being A-okay, then you know that the test suite is flawed because it missed the monkey wrench that was thrown into the code.
    
    Jester bugs are bugs that you intentionally introduce into your code, to see if your code reviewer is really spotting bugs in your code or just giving it a pass.

阿尔·斯威加特

解决方案

回答

否。通过电子邮件将数百或者数千行代码发送给某人并说"请检查此内容"永远不会导致全面的检查。如果我们认为执行此操作时人们没有在检查代码，那是对的。故意将错误放入代码中只是将这种荒谬的实践变成了游戏。

正确检查代码的唯一方法是让人们聚在一起并一起经历代码。

回答

好吧，我知道，如果我这样做，我会忘记的，因此有目的地在代码库中引入一个错误。因此，除非我们有良好的记忆力，否则我不确定这是否是个好主意。

回答

我想说："你是认真的吗？"但我可以看出你的意思...

虽然我可能不会这样做，但实际上是将代码摆在他们的脸上，并要求他们给出实际答案，让他们动脑筋……甚至可能会花一个人来吸引他们的注意力，然后，也许他们会感觉到更多入住后必须对其进行适当的审查...

我不想故意检查错误，只是因为担心我会忘记错误的位置^ _ ^

回答

这是我在讨论在线游戏规则之前所做的事情，我们会添加一些愚蠢的内容，以便我们知道我们每个人实际上都在阅读建议。一切都很幽默，非常有帮助。

回答

关于故意在代码中添加错误以吸引同事的某些事情只是不适合我。我说你只是做正式检查。然后，我们知道代码已经过审核，并且它们被证明可以找到更多的错误。

回答

我不同意博客作者的做法。代码审查应亲自在一个房间里进行，每个人都在里面。但是，在代码中放入错误的想法仍然存在，即观察人们(1)在参加会议之前是否阅读了代码，以及(2)在会议期间是否在关注和思考。

回答

我记得曾经见过有人建议我们不要在代码审查之前编译代码，然后尝试在该审查中查找编译错误。从理论上讲，一旦审阅结束，我们就可以真正地编译代码，并查看在审阅中没有发现多少编译错误。可以肯定地说，我们也错过了许多逻辑错误。不知道我是否可以强迫自己不要键入" make"，但这确实让我思考，这也将有助于解决此问题。

回答

这是解决问题的一种非常消极的进取方式，可以直接更好地解决该问题。如果我们认为需要更好，更正式的代码审查流程，请这样说。

回答

我认为处理此问题的最佳方法是将其召唤为不专心或者承诺不足。或者只是停止与该人进行代码审查。没有人喜欢偷偷摸摸，坦率而诚实。

回答

我们可以花时间为软件开发过程增加价值的所有事情中，即使它甚至根本无法增加价值，也必须排在列表的底部，这值得商de。

我认为这里的问题是我们误解了代码审查的基本增值。代码审查的重点不是专门查找错误。我们应该有其他流程，例如单元测试，集成测试，持续集成构建，QA工具/团队等，以查找错误。

代码审查可以通过识别不同级别的问题来提供价值-显然，我们可以在代码审查期间识别特定的错误，这很好，但是代码审查还可以识别较高或者较低级别的问题。

例如，在更高的层次上，也许有人可以指出，要求所有货币都必须以美分存储在整数中，而不是以美元存储在浮点数中，并且所检查的代码不能满足该要求(否则是完全正确的)。

在较低的级别上，它为经验丰富的开发人员提供了机会，向更多的初级开发人员提供有关如何更好地/更简单地/如何解决问题的建议。例如，也许开发人员有很多嵌套的for循环，可以用一些简单的列表推导或者更高阶的函数代替。

同样，它也可能为年轻，更有活力的开发人员提供一个机会，让年长的，经验丰富的，但也更加乐于助人的开发人员了解一些可以极大简化其代码的新的前沿技术，等等。

在一天结束时，它还可以使每个人都及时了解代码库中发生的一切，及时发现与预期相差甚远的情况，确保每个人都在正确的道路上，朝着同一方向前进，并帮助相关开发人员成长和发展。

回答

请记住，每个Bug都可能对我们不利。或者以人们仅仅认为我们不擅长犯愚蠢的错误的方式，或者以人们认为我们正在积极破坏项目的方式。

在奥运会之外，强烈建议不要破坏和作弊，并且实际上可能会适得其反。

回答

在我的组织中存在一个问题，即最终用户验收(UA)测试人员直到通过质量检查之后的最终测试阶段才对应用程序进行审查，这时需求更改的成本非常高(并且不幸的是过于频繁)。

在一个迭代项目中，为确保它们专注于我故意在用户界面中放置"丑角"的产品，这些丑角是措辞难看或者措辞不佳的(例如Lorem Ipsum，橙色背景，Courier字体等)。希望UA测试人员能够参与到该应用程序中，并立即对文本或者UI进行文字处理，而不是粗略地看它并说它"足够好"并等到最后。

回答

也许不进行代码审查，这些检查就足够艰难了，但是也许如果我们要确保质量保证小组能够对代码造成足够的打击....这是IEEE最佳实践中有关缺陷播种的部分的链接。

回答

引入错误不仅总是一个坏主意，而且还会使我们看起来很糟糕。如果他们发现了错误，他们对代码的重视程度就会降低。如果然后向他们解释说我们只是引入了测试它们的错误，那么他们也会对评价不高(因为他们会认为我们或者是偏执狂或者是骗子)。

回答

根据完成的方式，我认为这可能很糟糕/很傻或者很有价值。

几位评论者似乎认为这个想法基本上是在与队友玩"陷阱"，我倾向于同意。

但是，正如IEEE文章中所建议的那样，如果整个过程非常成熟，那么可能会有缺陷播种的地方。在本文中，隐含上下文是组织非常全面地测量和监视缺陷数量的一种，其中包括到达率，关闭率，总(不仅是发现的)缺陷等。

这篇文章讨论了这样做的一些风险，这里有很多评论者。如果过程足够成熟，可以证明缺陷播种是合理的，那么可以采取多种方法来防范这些风险。

一个相关的概念是将覆盖范围的代码版本发布给QA，尽管不是候选版本。这个想法是为了验证质量检查组织的测试是否确实在执行代码。可以从该实践中收集两点信息：

• 质量检查监督：当从需求到测试的可追溯性较弱或者缺少时，此功能特别有用。
• 死代码检测：查看未测试的代码；如果可追溯性很强，那么我们可以放心大多数/所有生产所需的代码都经过测试覆盖，因此未覆盖的代码已失效。或者，实际上，这是进一步检查的起点。