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

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

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

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

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

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

评论

#1楼  2008-04-19 02:09 萧寒

有些人过度设计，喜欢自己臆测用户的需求、业务流程，美其名曰“从用户角度出发”，结果程序员花了大量的工作实现之后，提交给用户才发现无法满足需求。
////////

非常之赞同！

#2楼  2008-04-19 08:51 侯垒

个人认为开始应该设计好一点.即使存在问题到重构的时候也不用修改太多的内容.否则在后期的重构过程中代价太大了.

#3楼  2008-04-19 09:06 Justin

“……等到重构的时候……”，这句话已经说明了一切啦！

去年参与一个大单据开发，初看代码大吃一惊，简直是垃圾中的战斗机！我问了一下这个东西的负责人，这样的代码怎么能经得起时间的考验，他的回答跟就是“……等到重构的时候……”，结果后来这个负责人自己没有经得起时间的考验，没有等到这个时候......

我想说的是，重构是工作中随时随地在进行的事情，应该是循序渐进的过程，遇到有不合理的地方就立刻改之。对重构的这种“……等到重构的时候……”的理解简直是一种可怕的无知！

最后，good luck～

#4楼  2008-04-19 09:17 lazylu

第一次写代码的时候,也就是第一次重构的时候.

#5楼  2008-04-19 09:28 随风逝去（叶进）

颇受启发！
ps：陈鹏是lz的名字？ 我一个高中同学也是这个名字！ 巧！

#6楼  2008-04-19 09:33 狼Robot

学习

#7楼  2008-04-19 10:05 GuoYong.Che

本人观点：如需要重构的迭代次数少，就要认真做好需求和设计，否则重构就可能是在一段程序完成后的一周、一天甚至是一个小时后就要进行的事。当然重构的对象也就不是整个项目，而可能是一个类，一个方法等等，意图就是适应需求，提高代码质量、可扩展性、可维护性、可修改性等等，避免需求进一步变化时再犯同样的错误。也就是说，在需求没做好的情况下，重构应和开发同步进行，否则也就没必要那么多的重构。

#8楼  2008-04-19 10:42 阿胜

在开发的同时，就伴随着重构。
但是在不影响开发的情况下。

#9楼  2008-04-19 12:49 ∈鱼杆

非常同意lz的看法，既要事先有所考虑，又要避免过度设计。懂得把握好粒度的设计人员可贵！！！

#10楼  2008-04-19 12:52 小瑞克

深有感触,我也讨厌臆测用户需求的人,一旦猜错了,程序员就要重写,甚至是返工

#11楼  2008-04-19 13:49 Yannic Yang

我比较主张无论什么时候开发，都以用户需求为目标
关键怎么理解这个用户，最大的用户当然是所谓“用户”,而实际上，我们自己（未来的开发团队）也是自己程序的用户
因此只要能满足用户需求就行，同时要保持程序的健壮性，代码的健壮性应当属于用户需求的一部分

满足了以上这些，我就大胆地说 其他事情，等到重构的时候balabala...

#12楼  2008-04-19 14:02 Yannic Yang

另外我觉得重构应该是一个粒度比较细的事情，频繁发生
比如他应该发生在每个程序员每天工作结束前两小时……而不是每个项目结束前两周
对于项目进度来说，重构是编码过程的一部分

#13楼  2008-04-19 15:00 magiclee

“等到重构的时候。。。”
这句话本身就是错误的，开发的过程就是不断重构的过程。如果想先将系统做得差不多再去重构，那他一定是疯了。
而且极限编程那套，适合精英小团队，人人都是高手，都有软件开发质量意识。如果是个大团队，指望团队中每个人都能主动的对代码重构优化，可能吗？

#14楼  2008-04-19 15:55 pavasun [未注册用户]

为什么需要重构，是我们知道有更优的方案（或者实现方法）来替代目前的做法，而这个方案是我们以前所不知或者没有能力去实施的。
“好吧，就这样，等到我们重构的时候......” 本身就是不负责的表现。
“重构”这个词和数据的名称“既有代码的设计”也说明了这一点。

#15楼  2008-04-19 18:57 sinmen

重构在实际的项目上很有可能不需要，当需要重构时，很有可能改项目的架构已经不能满足现有的需要，已经需要推翻先有的架构，重新编写

#16楼  2008-04-20 00:19 Leem

“等到重构的时候。。。”
是阿,这句话本来就是不负责任消极的表现,明显是在敷衍.如果说是在项目开展前,说这样的话,那更是一个严重错误.

#17楼  2008-04-20 02:38 镜涛

呵呵，设计是必须的，可是绝对不能过度，没有不变的设计，任何设计在实现起来总会发现不足。重构应该贯穿于项目的始终，只要发现了代码结构的缺陷就应该进行重构，而不应该到最后。积少成多，最后的重构简直无法进行！！

来自：http://www.cnblogs.com/cp800614/archive/2008/04/19/1160691.html

分类： 软件工程 项目管理 系统架构 软件测试