红色，绿色，重构--为什么重构？

Question

我正在尝试学习测试驱动开发和单元测试的概念，我已经看到了：“红色，绿色，重构”。我很好奇为什么要在测试通过后重构代码？

这对我来说毫无意义，因为如果测试通过了，为什么还要修改代码呢？我也看到TDD的口头论足，比如“只写足够的代码让测试通过”。

我能想到的唯一原因是，如果要让绿色测试通过，您只需草率地编写任何旧代码。你只需拼凑出一个解决方案，就可以通过测试。那么很明显代码是一团糟的，所以你可以把它清理干净。

编辑：

我在另一个stackoverflow帖子上找到了这个链接，我认为它证实了我想出的唯一原因，那就是‘通过’测试的原始代码可以非常简单，甚至可以是硬编码的：http://blog.extracheese.org/2009/11/how_i_started_tdd.html

Answer 1

通常情况下，代码的第一个工作版本-即使不是一团糟-仍然可以改进。所以你要改进它，使它更干净，更易读，消除重复，找到更好的变量/方法名等等。这就是重构。既然你有测试，你就可以安全地重构，因为测试将显示你是否无意中破坏了某些东西。

请注意，通常您不是从头开始编写代码，而是修改/扩展现有代码以添加/更改功能。并且现有代码可能不能无缝地适应新功能。因此，新功能的第一个实现可能看起来很笨拙或不方便，或者您可能会发现很难进一步扩展。因此，您可以改进设计，以最简单、最干净的方式合并所有现有功能，同时仍然通过所有测试。

你的问题是老生常谈的“如果它有效，就不要修复它”。然而，正如Martin Fowler在Refactoring中所解释的那样，代码可以用许多不同的方式来破坏。即使它通过了所有的测试，它也很难理解，因此很难扩展和维护。此外，如果它看起来草率，未来的程序员将更少注意保持它的整洁，因此它将恶化得更快，最终退化为一个完全不可维护的烂摊子。为了防止这种情况，我们重构以尽可能保持代码的干净和整洁。如果我们(或我们的前辈)已经让它变得混乱，重构是一项巨大的努力，对管理层和利益相关者没有明显的直接好处；因此，在实践中很难说服他们支持大规模重构。因此，在每次代码更改之后，我们都会以很小的甚至是微不足道的步骤进行重构。

Answer 2

我见过这样的咒语：“红色，绿色，重构。”

这不是一个‘咒语’，它是一个惯例。

我也看到了测试驱动开发的咒语，比如“只写足够的代码让测试通过”。

这是一个指导原则。

现在你的问题是：

我能想到的唯一原因是，如果要让绿色测试通过，你只需草率地编写任何旧代码。你只需拼凑出一个解决方案，就可以通过测试。那么很明显代码是一团糟的，所以你可以把它清理干净。

你就快到了。关键在于TDD的“设计”部分。您不仅在编写代码，还在设计您的解决方案。这意味着确切的API可能还不是一成不变的，您的测试可能不会反映最终的设计(因为它还没有完成)。在编写“仅够通过测试”的代码时，您会遇到一些问题，这些问题可能会改变您的想法并指导设计。只有在你有了一些可以工作的代码之后，你才能改进它。

此外，重构步骤涉及整个代码，而不仅仅是您为通过最后一次测试而编写的代码。随着编码的发展，代码的所有部分之间的交互越来越复杂，最好的时机是在代码开始工作时进行重构。

正是因为这个非常早的重构步骤，你不应该担心第一次迭代的质量。这只是一个概念证明，有助于设计。

Answer 3

很难看出操作员的怀疑是不合理的。TDD的工作流程根植于避免过早的设计决策，它强加了大量的成本，如果不排除的话，“裤子的座位”编码可能很快就会变成一个不明智的YAGNI Safari1

这种推迟过早设计的机制是“最小可能的测试”/“最小可能的代码”工作流，旨在防止在通常需要解决或甚至遇到之前“修复”感知到的缺陷或需求的诱惑，即，假设缺陷将(应该？)要在未来的测试用例中解决，直接映射到一个验收标准，该标准反过来又捕获了一个特定的业务目标。

此外，测试开发中的测试应该a)帮助澄清设计需求，b) design2的表面问题，以及c)作为项目资产，捕获并记录应用于特定故事的工作，因此用自定向重构工作替换适当组合的测试不仅排除了测试可能提供的任何洞察力，还拒绝了管理和项目规划者关于实现特定功能的真实成本的信息。3

因此，我建议，一个新的测试用例，专门为在设计中引入额外的需求而构建的，是解决当前测试代码的样式更改之外的任何可察觉到的缺陷的适当方式，而“重构”阶段，无论其用意如何良好，都违背了这一理念，实际上是邀请进行TDD应该防止的那种过早的YAGNI设计探险。我相信Robert Martin对3条规则的版本与这种解释是一致的。4-明目张胆地向当局呼吁

1前面引用的http://blog.extracheese.org/2009/11/how_i_started_tdd.html优雅地证明了将设计决策推迟到最后一刻的价值。(虽然斐波那契序列可能是一个有点人为的例子)。

2请参阅https://blog.thecodewhisperer.com/permalink/how-a-smell-in-the-tests-points-to-a-risk-in-the-design

3向待办事项中添加“技术”或“尖峰”故事(有没有味道)将是确保遵循正式流程、开发工作得到记录和证明的适当方法……如果你不能说服产品负责人添加它，那么你就不应该在它上面花费时间。

4