开车的朋友一定深有体会，驾驶汽车其实就是在不断矫正汽车行驶方向的一个过程。在整个驾驶过程中，你必须全神贯注地紧盯前方，通过方向盘不断矫正方向，否则即使行驶在直线路段也可能偏离车道。那些疲劳驾驶的司机，因为进入睡眠状态，无法再矫正方向，车辆就会越来越偏离航向。这种情况下，即使数秒钟的小盹，也能造成车毁人亡的严重后果。
重构与驾车虽然属于完全不同的领域，但其道理是相同的。我们在运用重构方法修改代码的过程中也是经常会犯错的（是人就会犯错）。犯错就如同偏离了航向一样，因此我们需要不断去矫正。既然是矫正，就必须有一个正确的标准，以及判断是否正确的方法。驾车过程中正确的标准是车辆是否正确行驶在自己的车道上，判断是否正确的方法则是司机朋友的目测。同样地，重构过程中正确的标准是我们的软件是否保持重构前的外部行为，判断的方法则是测试，不论是手工测试还是自动化测试。
说起来这个道理很简单，但问题是你不可能随时都在测试，随时都在矫正，这是不可能的。因此，我们必须要有一个周期，即间隔多长时间测试并矫正一次。周期越长，出大问题的几率就越大，就如同那个睡着了的司机；周期越短，我们所需要付出的成本就越高，因为每进行一次测试都是需要我们付出成本的。周期的长短是需要我们去不断权衡的。
然而，与驾车不同，重构的测试周期还要取决于完成一次重构并提交代码的周期。因为软件重构总是这样一个过程，首先修改一部分代码，使程序处于一个错误而无法编译运行的状态，然后完全其它所有相关代码的修改，使程序恢复编译可运行的状态。在这个中间状态中，我们是无法测试的，或者说测试是无意义的。只有当相关代码都修改完成，程序恢复到可运行状态时，测试才变得有意义。每完成这样一个过程，我们称之为“完成一次重构”。而完成一次重构所花费的时间，是决定我们测试周期的关键因素。
既然如此，我们完成一次重构到底要花费多少时间呢？这听起来像是在进行数学推导，但其中的道理就是这样。决定一次重构花费的时间，是由我们的设计决定的。小设计，我们对代码的修改量少，我们完成重构的时间就短；大设计，我们对代码的修改量大，我们完成重构的时间必然长。完成重构时间长，测试的周期就长，我们发现错误的时间就晚，可能给我们造成的损失必然就大。
大布局为什么我们伤不起？漫长的业务整理，漫长的设计与开发，持续数月之久。在这数月中我们一直都无法评估自己是否正确。当我们辛苦数月之后才被告知我们犯错了，一切都为时已晚，项目不得不滑入了失败的深渊。这就是前面那个故事系统改造失败的根本原因。
我们说，大布局不可以，但大设计同样不可能。我开始要重构了，我们思考了很多问题，运用了很多重构手法，来完成一次重构。这样的重构，代码修改量必然多，重构周期必然长，出错的风险就大。因此，我们的重构应当是一个一个的小设计。运用一个重构手法，解决一个问题，完成一次重构，测试通过，再运用一个重构手法，解决另一个问题，完成另一次重构……如此往复，这就是我在前面所说的“小步快跑”的开发模式。
但是一个我必须要澄清的概念就是，判断是否是大设计的衡量标准并不是代码行数。举一个简单例子，我们将一段上千行的代码从一个函数，原封不动地挪到另一个函数中，而这段代码本身改动很小，这属不属于大设计呢？显然不属于，因为我们真正修改的代码量不多。后面我们将看到，重构过程会经常进行这种代码的搬移。
小步快跑让我们每次重构的时候只关注一个问题，运用一个重构手法去解决这一个问题。这样就使我们每次在修改问题时不会想得太多太远。但是，小步快跑并不是要我们完全没有远期规划，不是这样的。你可以有远期规划，但这种规划不要做得太早，过早做出这些规划往往容易顾此失彼。先工作一段时间，做一些基础的工作，让我们对系统的整体有了一个比较全面地认识，然后再规划，这样将得到更好的效果。
同时，它要求我们对远期的规划不要过细。越近期的计划越细，越远期的规划越粗。一些人之所以急急匆匆地去做细致的远期规划，是因为担心今天做出来的东西，到了今后发现不对，得改，所以今天多想想，多规划一些。但问题是，今天规划的就正确吗？如果是当然很好，而现实常常是否。不正确的规划却常常适得其反，让我们陷入一种困境，一种既不能解决当前问题，又不得不为错误设计埋单的困境之中。因此重构的思想却完全打破了这种思维习惯。重构不惧怕修改，因为它让明天的代码修改是安全的，而不再是走钢丝。它认为，今天的任务就是改今天的，即使到了明天会被认为是错误的，也是明天再改去。
大话重构连载首页：http://www.cnblogs.com/mooodo/p/talkAboutRefactoringHome.html
特别说明：希望网友们在转载本文时，应当注明作者或出处，以示对作者的尊重，谢谢！