重构，早就不再是“奢侈品”，而是“日用品”。纵然如此，在自己的工作过程中，还是听到很多关于重构的误解。
首先，重构是日常工作。
许多人问过我这样的问题，要不要拿出专门的时间做重构。作为一个程序员，重构就应该和写代码、写测试一样，是我们日常工作的一部分，只要你写代码，就应该重构。特别是当你在做TDD的时候，如果你只写测试，编代码通过，对不起，那根本不叫TDD，那叫测试先行。目前为止，我还没有见过一个程序员，包括我自己在内，写代码是一遍就写得非常整洁，无需重构的。通常都是第一遍写出的代码只能实现功能，然后，把它重构得符合整洁的要求。这里要说的重点是，别讨论专门拿时间做重构，那就是你日常工作的一部分。
我知道为什么会有人问出这样的问题，这就是接下来要说的：重构不是重写。
对于很多人来说，他嘴上说的是重构，心里想的是重写，所以，这事很大，不是一蹴而就的，所以，要专门划拨时间来做。重写，事确实不小。但也是有技巧可言的。我们这里所说的重写，不是整个系统的重写，那专门立项就好了，这里所说的是要调整项目的某个模块，或是某个设计。
一旦设计到调整，实际上是对整个项目组编码风格的一种影响，因为影响比较大，所以，可以考虑以技术债的形式在项目组内部提出来。如果项目组内达成共识，并且业务人员也同意给这件事留出时间，那就可以着手来做了。想要说服业务人员，最好是告诉他们，花多长时间做这件事，能给未来省下多少时间。即便所有人都同意这个调整的方案，真正在实施的时候，我们也需要按照重构的思路来做，这也是需要一些功夫的。
没有测试的重构就是耍流氓。
对于ThoughtWorks内部的项目，测试多还是有保障的，但我周游天下时亲眼见过一些没有测试的巨大代码库，我能说的，赶紧花时间为你要写的代码补一些测试，然后再说重构的事。
具体到动手重构了，标准只有一个：重构可以随时随地停下来，不破坏任何测试。
这话说得很容易，但真要做到可绝非轻而易举。我看到很多大动干戈的修改，中间无法停下，一旦发觉不对，只好推翻重来。我只能说，对于重构，这种做法只是理解了形，并不理解神。站着说话不要疼，事实上，我个人对重构的理解也是看到了有人用小步重构把一段代码逐步改好之后，震惊之余，才理解原来重构应该这样做。要知道，我也曾经是大刀阔斧之辈，那一刻，我皈依于小步重构。
小步重构，是需要刻意练习的。我是花了不少时间去练习，才能做出一些当初见到的重构效果。时至今日，我依然不敢说自己有十足的把握能够小步重构每一段丑陋的代码，内心中总有一种躁动，想一路劈杀过去，只能不断与自己说，慢点，别急。
对于ThoughtWorker而言，内部总是有这样机会见到小步重构，对于外部的人来说，经常参加ThoughtWorks的活动，应该也可以见到这种做法。
重构易，程序员人人知重构，重构难，做好重构者寥寥无几。无它，刻意练习。