红色、绿色、重构——为什么要重构? [英] Red, green, refactor - why refactor?

问题描述

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

I am trying to learn TDD and unit testing concepts and I have seen the mantra: "red, green, refactor." I am curious about why should you refactor your code after the tests pass?

这对我来说毫无意义，因为如果测试通过了，那么你为什么要弄乱代码?我还看到 TDD 的口头禅，比如只编写足够的代码来使测试通过".

This makes no sense to me, because if the tests pass, then why are you messing with the code? I also see TDD mantras like "only write enough code to make the test pass."

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

The only reason I could come up with, is if to make the test pass with green, you just sloppily write any old code. You just hack together a solution to get a passing test. Then obviously the code is a mess, so you can clean it up.

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

I found this link on another stackoverflow post which I think confirms the only reason I came up with, that the original code to 'pass' the test can be very simple, even hardcoded: http://blog.extracheese.org/2009/11/how_i_started_tdd.html

推荐答案

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

Usually the first working version of the code - even if not a mess - still can be improved. So you improve it, making it cleaner, more readable, removing duplication, finding better variable/method names etc. This is refactoring. And since you have the tests, you can refactor safely, because the tests will show if you have inadvertently broken something.

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

Note that usually you are not writing code from scratch, but modifying/extending existing code to add/change functionality. And the existing code may not be ready to accommodate the new functionality seamlessly. So the first implementation of the new functionality may look awkward or inconvenient, or you may see that it is difficult to extend further. So you improve the design to incorporate all existing functionality in the simplest, cleanest possible way while still passing all the tests.

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

Your question is a rehash of the age old "if it works, don't fix it". However, as Martin Fowler explains in Refactoring, code can be broken in many different ways. Even if it passes all the tests, it can be hard to understand, thus hard to extend and maintain. Moreover, if it looks sloppy, future programmers will take even less care to keep it tidy, so it will deteriorate ever quicker, and eventually degrades into a complete unmaintainable mess. To prevent this, we refactor to always keep the code clean and tidy as much as possible. If we (or our predecessors) have already let it become messy, refactoring is a huge effort with no obvious immediate benefit for management and stakeholders; thus they can hardly be convinced to support a large scale refactoring in practice. Therefore we refactor in small, even trivial steps, after every code change.

这篇关于红色、绿色、重构——为什么要重构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！