unit-testing - 红色、绿色、重构——为什么要重构？

Question

我正在尝试学习 TDD 和单元测试概念，并且我看到了口头禅:“红色、绿色、重构”。我很好奇为什么要在测试通过后重构代码？

这对我来说毫无意义，因为如果测试通过了，那你为什么要弄乱代码？我还看到 TDD 的咒语，例如“只编写足够的代码来使测试通过”。

我能想出的唯一原因是，如果要使测试通过绿色，您只需草率地编写任何旧代码即可。您只需拼凑出一个解决方案即可通过测试。那么显然代码是乱七八糟的，所以你可以清理它。

编辑:

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

Answer 1

通常代码的第一个工作版本——即使不是一团糟——仍然可以改进。所以你改进它，让它更干净、更易读、删除重复、找到更好的变量/方法名称等。这就是重构。由于您进行了测试，因此您可以安全地进行重构，因为测试会显示您是否无意中破坏了某些东西。

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

您的问题是对古老“如果有效，请不要修复” 的陈词滥调。然而，正如 Martin Fowler 在重构中解释的那样，代码可以通过许多不同的方式被破坏。即使它通过了所有测试，也可能难以理解，因此难以扩展和维护。此外，如果它看起来马虎， future 的程序员将更不会注意保持它的整洁，因此它会更快地恶化，并最终退化为完全无法维护的困惑。为了防止这种情况，我们重构以尽可能始终保持代码干净整洁。如果我们(或我们的前任)已经让它变得困惑，那么重构是一项巨大的工作，对管理层和利益相关者没有明显的直接好处；因此，很难说服他们在实践中支持大规模重构。因此，在每次代码更改后，我们都会以小的、甚至是微不足道的步骤进行重构。