中国软件业真的到了该反思的时候了

其实相反，只有迭代的重构才能做出一个良好的系统

每个人都有自己的观点和喜好，这无可厚非。但我个人认为，重构在中国是被误解了，被误解成将系统整个大改一遍才叫重构。在国内研究它的人也很少，据我所知，除了经典的外文引进，目前国内似乎还没有书在探讨它。因此我希望更多的人去关注它，学习它，实践它，使之成为我们手中的利器。

是的，重构是一种习惯，一种设计习惯。从一开始设计软件，就应当采用“编写测试用例->代码实现->通过测试用例->重构->再次通过测试”的步骤，以小步快跑的方式进行软件设计。习惯了这样的设计，你就可以非常容易地设计出优质的代码。一旦习惯了这种设计，你甚至不能够习惯不重构的软件开发。

关于这种设计方式，在书中“12.1 重构是一种习惯”会有代码示例详细描述：
详见我的新书终于要出来啦中的目录部分

关于“小步快跑”可以详见博文：
我们应当改变我们的设计习惯
小步快跑是这样玩的（上）
小步快跑是这样玩的（下）

其实楼上很多人并没有真正理解楼主想表达什么，只是主观地因为书名和楼主的几句地图炮产生一种对心灵鸡汤的逆反心理。
重构这个玩意最终目的不就是为了代码更优雅更简洁，为了高扩展高可用吗。大到把流水账的代码切割分离解耦，小到写代码能用foreach就不要用fori吗。我想这种目标应该是绝大部分程序员的目标，即便人各有志，但至少是应该被认可的。

重构是一件虽未亡羊但需补牢的过程，因为再不补牢就会亡羊了。一个跨度了数年的老系统，最开始的那批人不会去做这么长期的规划，于是流程上没有对代码质量的约束，没有制定规则文档，于是几年下来，不断涌入的新人水平参差不齐，写出的代码五花八门。这种现象几乎是所有大型项目的通病，老外也不例外。linkedin把ror写的系统用nodejs重构，代码量减少了数十倍，我不认为是js的功劳，这绝对是重构的结果。

我觉得楼主想表达的完全不是教大家如何去重构一个数年的老系统，像前面一位兄弟说的，重构老系统涉及到很多政治因素。楼主想告诉大家的是，

我 们 在 上 手 写 代 码 的 时 刻 就 应 符 合 基 本 的 最 佳 实 践。

当然需求永远快于计划，后面的发展你可以不重构，那就让你的系统熵增加的曲线越来越陡吧。

最后说下楼主的书，看了一下试读的4章，主要看了例子，大篇大篇描述性概念性的段落都跳过了。看完的感想，前四章重构的干货不多，偏向引发思考，可能适合入门。看目录后面几章标题感觉干货会多一点，但只是猜测。这书其实是设计模式类书的一个变种，重构的结果不就是良好的设计模式吗。但是我个人觉得这一类书和文章有一个通病，就是例子的设计，都是为了例子而例子。记得有个设计模式书讲工厂模式，就拿出工厂造车的例子，不同颜色的车，不同牌子的车，相同的run方法，相同的按喇叭方法。这容易让读者假孕，以为理解了工厂模式，但事实上还是不会用。因为例子是刻意编造的，没有切肤之感。如果例子能够用大家平时接触到的框架，工具，server等原理源码，或者常用的业务逻辑，不仅让读者理解的更亲切，还能让读者顺带学会更多的知识。
当然这个要求可能高了点，也许大部分人只需要一个简单的例子说明逻辑就行了，至于以后就再靠自己的提高了。

@white_crucifix
感谢你的分享，感觉你是一个特别用心的人

是的，这本书分为基础篇、实践篇与进阶篇。试读部分就是全部的基础篇，是对重构这些基本概念的讲述，采用的实例也会简单但理想化一些。然而实践篇与进阶篇全部都是真实的实例，你看到的就跟你在工作中的情形一模一样。比如，我讲述了一次完整的重构过程，我讲解了一个工资系统如何应对无数次的需求变更，等等。本书的目的就是要落地，让你在工作中真正用起来。

本书在进入进阶篇以后，提出来的全部是十分尖锐的话题，那些实际工作中十分挠头但苦于无法解决的问题。面对问题我们应当去直面而不是逃避，因此我提出了许多的思路去思考与解决问题，比如我们应该什么时候重构、怎样开展测试驱动开发、如何应对一次次需求变更、遗留系统怎样实现自动化测试，等等。

我个人认为，那些大师们都具有深邃的思考，但这并不意味着他们能把它表达清楚。相反，不少大师的著作都没能把他深邃的思考表达清楚，让所有人看明白。所以许多大师的经典著作读起来都比较晦涩，更何况还经历了一次语言的翻译。

这因为如此，大师的著作都需要一批人去深入研究与实践，用深入的实践与专业的笔触，更生动的示例，将大师的思想讲清楚、落地，真正为千千万万人所运用。而这就是我的初衷。

中外无关，我也看过IBM的项目代码（一个案例DEMO的，核心代码肯定看不到）
然后对IBM的评价降了几个等级。

基本所有上了一定年头的项目都是这个鸟样。

软件开发参与人员水平良莠不齐，不是每个人都是重构大师，指望那种上过几个月培训班，设计模式这种设计层面的东西都没接触过的人来做重构完全是个灾难。而项目进度的压力导致代码审查难以实行，很难再抽个人出来一行行的过代码进行重构操作。源码从开始阶段的有序渐渐就会开始失控，到后期项目需求再变更几次，代码修修补补几次结果就是完全的失序。

我认为与其教每个人学会设计模式，学会重构不如在框架层面就限制死这些东西。Spring的伟大之处就在于能够轻易的引导一个哪怕MVC是什么都不知道的人把MVC分离开。当然重构是必要的，但是最好的办法是还是在架构层面就减轻重构的负担

架构的作用范围有限，可应用重构的地方却无处不在，一个团队里推行重构还是很有必要的。