自从Martin Fowler先生将Refactoring这个概念带到了中国，许多程序员都如同获得了一个通行金牌似的，随时可能提起"Bad Smell"和"重构"，
别动不动拿“重构”说事
。从我的心里来讲，我并不反对重构。但我反对不考虑项目情况的盲目重构。
回想一下，当我们在考虑系统需要重构的时候，我们都考虑了那些因素？特别是大范围的系统级别的重构。由于小型重构涉及面较小，所以下面的很多原因都是针对大型重构进行论述的。
"Bad Smell"也许是我们第一个说出的原因。讲起这个，我仿佛就听到有无限个非常有道理的理由，能从重构者嘴里说出。其中最经常的理由就是：现在不重构，以后也得重构，显然现在重构的代价更小一点。
那么，我们就因此而准备进行重构了吗？
至少我看到很多项目最终都选择了重构。
选择重构的心理，应该和我们程序员的追求完美的个性非常相关。软件不断的进行重构，那么软件的质量就能越好。最关键的是，我们越来越将代码修改得让自己感觉没有遗憾。请允许我这样来分析重构者的心理，但是你不得不承认，往往决定一件事的时候，潜意识很容易战胜理智。
我的问题是，我们重构的时候，真正理性而全面的考虑过吗？
第一、重构的目标是什么？是系统的完美吗？是项目的顺利完成！我想提出一个大家不一定能够接受的标准，任何系统都是可以也是必然存在足够多的缺陷的。真正的成功，是指项目的成功，而并不是指创造一个完美的系统。重构的需要，是项目开发过程中，根据需要而采用的开发方式。只要保障足够程度的软件架构，重构是可以不进行的。
第二、重构的基础具备了吗？在很多成功的经验中，都明确地指出，重构需要有足够的单元测试支持。而且最好是自动化的。目前，很多项目并不具备这样的基础。对于单元测试的问题，我在最近的几篇关于单元测试的博文中也分析过现状和原因。总体说来，真正具备重构的基础的很少。
第三、重构对成本是否考虑周到。我们知道，重构必然会影响到现有项目的进度。这个进度的影响是否是可以接受的？你先不要忙着回答这个问题。能不能接受不是重构者说的，而是市场说的。这个时候，一个三方的沟通会议必不可少。
第四、重构的策略是否制定。重构这件事，并不是简简单单地就去将所有需要重构的地方进行重构。重构的范围越大，这个策略的需求就越高。过分乐观地估计重构的过程，往往是重构失败的重要原因之一。在对项目进行系统级别重构的时候，针对重构的范围规划，进度控制是非常必要的。这个不能要求重构者完全把控。本着适合的人做适合的事的原则，项目经理，应该充分考虑这方面的问题。
其实说到底，不要因为喜欢重构而重构，不要因为重构而重构。在重构之前以及重构的过程之中，我们都必须进行足够的保障，才能保障成功地完成。
评论
#brucenan999 发表于2007-05-23 11:32:57 IP: 221.226.124.*
我同意.严重同意.
项目还是很现实的,首先是要满足的是客户的需求,而不是完美主义者的追求. 不能唯技术论
#winprog 发表于2007-05-23 12:43:58 IP: 221.204.246.*
项目重构？
粒度太太了吧？
根据需求重构就可以了。
如果TDD，重构和项目进度是同时推进的。
反对为了重构而重构已有代码，支持新项目构建中用TDD的方法使用重构。
#apple_snake 发表于2007-05-23 14:15:03 IP: 221.122.38.*
等项目完了再重构已经晚了。
#007pro 发表于2007-05-23 17:20:55 IP: 203.86.46.*
项目重构？呵呵。一定是吃了什么迷幻剂。
#YidingHe 发表于2007-05-23 18:03:03 IP: 220.169.30.*
同意楼主的看法。缺少单元测试的重构如履薄冰，而且项目也不可能一直保持得像开发人员心目中的那么完美。在项目进度和人员水平的制约下，很多时候不得不接受一些 Bad Smell。哪天实在不行了的话，推倒好了，重新赚钱。
#yyw84 发表于2007-05-24 08:08:39 IP: 59.40.43.*
第一点不同意,重构不仅仅是实现代码的优雅,而是让你的项目不至于变成一个没人可以驾驭的大怪物,重构是每时每刻都要进行的事,而不是等到项目全部完成了再来实现完美,
第三点也不同意 ,重构可以有效地降低后期的开发和维护的成本,没有重构的项目最终可能面临夭折
#ai92 发表于2007-05-24 08:52:03 IP: 202.110.224.*
说实话，LZ还是没有理解重构的涵义
重构并不是一定要在项目某个阶段抽出一定的时间专注的去“重构”
这是伪重构，只是为了弥补前一段时间糜烂开发造成的恶果
重构应该存在在项目构建的每一个阶段、每一天、每一个人身上，
管理资料
《别动不动拿“重构”说事》(https://www.unjs.com)。#reaperwu 发表于2007-05-24 09:17:02 IP: 58.61.189.*
那是重构么？部分功能的重新设计吧。
别动不动拿"重构"说事。
#brucenan999 发表于2007-05-24 09:19:09 IP: 221.226.124.*
不同意楼上的说法,重构固然是好,可是重要额外的资源.
一是员工首先要理解重构,需要学习重构,这是需要时间和精力的
二是在项目中进行重构也是需要时间的,如果要编写达到一定覆盖率的单元测试用例,编码的时间起码要延长10%.进行重构则需要更多的时间.
除非你说服客户,愿意再投入一部分的钱让你用来进行重构.我一朋友在日本做项目,客户甚至要求有单独写单元测试用例的开发人员.
所以,除非你遇到这样的大客户.想做重构,真得很难.
#yyw84 发表于2007-05-24 09:47:08 IP: 202.105.108.*
楼上的,你说的第一点说明你入错行了,或许你根本就不是搞技术的,那就更没资格说这了,第二点说明你不理解重构的意义,你就连为什么要重构都不知道,建议搞几个项目再来这说事
#yyw84 发表于2007-05-24 09:49:33 IP: 202.105.108.*
评论发出去后才发现有些偏激了, 今天心情很不好, 大家见谅 -_-#
#ccanan 发表于2007-05-24 13:33:04 IP: 10.9.98.93, 218.*
严重同意yyw84
#buyaowen 发表于2007-05-24 13:58:56 IP: 218.97.252.*
个人认为，重构和设计是密不可分的
#brucenan999 发表于2007-05-24 14:49:38 IP: 221.226.124.*
TO:YYW84
首先说明我不介意,人人都有发表看法的权力.
我想说的是这是看问题角度的问题,LZ是从整个项目的角度来看待这个问题,在考虑项目的成本,进度,质量等方面做出权衡的情况下来表达自己的看法. 而你是从开发人员的技术角度去看待这个问题
#hy_lihuan 发表于2007-05-24 20:48:01 IP: 60.177.236.*
我对lz的想法不以为然,一个重构是一种思想,应该在每一个项目的每一个阶段都应该得到贯穿;项目确实是和用户权衡后需要考虑的不仅仅是质量问题,还有效率和成本,但是做为一个软件公司,赚钱不赚钱的最大区别在于维护软件的成本高低以及软件质量带来的长尾效应,这个才是赚钱的!如果就lz所说的这个意思,项目完成了,在维护中或者二次开发中却要推倒重来或者花费更大的精力,还不如现有阶段就完成一些不是更好吗?
2007-05-24 21:33:33作者回复：
软件当然是质量越高，维护成本越低。但是不要忘了，而且这一点经常被忽略，高质量的产品本身也是需要代价的。在计算是否赚钱的时候，难道就不好考虑这点了吗？如果要软件质量高，除了重构还有很多方法可以做：选全世界最好的架构师架构，请最好的开发人员开发，画最长的时间进行稳定。这三点看上去有点可笑，因为你根本不会这样做，但是不要忘了，这些都是影响软件质量的。重构并不能保障软件质量，因为重构还是依赖于设计的。新的设计纵然比之前的好，但是好到哪里，怎么评价呢？
#platform 发表于2007-05-25 00:11:24 IP: 124.78.123.*
不能为了重构而重构
来自：http://blog.csdn.net/xiammy/archive/2007/05/23/1621690.aspx