# 译序 by 熊节 **重构的生活方式** 还记得那一天，当我把《重构》的全部译稿整理完毕，发送给侯老师时，心里竟然不经意地有了一丝惘然。我是一只习惯的动物，总是安于一种习惯的生活方式。在那之前的很长一段时间里，习惯了每天晚上翻译这本书，习惯了随手把问题写成mail发给Martin Fowler先生，习惯了阅读Martin及时而耐心的回信，习惯了在那本复印的、略显粗糙的书本上勾勾画画，习惯了躺在床上咀嚼回味那些带有一点点英国绅士矜持口吻的词句，习惯了背后嗡嗡作响的老空调…当深秋的风再次染红了香山的叶，这种生活方式也就告一段落了。 只有几位相熟的朋友知道我在翻译这本书，他们不太明白为什么常把经济学挂在嘴边的我会乐于帮侯老师翻译这本书一我自己也不明白，大概只能用爱好来解释吧。既然已经衣食无忧，既然还有一点属于自己的时间，能够亲手把这本《重构》翻译出来，也算是给自己的一个交代。 第一次听到「重构」这个词，是在2001年10月。在当时，它的思想足以令我感到震撼。软件自有其美感所在。软件工程希望建立完美的需求与设计，按照既有的规范编写标准划一的代码，这是结构的美；快速迭代和RAD颠覆「全知全能」的神话，用近乎刀劈斧砍（crack）的方式解决问题，在混沌的循环往复中实现需求，这是解构的美；而Kent Beck与Martin Fowler两人站在一起，XP那敏捷而又严谨的方法论演绎了重构的美―我不知道是谁最初把refactoring一词翻译为「重构」，或许无心插柳，却成了点睛之笔。 我一直是设计模式的爱好者。曾经在我的思想中，软件开发应该有一个「理想国」一 当然，在这个理想国维持着完美秩序的，不是哲学家，而是模式。设计模式给我们的，不仅仅是一些问题的解决方案，更有追求完美「理型」的渴望。但是，Joshua Kerievsky在那篇著名的《模式与XP》〔收录于《极限编程研究》一书）中明白地指出：在设计前期使用模式常常导致过度工程（over-engineering)。这是一个残酷的现实，单凭对完美的追求无法写出实用的代码，而「实用」是软件压倒一切的要素。从一篇《停止过度工程》开始，Joshua撰写了 "Refactoring to Patterns"系列文章。 这位犹太人用他民族性的睿智头脑，敏锐地发现了软件的后结构主义道路。而让设 计模式在飞速变化的Internet时代重新闪现光辉的，又是重构的力量。 在一篇流传甚广的帖子里，有人把《重构》与《设计模式》并列为「Java行业的圣经」。在我看来这种并列其实并不准确。实际上，尽管我如此喜爱这本《重构》，但自从完成翻译之后，我再也没有读过它。不，不是因为我已经对它烂熟于心，而是因为重构已经变成了我的另一种生活方式，变成了我每天的「面包与黄油」，变成了我们整个团队的空气与水，以至于无须再到书中寻找任何「神谕』。而《设计模式》，我倒是放在手边时常翻阅，因为总是记得不那么真切。 所以，在你开始阅读本书之前，我有两个建议要给你：首先，把你的敬畏扔到大西洋里去，对于即将变得像空气与水一样普通的技术，你无须对它敬畏；其次，找到合适的开发工具（如果你和我一样是Java人，那么这个「合适的工具」就是Eclipse），学会使用其中的自动测试和重构功能，然后再尝试使用本书介绍的任何技术。懒惰是程序员的美德之一，绝不要因为这本书让你变得勤快。 最后，即使你完全掌握了这本书中的所有东西，也千万不要跟别人吹嘘。在我们的团队里，程序员常常会说：『如果没有单元测试和重构，我没办法写代码。』 好了，感谢你耗费一点点的时间来倾听我现在对重构、对这本《重构》的想法。Martin Fowler经常说，花一点时间来重构是值得的，希望你会觉得花一点时间看我的文字也是值得的。 熊节2003年6月11日 夜杭州 P.S.我想借这个难得的机会感谢一个人：我亲爱的女友马姗姗。在北京的日子里，是她陪伴着我度过每个日日夜夜，照顾我的生活，使我能够有精力做些喜欢的事（包括翻译这本书〉。当我埋头在屏幕前敲打键盘时，当我抱着书本冥思苦想时，她无私地容忍了我的痴迷与冷淡。谢谢你，姗姗，我永远爱你。