《重构：改善既有代码的设计（第2版）》是一本好书，好到什么程度？这里有一个小故事。

经过这么多年的试错，我发现 最容易抓住听众的办法还是讲故事 。（《程序员的呐喊》）

发现重构

我注意到《重构》这本书是在2002年的时候，距离它出版已经好多年了。之前一直没有读是因为出版它的是那帮搞 UML 的蠢货。我从来都不是它的粉丝。UML在数据库建模上还（可能）有点用，但是在类建模上根本一无是处。我也从来没有在意过布池（Booch）、雅各布森（Jacobsen ）等人的书。

《重构》偏偏就和这样一堆烂书挤在一起，每次看到它我都直接扫过，从不多 停留一秒。别在烂书上浪费时间！

直到2002年冬，我在一家书店里拿起了它。没什么特别的理由，纯粹出于好奇而已。或许我在其他什么地方听到过“重构”这个词吧。它到底是什么意思？字典里根本查不到嘛。

“分解”倒是字典里有的词。你可以分解数字，也可以分解多项式。这个我懂，但是干嘛要再做一次呢？什么叫“再分解” ？（英文中的前缀re—有重新、再次的意思。）

翻开书， 局部变量 是万恶之源 。这或许不是原话，但引入我眼帘的第一段话就在讨论这个。局部变量！？我抓来椅子一屁股坐下来，非常愤怒地往下读。我要看看这个家伙到底是脑子不正常，还是傻瓜一个。

接着一股恐惧袭上心头：他居然说得没错，有理有据。 我最自豪的编程习惯（把中间值保存在局部变量里，作为简单的性能优化）显然是个坏习惯 ，书中明明白白地展示了一点，它解释了我代码里的某些方法为什么会不断膨胀，那就是因为这些方法无法分割，这一点我之前从未想到过。

而这些巨大的方法正是邪恶的温床，那些代码我碰都不想碰。每次不得不去修改它们的时候，黑暗洞穴就会变得愈加邪悲。不管多么不愿意，我还是必须要为之添加新功能，可是那些局部变量已经深入骨髓，像蜘蛛网一样将我困住。

书里解释了为什么它们无法分割，然后提供了斩断它们的利斧——尖锐精准的工具，这些都是很棒的技术，有些甚至还可以自动化，太了不起了。

我越读越快，完全入了迷。

这本书接着告诉我： 不要写注释 。又是疯话！可是它说得的确有道理。我从此也不再写单行注释，开始编写更直白的函数和参数名。

我掏钱买它回家，反复研读。彻底震惊，太天才了。时至今日我也依然这么觉得，虽然那种震撼没有当天那么巨大。但这本书 实乃惊世之作，好似醍醐灌顶 ，令人茅塞顿开。这种事情可不常见。

突然我心里冒出一个尴尬念头： 我怎么没在1998年的时候读这本书呢？这股寒意一下子将我淹没，好像我多年来一直都脱了裤子上班一样。其他人是不是早就读过这本书了？ 我会不会是唯一不知道的人？

第二天我就四处打探。我假装冷静，好像随口提起一样。你读过《重构》吧？没有。每个人都回答没有，大多数人连听都没听过，我问了20个程序员，只有一个读过这本书，不过他什么书都读，所以没什么好意外的。你问他的读后感，他说：

“我读过，那是本好书！”

我顿时松了一口气。既然大多数人都不知道这本书，那我的处境还算安全。 我可以好好研读运用，不用担心别人发现我的代码有多烂。它们只是在某几个方面比较糟糕而已，大部分还是经过精心设计的。各种常见的软件工程规范、设计模式、单元测试、版本控制等我都有用到。它只是在有些地方不太漂亮而已，而我现在已经知道怎么改正了。

重构的现状

今天，所有人都知道《重构》这本书，因为很多IDE包含了书中描述的全部自动化重构技术，甚至还有自己的扩展。

尽管一夜爆红，我却怀疑到底有多少程序员真的读过福勒的这本书，恐怕连部分章节都没读过吧。我觉得大多数程序员到今天也不知道，其实还有很多重构技术是无法自动化的，就连 Java 也无能为力。甚至可以说大部分都是如此。当然这说起来就话长了。

我到今天也不知道他们到底为什么要起“重构”这个名字。我猜可能是比较吸引眼球吧。站在数学的角度上来看，这个词和“分解”勉强有点联系，而重组（reorganization）则太宽泛了，所以“重构”似乎是个好名字。

而有时候能不能取个好名字就能决定一个想法会不会为大众接受。

到今天，重构已经衍生出一整个产业了，它就是一面旗帜。Java IDE的粉丝们都在为之摇旗呐喊。重构工具就好像摆在瓶子里的产品一样。翻开菜单从里面挑一个出来，连地球都能撬起来。

为什么自动化重构在Java阵营里那么流行，在其他语言里却没掀起什么浪花呢？Java说那是因为只有Java才能将代码变换自动化做到这种程度。