# 譯序 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.我想借這個難得的機會感謝一個人：我親愛的女友馬姍姍。在北京的日子里，是她陪伴著我度過每個日日夜夜，照顧我的生活，使我能夠有精力做些喜歡的事（包括翻譯這本書〉。當我埋頭在屏幕前敲打鍵盤時，當我抱著書本冥思苦想時，她無私地容忍了我的癡迷與冷淡。謝謝你，姍姍，我永遠愛你。