最近正在参与一个我很不看好的项目，一次讨论时听了数遍：“……等到重构的时候……”，于是有感而发。希望对路过的人有所帮助。

    《重构——改善既有代码的设计》相信这本书大家都不陌生。“在不改变代码外在行为的前提下，对代码做出修改，以改进程序内部结构”、“在代码写好之后改进它的设计”也算是耳熟能详。重构不是坏事，但是却不要项目一开始就满嘴“没事，就这样吧，重构的时候我们再……”。真不知大师看到这种结果会如何感慨。

     重构能将糟糕的设计修订为一个良好的设计，但是千万不要忘了，重构也是有成本的。胡乱设计，天马行空之后，自信满满地说：“我们开始重构吧”。如何重构呢？1、老老实实的重新设计、重写代码；2、开始所谓的“重构”，在程序里贴满狗皮膏药。如果你选择的是1，为什么开始时不适当规划一下呢？当项目全部完成后，告诉你的程序员：“我们之前的设计有误，需要好好整理一下（推翻）”你的程序员会有什么感想？2、不管设计是否有失误，我们只管修改出错的代码和对代码进行优化。不断修改和优化的结果一定等价于重新设计。肯定有人说：“没错啊，通过重构，使我们的系统更加高效和稳定了”。这里并不是说喜欢重构有什么问题，只是不应完全让系统依赖重构来完成。

      个人认为项目开发的过程应该是：
         1、了解需求。
         2、进行适当的设计、规划。
         3、依照设计尽快完成系统原型，提交用户或测试部门测试。
         4、根据反馈，修改错误、完善系统。并对现有代码进行重构。
         5、重复4。直到项目完成。
         6、继续走我们的重构之路，使项目中的代码更加精炼、完善，并可为其他项目重用。

      有些人过度设计，喜欢自己臆测用户的需求、业务流程，美其名曰“从用户角度出发”，结果程序员花了大量的工作实现之后，提交给用户才发现无法满足需求。有些人就像上面说的，只讲究重构，却不进行设计、规划。还有些人总强调对象的语义、代码的结构，却忽略了系统的总体架构。每一个问题都可以经过重构，得到解决，但是成本呢？告诉用户：“请您稍等，我们正在进行重构，很快就会有一个健壮的系统提交给您使用了”。对于不懂行的用户，可以慢慢忽悠，但是忽悠一时不能忽悠一世，用户总有那么一天会说“这么简单的东西，那个谁谁谁找人做很快就搞定了。你们怎么这么久，是不是水平有问题啊？”。如果用户也是个内行人怎么办？立马露馅，丢了面子不说，还少了一个经济来源。

      “重构的每个步骤都很简单，甚至简单过了头，你只需要把某个值域（field）从一个class移到另一个class，把某些代码从一个函数（method）拉出来构成另一个函数，或者是在classhierarchy中把某些代码推上推下就行了。但是，这些小小的修改累积起来就可以根本改善设计质量。这和一般常见的‘软件会慢慢腐烂’的观点恰恰相反”我相信，聚沙成塔也必须有一个坚实的基础作为依托。项目初期良好的设计、规划不仅能节约成本，进行重构的时候也会更得心应手。