# 前言 從前,有位咨詢顧問參訪一個幵發項目。系統核心是個class hierarchies (類階層體系〉，顧問看了開發人員所寫的一些代碼。他發現整個體系相當凌亂，上層classes對于classes的運作做了一些假設，下層（繼承〕classes實現這些假設。但是這些假設并不適合所有subclasses，導致覆寫〔overridden）行為非常繁重。只要在superclass做點修改，就可以減少許多覆寫必要。在另一些地方，superclass的某些意圖并未被良好理解，因此其中某些行為在subclasses內重復出現。還有一些地方，好幾個subclasses做相同的事情，其實可以把它們搬到class hierarchy的上層去做。 這位顧問于是建議項目經理看看這些代碼，把它們整理一下，但是經理并不熱衷于此，畢竟程序看上去還可以運行，而且項目面臨很大的進度壓力。于是經理說，晚些時候再抽時間做這些整理工作。 顧問也把他的想法告訴了在這個class hierarchy上工作的程序員，告訴他們可能發生的事情。程序員都很敏銳，馬上就看出問題的嚴重性。他們知道這并不全是他們 的錯，有時候的確需要借助外力才能發現問題。程序員立刻用了一兩天的時間整理好這個class hierarchy，并刪掉了其中一半代碼，功能毫發無損。他們對此十分滿意， 而且發現系統速度變得更快，更容易加入新classws或使用其他classes。 項目經理并不高興。進度排得很緊，許多工作要做。系統必須在幾個月之后發布，許多功能還等著加進去，這些程序員卻白白耗費兩天時間，什么活兒都沒干。原先的代碼運行起來還算正常，他們的新設計顯然有點過于「理論」且過于「無瑕」。項目要出貨給客戶的，是可以有效運行的代碼，不是用以取悅學究們的完美東西。顧問接下來又建議應該在系統的其他核心部分進行這樣的整理工作，這會使整個項目停頓一至二個星期。所有這些工作只是為了讓代碼看起來更漂亮，并不能給系統添加任何新功能。 你對這個故事有什么看法？你認為這個顧問的建議（更進一步整理程序〉是對的嗎？你會因循那句古老的工程諺語嗎：「如果它還可以運行，就不要動它」。 我必須承認我自己有某些偏見，因為我就是那個顧問。六個月之后這個項目宣告失敗，很大的原因是代碼太復雜，無法除錯，也無法獲得可被接受的性能。 后來，項目重新啟動，幾乎從頭開始編寫整個系統，Kent Beck被請去做了顧問。 他做了幾件迥異以往的事，其中最重要的一件就是堅持以持續不斷的重構行為來整理代碼。這個項目的成功，以及重構（refactoring）在這個成功項目中扮演的角色, 促成了我寫這本書的動機，如此一來我就能夠把Kent和其他一些人已經學會的「以 重構方式改進軟件質量」的知識，傳播給所有讀者。 ### 什么是重構？ 所謂重構是這樣一個過程：「在不改變代碼外在行為的前提下，對代碼做出修改，以改進程序的內部結構」。重構是一種有紀律的、經過訓練的、有條不紊的程序整理方法，可以將整理過程中不小心引入錯誤的機率降到最低。本質上說，重構就是「在代碼寫好之后改進它的設計」。 「在代碼寫好之后改進它的設計」？這種說法有點奇怪。按照目前對軟件幵發的理解，我們相信應該先設計而后編碼（coding）。首先得有一個良好的設計，然后才能開始編碼。但是，隨著時間流逝，人們不斷修改代碼，于是根據原先設計所得的系統，整體結構逐漸衰弱。代碼質量慢慢沉淪，編碼工作從嚴謹的工程墮落為胡砍亂劈的隨性行為。 「重構」正好與此相反。哪怕你手上有一個糟糕的設計，甚至是一堆混亂的代碼，你也可以借由重構將它加工成設計良好的代碼。重構的每個步驟都很簡單，甚至簡單過了頭，你只需要把某個值域（field）從一個class移到另一個class，把某些代碼從一個函數（method）拉出來抅成另一個函數，或是在class hierarchy中把某些代碼推上推下就行了。但是，聚沙成塔，這些小小的修改累積起來就可以根本改善設計質量。這和一般常見的「軟件會慢慢腐爛」的觀點恰恰相反。 通過重構（refactoring），你可以找出改變的平衡點。你會發現所謂設計不再是一切動作的前提，而是在整個開發過程中逐漸浮現出來。在系統構筑過程中，你可以 學習如何強化設計；其間帶來的互動可以讓一個程序在開發過程中持續保有良好的設計。 ### 本書有些什么？ 本書是一本重構指南（guide to refactoring），為專業程序員而寫。我的目的是告訴你如何以一種可控制且高效率的方式進行重構。你將學會這樣的重構方式：不引入「臭蟲」（錯誤〉，并且有條不紊地改進程序結構。 按照傳統，書籍應該以一個簡介開頭。盡管我也同意這個原則，但是我發現以概括性的討論或定義來介紹重構，實在不是件容易的事。所以我決定拿一個實例做為開路先鋒。第1章展示一個小程序，其中有些常見的設計缺陷，我把它重構為更合格的面向對象程序。其間我們可以看到重構的過程，以及數個很有用的重構準則。如果你想知道重構到底是怎么回事，這一章不可不讀。 第2章涵蓋重構的一般性原則、定義，以及進行原因，我也大致介紹了重構所存在的一些問題。第3章由Kent Beck介紹如何嗅出代碼中的「壞味道」，以及如何運用重構清除這些壞味道。「測試」在重構中扮演非常重要的角色，第4章介紹如何運用一個簡單的（源碼開放的〕Java測試框架，在代碼中構筑測試環境。 本書的核心部分，重構名錄（catalog of refactoring），從第5章延伸至第12章。 這不是一份全面性的名錄，只是一個起步，其中包括迄今為止我在工作中整理下來 的所有重構準則。每當我想傲點什么——例如Replace Conditional with Polymorphism——的時候，這份名錄就會提醒我如何一步一步安全前進。我希望這是值得你日后一再回顧的部分。 本書介紹了其他人的許多研究成果，最后數章就是由他們之中的幾位所客串寫就。Bill Opdyke在第13章記述他將重構技術應用于商業開發過程中遇到的一些問題。Don Roberts和John Brant在第14章展望重構技術的未來一自動化工具。我把最 一章（第15章）留給重構技術的頂尖大師，Kent Beck。 ### 在Java中運用重構 本書全部以Java撰寫實例。重構當然也可以在其他語言中實現，而且我也希望這本書能夠給其他語言使用者帶來幫助。但我覺得我最好在本書中只使用Java，因為那是我最熟悉的語言。我會不時寫下一些提示，告訴讀者如何在其他語言中進行重構，不過我真心希望看到其他人在本書基礎上針對其他語言寫出更多重構方面的書籍。 為了最大程度地幫助讀者理解我的想法，我不想使用Java語言中特別復雜的部分。所以我避免使用inner class（內嵌類）、reflection(反射機制）、thread（線程〕以及很多強大的Java特性。這是因為我希望盡可能清楚展現重構的核心。 我應該提醒你，這些重構準則并不針對并發（concurrent）或分布式（distributed）編程。那些主題會引出更多重要的事，超越了本書的關心范圍。 ### 誰該閱讀本書 本書瞄準專業程序員，也就是那些以編寫軟件為生的人。書中的示例和討論，涉及大量需要詳細閱讀和理解的代碼。這些例子都以Java完成。之所以選擇Java，因為它是一種應用范圍愈來愈廣的語言，而且任何具備C語言背景的人都可以輕易理解它。Java是一種面向對象語言，而面向對象機制對于重構有很大幫助。 盡管關注對象是代碼，重構（refactoring）對于系統設計也有巨大影響。資深設計師（senior designers）和架構規劃師（architects）也很有必要了解重構原理，并在自己的項目中運用重構技術。最好是由老資格、經驗豐富的開發人員來引入重構技術，因為這樣的人最能夠良好理解重構背后的原理，并加以調整，使之適用于特定 工作領域。如果你使用Java以外的語言，這一點尤其必要，因為你必須把我給出的范例以其他語言改寫。 下面我要告訴你：如何能夠在不遍讀全書的情況下得到最多知識。 - 如果你想知道重構是什么，請閱讀第1章，其中示例會讓你清楚重構過程。 - 如果你想知道為什么應該重構，請閱讀前兩章。它們告訴你「重構是什么」以及「為什么應該重構」。 - 如果你想知道該在什么地方重構，請閱讀第3章。它會告訴你一些代碼特征，這些特征指出「這里需要重構」。 - 如果你想真正（實際〉進行重構，請完整閱讀前四章，然后選擇性地閱讀重構名錄（refactoring catalog）。一開始只需概略瀏覽名錄，看看其中有些什么，不必理解所有細節。一旦真正需要實施某個準則，再詳細閱讀它，讓它來幫助你。名錄是一種具備查詢價值的章節，你也許并不想一次把它全部讀完。此外你還應該讀一讀名錄之后的「客串章節」，特別是第15章。 ### 站在前人的肩膀上 就在本書一開始的此刻，我必須說：這本書讓我欠了一大筆人情債，欠那些在過去十年中做了大量研究工作并開創重構領域的人一大筆債。這本書原本應該由他們之中的某個人來寫，但最后卻是由我這個有時間有精力的人撿了便宜。 重構技術的兩位最早擁護者是Ward Cunningham和Kent Beck。他們很早就把重構作為開發過程的一個核心成份，并且在自己的開發過程中運用它。尤其需要說明的 是，正因為和Kent的合作，才讓我真正看到了重構的重要性，并直接激勵了我寫這一本書。 Ralph Johnson在University of Illinois,Urbana-Champaign（伊利諾斯大學烏爾班納分校）領導了一個小組，這個小組因其對對象技術（object technology）的實際貢獻而聞名。Ralph很早就是重構技術的擁護者，他的一些學生也一直在研究這個課題。 Bill Opdyke的博士論文是重構研究領域的第一份詳細書面成果。John Brant和Don Roberts則早已不滿足于寫文章了，他們寫了一個工具―重構瀏覽器（Refactoring Browser），對Smalltalk程序實施重構工程。 ### 致謝 盡管有這些研究成果幫忙，我還需要很多協助才能寫出這本書。首先，并且也是最重要的，給了我巨大的幫助。Kent在底特律(Detroit)和我談起他正在為Smalltalk Report撰寫一篇論文[Beck, hanoi],從此播下本書的第一顆種子。那篇論文不但讓我開始注意到重構技術，而且我還從中「偷」了許多想法放到本書第1章。Kent也在其他地方幫助我，想出「代碼味道」這個概念的是他，當我遇到各種困難時，鼓勵我的人也是他，常常和我一起工作助我完成這本書的，還是他。我常常忍不住這么想：他完全可以自己把這本書寫的更好。可惜有時間寫書的人是我，所以我也只能希望自己不要做的太差。 寫這本書的時候，我希望能把一些專家經驗直接與你分享，所以我非常感激那些花時間為本書添加材料的人。Kent Beck, John Brant, William Opdyke, 和Don Roberts編撰或合著了本書部分章節。此外Rich Garzaniti和Ron Jeffries幫我添加了一些有用的補充資料。 在任何像這樣的一本書里，作者都會告訴你，技術審閱者提供了巨大的幫助。一如以往，Addison-Wesley的Carter Shanklin和他的優秀團隊是一群精明的審閱者。他們是： - Ken Auer, Rolemodel Software, Inc. - Joshua Bloch, Sun Microsystems, Java Software - John Brant, University of Illinois at Urbana-Champaign - Scott Corley, High Voltage Software, Inc. - Ward Cunningham, Cunningham & Cunningham, Inc. - Stéphane Ducasse - Erich Gamma, Object Technology International, Inc. - Ron Jeffries - Ralph Johnson, University of Illinois - Joshua Kerievsky, Industrial Logic, Inc. - Doug Lea, SUNY Oswego - Sander Tichelaar 他們大大提高了本書的可讀性和準確性，并且至少去掉了一些任何手稿都可能會有的潛在錯誤。在此我要特別感謝兩個效果顯著的建議，這兩個建議讓我的書看上去耳目一新：Ward和Ron建議我以重構前后效果（包括代碼和UML圖）并列的方式寫第1章，Joshua建議我在重構名錄中畫出代碼梗概（code sketches）。 除了正式審閱小組，還有很多非正式的審閱者。這些人或看過我的手稿，或關注我的網頁并留下對我很有幫助的意見。他們是Leif Bennett, Michael Feathers, Michael Finney, Neil Galarneau, Hisham Ghazouli, Tony Gould, John Isner, Brian Marick, Ralf Reissing, John Salt, Mark Swanson, Dave Thomas, 和 Don Wells。我相信肯定還有一些被我遺忘的人，請容我在此向你們道歉，并致上我的謝意。 有一個特別有趣的審閱小組，就是「惡名昭彰」的University of Illinois at Urbana-Champaign讀書小組。由于本書反映出他們的眾多研究成果，我要特別感謝他們的成就。這個小組成員包括Fredrico "Fred" Balaguer, John Brant, Ian Chai, Brian Foote, Alejandra Garrido, Zhijiang "John" Han, Peter Hatch, Ralph Johnson, Songyu "Raymond" Lu, Dragos-Anton Manolescu, Hiroaki Nakamura, James Overturf, Don Roberts, Chieko Shirai, Les Tyrell, 和 Joe Yoder。 任何好想法都需要在嚴酷的生產環境中接受檢驗。我看到重構對于Chrysler Comprehensive Compensation system (C3)系統起了巨大的影響。我要感謝那個團隊的所 有成員：Ann Anderson, Ed Anderi, Ralph Beattie, Kent Beck, David Bryant, Bob Coe, Marie DeArment, Margaret Fronczak, Rich Garzaniti, Dennis Gore, Brian Hacker, Chet Hendrickson, Ron Jeffries, Doug Joppie, David Kim, Paul Kowalsky, Debbie Mueller, Tom Murasky, Richard Nutter, Adrian Pantea, Matt Saigeon, Don Thomas, 和 Don Wells。和他們一起工作所獲得的第一手數據，鞏固了我對重構原理和利益的認識。他們在重構技術上不斷進步，極大程度地幫助我看到：一旦重構技術應用于歷時多年的大型項目中，可以起怎樣的作用。 再—次，我得到了Addison-Wesley 的J. Carter Shanklin和其團隊的幫助，包括Krysia Bebick, Susan Cestone, Chuck Dutton, Kristin Erickson, John Fuller, Christopher Guzikowski, Simone Payment, 和 Genevieve Rajewski。與優秀出版商合作是一個令人愉快的經驗，他們會提供給作者大量的支援和幫助。 談到支援，為一本書付出最多的，總是距離作者最近的人。對我來說，那就是我（現在）的妻子Cindy。感謝你，當我埋首工作的時候，你還是一樣愛我。當我投入書 中，總會不斷想起你。 Martin Fowler Melrose, Massachusetts fowler@acm.org [http://www.martinfowler.com](http://www.martinfowler.com/) [http://www.refactoring.com](http://www.refactoring.com/)