代码评审滞后于交付/测试周期

Question

在敏捷的过程中，我们有两周的冲刺。任务每天交付(每日构建)，测试团队在第二天甚至同一天立即完成测试。

我们也有开发代码审查，这需要一些时间(1-2小时)，所以他们被排定为每周3次:Mon。开发人员聚在一起，就如何改进/重构代码提出建议。

我们的问题是，当操作项在代码评审之后出现时，大多数任务已经测试过了。测试人员不想重新测试已经通过测试的内容。他们不关心内部的开发工具更改。

我们是否误解了敏捷过程？代码评审是否与每日发布/测试周期不兼容？我们不能每天进行代码评审，因为它们占用了每个人的时间。

Answer 1

如果您要在某一时刻检查代码，那么尽早进行检查也就不太昂贵了。而且你似乎有一个昂贵的测试过程，所以你不想测试两次。因此，在测试之前检查代码是比较便宜的。测试后检查代码并不能使工作进行得更快。它会使代码运行得更慢，并诱使您交付编写得不好但测试成功的代码。随着时间的推移，所有这些未经评审的代码将使工作变得越来越慢。然后一个更有效率的竞争者以更低的成本提供更好的产品，游戏结束了。

同时，自动化测试。手工测试是如此的1970年。

Answer 2

测试人员不想重新测试就像说“程序员不想重构”。这是工作的一部分。这个过程可以被重声明如下:任务是创建的。生成代码。代码是经过测试的。对代码进行审查。代码中存在缺陷。创建新任务是为了解决这些缺陷(例如，代码是重构的)。这些新任务需要新的测试。

Answer 3

如果您发现很难在QA之前的时间内进行代码评审，那么您应该考虑让代码评审更加轻量级，正如@Dukeling发布的敏捷团队中的代码评审，第二部分所讨论的那样。

我发现，即使是最简单的东西，也可能被称为代码评审，它也带来了好处:在提交代码(或插入DVCS)之前，请另一个开发人员过来，然后遍历您的更改。这可能需要五到十分钟。此代码评审的目标是“这对其他开发人员有意义吗？”目标不是挑剔设计实现，也不是完全符合审阅者关于如何编写它的个人想法。它提供了以下好处：

• 改进对代码工作方式的共享知识
• 捕获混淆或潜在错误的代码，因为解释代码的行为足以使作者重新思考问题。
• 帮助逐渐发展团队习语和风格，因为它使解释事情变得更容易。
• 队员们很少抱怨

更深入的代码评审绝对能更好地发现问题。但你必须能够做到，并对他们采取行动，以获得价值。您可以一直执行的轻量级流程可能比一直被推迟的重量级流程更有帮助，或者只是向待办事项添加一些内容。