讨论：重构的前提是不是 TDD

我觉得很重要的一个点是重构的目的，其实我们关注的是重构的结果。重构的目的是什么呢？是不是使用一些方法、技巧达到了重构的目的，就应该算是重构呢？如果按照重构的定义，答案是不一定了。但是从结果看，我们是达到了重构的目的。

所以我比较在意，重构的定义就像它的原则，违反这个原则会带来什么副作用呢？遵从这个原则又会让我们重构过程中带来什么好处呢？



刚开始我还觉得加深地基也应该算是增加功能嘛，但是回头想想：我们是看不到地基的，因此无论如何该地基，外部行为一定不会改变。

我觉得测试用例是检验重构后的代码是否合格的标准，如果没有测试用例对代码有效性进行验证，那么重构就没有意义。至于自动化测试还是手工测试倒没有那么重要，只是自动化测试能提高效率，如果用手工测试重构的后的代码而延误了进度或导致开发人员加班，那还不如不重构。
    重构是在不改变代码外在行为的前提下对代码进行整理和修改，外在行为从哪来?就是从测试用例来，当然，也可以用上百页的文档去描述那些行为，但测试用例还是最好的行为描述工具，因为它能被很快的验证。
    Martin Fowler说过：“本质上说，重构就是在代码写好之后改进它的设计”，按照TDD的步骤去走，你会发现整个系统或者子系统的设计在慢慢成形，慢慢生长，而控制这个生长过程不出现错误或扭曲的东西就是测试用例，如果连这个都没有，那么系统的设计会走向畸形。
    对代码的修改不能都称为重构，如果修改代码导致外在行为的更改，必须有验证这一行为的测试用例。
    重构不一定要配合TDD使用，也可以先做好设计，再写代码，然后测试，测试后再对代码进行重构，同样可以获得优化代码和优化设计的效果