敏捷实践:代码评审-失败的审查或提出一个问题？

Question

在为期两周的sprint和任务结束时，有一个代码评审，在评审中我们发现一个可以工作、可读的函数，但是它很长，而且有一些代码气味。轻松重构工作。

否则，该任务符合已完成的定义。

我们有两个选择。

• 如果代码检查失败，那么票子就不会在这个sprint中关闭，我们的士气也会受到一点打击，因为我们不能通过它。
• 重构是一小部分工作，并将在下一次冲刺(甚至在它开始之前)作为一个微小的，半点的故事完成。

我的问题是:是否有任何内在的问题或考虑提高票从后面的审查，而不是失败的？

我可以找到的资源和阅读详细代码评论100%或没有，通常，但我发现这通常是不现实的。

Answer 1

是否有任何内在的问题或考虑提高票从后面的审查，而不是失败的？

不是天生的。例如，执行当前的更改可能已经发现了一个问题，但直到现在才知道/明显。失败罚单是不公平的，因为你会因为一些与实际描述的任务无关的事情而失败。

在回顾中，我们发现了一个函数

然而，我推测这里的函数是由当前的变化所增加的。在这种情况下，由于代码没有通过气味测试，票证应该失败。

你会在哪里划线，如果不是在你已经划过的地方？显然，您认为这段代码不够干净，不足以保持当前形式的代码库；那么，为什么要考虑给票证一个通行证呢？

如果代码检查失败，那么票子就不会在这个sprint中关闭，我们的士气也会受到一点打击，因为我们不能通过它。

在我看来，你似乎是在间接地辩称，你试图给这张票一个通行证，以提高团队士气，而不是提高代码库的质量。

如果是这样的话，那么你的优先级就混合在一起了。清洁代码的标准不应该仅仅因为它使团队更快乐而改变。代码的正确性和整洁程度并不取决于团队的情绪。

重构是一小部分工作，并将在下一次冲刺(甚至在它开始之前)作为一个微小的，半点的故事完成。

如果原票证的实现引起代码异味，则应在原票证中进行寻址。只有在代码气味不能直接归因于原始票证(例如，“折断骆驼背的稻草”)的情况下，您才应该创建新的票证。

我可以找到的资源和阅读详细代码评论100%或没有，通常，但我发现这通常是不现实的。

Pass/fail本质上是一种二进制状态，它本身就是全部或根本不存在。

我认为，您在这里所指的更多的是，您将代码评审解释为需要完美的代码或其他失败的代码，但事实并非如此。

代码不应该是完美无瑕的，它应该简单地符合您的团队/公司使用的合理的清洁标准。坚持这一标准是一种二进制选择:它坚持(通过)或不遵守(失败)。

根据您对这个问题的描述，很明显，您认为这不符合预期的代码标准，因此不应该因为诸如团队士气等不可告人的原因而通过。

否则，该任务符合已完成的定义。

如果“它完成了工作”是代码质量的最佳基准，那么我们就不必首先发明干净代码和良好实践的原则--编译器和单元测试已经是我们的自动化评审过程，您将不需要代码评审或样式参数。

Answer 2

在2周的sprint和任务结束时，有一个代码评审，...轻松重构工作。

为什么在冲刺结束时会出现这种情况？一旦您认为代码已经完成(甚至在此之前)，就应该立即进行代码评审。你应该检查你完成的每一个故事的定义。

如果你发现自己在你的演示/短跑评审之前完成了故事，以至于你不能把它作为一个“微小”的任务，那么你需要更好地估计你的工作。是的，那个故事还没讲完。不是因为代码评审，而是因为您没有计划合并代码评审中的更改。这就像估计“测试”所需的时间为零，因为“如果你编程正确，它就会正常工作，对吗？”它不是这样工作的。测试将发现错误，代码评审将发现需要更改的内容。如果不这样做，那将是对时间的极大浪费。

所以总结一下:是的，DoD是二进制的。通过还是失败。代码评审不是二进制的，它应该更像是一个正在进行的任务。你不能失败。这是一个过程，最终完成了。但是如果你没有正确的计划，你就不会及时到达“完成”阶段，并且在冲刺结束时被困在“未完成”的领域。这对士气不好，但你需要在计划中考虑到这一点。

Answer 3

简单:您可以查看更改。否则，您不会检查程序的状态。如果我在一个3,000行函数中修复了一个bug，那么您将检查我的更改是否修复了bug，仅此而已。如果我的更改修复了错误，您可以接受更改。

如果您认为函数太长，则在我的更改被接受之后，您会输入一个更改请求，以缩短或拆分该函数，然后可以根据其重要性对该更改请求进行排序。如果决定团队有更重要的事情要做，那么它将在稍后处理。

如果您能够在代码评审期间决定开发优先级，并且拒绝我的更改，这将是一次尝试决定开发优先级的尝试，这将是荒谬的。

总之，接受代码更改并根据查看更改时看到的内容立即引发票证是绝对可以接受的。在某些情况下，如果更改本身导致了问题，您甚至会这样做:如果现在进行更改比修复问题更重要的话。例如，如果其他代码被阻塞，等待更改，则希望在代码可以改进时解除阻塞。