代码审查落后于交付/测试周期

在我们的敏捷过程中，我们有2周的冲刺。每天（每天一次）交付任务，测试团队会在第二天甚至同一天立即完成测试。

我们也有开发人员代码审查，需要一些时间（1-2小时），因此每周安排3次：星期一至星期三至星期五。开发人员聚在一起，建议如何改进/重构代码。

我们的问题是，在代码审查后提出“行动项目”时，大多数任务已经过测试。测试人员不想重新测试已经通过测试的内容。他们不在乎内部开发人员的变更。

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

测试人员不想重新测试，就像在说“编码人员不想重构”。它是工作的一部分。可以像下面这样重新定义该过程：创建任务。生成代码。代码经过测试。代码已审查。在代码中发现缺陷。创建新任务以解决这些缺陷（例如，重构代码）。这些新任务需要新测试。

如果您打算在某个时候审查代码，那么尽早进行审查就不再昂贵。看来您的测试过程很昂贵，所以您不想重复测试。因此，在测试之前复查代码会更便宜。测试后复查代码并不能使工作更快。它会使速度变慢，并会诱使您交付编写质量差但已成功测试的代码。随着时间的流逝，所有这些未经审查的代码都会使工作变得越来越慢。然后，更有效率的竞争对手以更低的成本提供了更好的产品，这一切都结束了。

另外，自动化测试。手动测试大约是1970年。

如果您发现很难在当前进行质量检查之前的时间进行代码审查，则应考虑使代码审查更加轻巧，就像@Dukeling发布的《敏捷团队中的代码审查》第二部分所述。

我发现，即使是最简单的事情（可能称为代码审查）也能带来好处：在提交代码（或推入DVCS）之前，请另一位开发人员致电并带他们进行更改。这可能需要五到十分钟。此代码审查的目标是“这对其他开发人员有意义吗？” 我们的目标不是硬要设计实现或完全符合审阅者关于应如何编写的个人想法。它具有以下优点：

• 增进了有关代码工作方式的共享知识
• 由于解释代码的行为足以使作者重新思考事物，因此导致代码混乱或潜在错误
• 帮助逐步发展团队习语和风格，因为它使解释事情变得更加容易
• 团队很少抱怨

更深入的代码审查绝对可以更好地发现问题。但是您必须能够做到并采取行动以获取价值。您一直可以执行的轻量级流程比不断拖延或仅将事情添加到积压的重量级流程更有帮助。

解决此问题的一种方法是，一旦用户故事结束，另一对等方便会对代码进行快速检查，以使代码中不会出现任何基本/明显的错误。

但这必须在测试周期之前发生。然后，当您与所有团队一起进行较大的审核时，测试后的代码更改将减少。

从它的声音来看，测试人员不想重新测试，因为测试是一个痛苦/昂贵的过程。

对于试图以敏捷方式工作的团队来说，开发人员和测试人员的测试自动化都是巨大的收获。这样，您可以执行的测试越多，越便宜，越容易且可重现的次数就越多，那么您对测试进行更改的阻力就越小。

根据一些开发人员反馈进行了快速重构吗？按下执行您的回归/烟雾套件的红色大按钮，并进行一次快速手动操作，以检查是否可能出现任何视觉问题。简单！

一旦您处在这样的地方，重新测试就不会繁琐了-这将是第二天性。