串行卧重建10：小设计，而不是大布局

开车的朋友一定要充分了解，驾驶汽车其实是在不断修正汽车的方向流程。在整个驾驶过程中。你必须紧盯前方目不转睛。通过不断地校正方向盘的方向。否则，即使在直的部分可能会偏离车道。那些司机疲劳驾驶，由于睡眠，不再正确方向。车辆将越来越多地偏离航向。在这种情况下，小盹。也能造成车毁人亡的严重后果。

重构与驾车尽管属于全然不同的领域。但其道理是相同的。我们在运用重构方法改动代码的过程中也是常常会犯错的（是人就会犯错）。

犯错就如同偏离了航向一样，因此我们须要不断去矫正。既然是矫正。就必须有一个正确的标准。以及推断是否正确的方法。驾车过程中正确的标准是车辆是否正确行驶在自己的车道上，推断是否正确的方法则是司机朋友的目測。相同地，重构过程中正确的标准是我们的软件是否保持重构前的外部行为，推断的方法则是測试，不论是手工測试还是自己主动化測试。

说起来这个道理非常easy，但问题是你不可能随时都在測试，随时都在矫正，这是不可能的。因此，我们必须要有一个周期，即间隔多长时间測试并矫正一次。周期越长。出大问题的几率就越大，就如同那个睡着了的司机；周期越短，我们所须要付出的成本就越高，由于每进行一次測试都是须要我们付出成本的。周期的长短是须要我们去不断权衡的。

然而。与驾车不同，重构的測试周期还要取决于完毕一次重构并提交代码的周期。由于软件重构总是这样一个过程。首先改动一部分代码，使程序处于一个错误而无法编译执行的状态，然后全然其他全部相关代码的改动，使程序恢复编译可执行的状态。在这个中间状态中。我们是无法測试的。或者说測试是无意义的。仅仅有当相关代码都改动完毕，程序恢复到可执行状态时，測试才变得有意义。

每完毕这样一个过程。我们称之为“完毕一次重构”。而完毕一次重构所花费的时间，是决定我们測试周期的关键因素。

既然如此。我们完毕一次重构究竟要花费多少时间呢？这听起来像是在进行数学推导，但当中的道理就是这样。

决定一次重构花费的时间，是由我们的设计决定的。小设计，我们对代码的改动量少，我们完毕重构的时间就短；大设计，我们对代码的改动量大。我们完毕重构的时间必定长。完毕重构时间长，測试的周期就长，我们发现错误的时间就晚。可能给我们造成的损失必定就大。

大布局为什么我们伤不起？漫长的业务整理。漫长的设计与开发，持续数月之久。在这数月中我们一直都无法评估自己是否正确。

当我们辛苦数月之后才被告知我们犯错了。一切都为时已晚。项目不得不滑入了失败的深渊。这就是前面那个故事系统改造失败的根本原因。

我们说，大布局不能够。但大设计相同不可能。我開始要重构了。我们思考了非常多问题，运用了非常多重构手法。来完毕一次重构。这种重构，代码改动量必定多，重构周期必定长，出错的风险就大。

因此。我们的重构应当是一个一个的小设计。

运用一个重构手法。解决一个问题，完毕一次重构，測试通过。再运用一个重构手法，解决还有一个问题。完毕还有一次重构……如此往复，这就是我在前面所说的“小步快跑”的开发模式。

可是一个我必需要澄清的概念就是，推断是否是大设计的衡量标准并非代码行数。举一个简单样例，我们将一段上千行的代码从一个函数，原封不动地挪到还有一个函数中，而这段代码本身修改非常小，这属不属于大设计呢？显然不属于，由于我们真正修改的代码量不多。后面我们将看到。重构过程会常常进行这样的代码的搬移。

小步快跑让我们每次重构的时候仅仅关注一个问题，运用一个重构手法去解决这一个问题。

这样就使我们每次在改动问题时不会想得太多太远。可是。小步快跑并非要我们全然没有远期规划，不是这种。你能够有远期规划，但这种规划不要做得太早，过早做出这些规划往往easy顾此失彼。先工作一段时间，做一些基础的工作。让我们对系统的总体有了一个比較全面地认识，然后再规划。这样将得到更好的效果。

同一时候，它要求我们对远期的规划不要过细。越最近的计划越细，越远期的规划越粗。

一些人之所以急急匆匆地去做仔细的远期规划，是由于操心今天做出来的东西，到了今后发现不对。得改。所以今天多想想，多规划一些。但问题是，今天规划的就正确吗？假设是当然非常好。而现实经常是否。不对的规划却经常适得其反，让我们陷入一种困境，一种既不能解决当前问题。又不得不为错误设计埋单的困境之中。因此重构的思想却全然打破了这样的思维习惯。重构不惧怕改动。由于它让明天的代码改动是安全的，而不再是走钢丝。

它觉得，今天的任务就是改今天的。即使到了明天会被觉得是错误的，也是明天再改去。

大话重构连载首页：/article/1330396.html

特别说明：希望网友们在转上传文章，它应注明作者或源，为了尊重作者，谢谢！