java代码重构
2019獨角獸企業重金招聘Python工程師標準>>>
重構（Refactoring）就是在不改變軟件現有功能的基礎上，通過調整程序代碼改善軟件的質量、性能，使其程序的設計模式和架構更趨合理，提高軟件的擴展性和維護性。
也許有人會問，為什么不在項目開始時多花些時間把設計做好，而要以后花時間來重構呢？要知道一個完美得可以預見未來任何變化的設計，或一個靈活得可以容納任何擴展的設計是不存在的。系統設計人員對即將著手的項目往往只能從大方向予以把控，而無法知道每個細枝末節，其次永遠不變的就是變化，提出需求的用戶往往要在軟件成型后，始才開始"品頭論足"，系統設計人員畢竟不是先知先覺的神仙，功能的變化導致設計的調整再所難免。所以"測試為先，持續重構"作為良好開發習慣被越來越多的人所采納，測試和重構像黃河的護堤，成為保證軟件質量的法寶。
一、為什么要重構（Refactoring）
?????? 在不改變系統功能的情況下，改變系統的實現方式。為什么要這么做？投入精力不用來滿足客戶關心的需求，而是僅僅改變了軟件的實現方式，這是否是在浪費客戶的投資呢？
?????? 重構的重要性要從軟件的生命周期說起。軟件不同與普通的產品，他是一種智力產品，沒有具體的物理形態。一個軟件不可能發生物理損耗，界面上的按鈕永遠不會因為按動次數太多而發生接觸不良。那么為什么一個軟件制造出來以后，卻不能永遠使用下去呢？
?????? 對軟件的生命造成威脅的因素只有一個：需求的變更。一個軟件總是為解決某種特定的需求而產生，時代在發展，客戶的業務也在發生變化。有的需求相對穩定一些，有的需求變化的比較劇烈，還有的需求已經消失了，或者轉化成了別的需求。在這種情況下，軟件必須相應的改變。
?????? 考慮到成本和時間等因素，當然不是所有的需求變化都要在軟件系統中實現。但是總的說來，軟件要適應需求的變化，以保持自己的生命力。
?????? 這就產生了一種糟糕的現象：軟件產品最初制造出來，是經過精心的設計，具有良好架構的。但是隨著時間的發展、需求的變化，必須不斷的修改原有的功能、追加新的功能，還免不了有一些缺陷需要修改。為了實現變更，不可避免的要違反最初的設計構架。經過一段時間以后，軟件的架構就千瘡百孔了。bug越來越多，越來越難維護，新的需求越來越難實現，軟件的構架對新的需求漸漸的失去支持能力，而是成為一種制約。最后新需求的開發成本會超過開發一個新的軟件的成本，這就是這個軟件系統的生命走到盡頭的時候。
?????? 重構就能夠最大限度的避免這樣一種現象。系統發展到一定階段后，使用重構的方式，不改變系統的外部功能，只對內部的結構進行重新的整理。通過重構，不斷的調整系統的結構，使系統對于需求的變更始終具有較強的適應能力。
通過重構可以達到以下的目標：
·持續偏糾和改進軟件設計
重構和設計是相輔相成的，它和設計彼此互補。有了重構，你仍然必須做預先的設計，但是不必是最優的設計，只需要一個合理的解決方案就夠了，如果沒有重構、程序設計會逐漸腐敗變質，愈來愈像斷線的風箏，脫韁的野馬無法控制。重構其實就是整理代碼，讓所有帶著發散傾向的代碼回歸本位。
·使代碼更易為人所理解
Martin Flower在《重構》中有一句經典的話："任何一個傻瓜都能寫出計算機可以理解的程序，只有寫出人類容易理解的程序才是優秀的程序員。"對此，筆者感觸很深，有些程序員總是能夠快速編寫出可運行的代碼，但代碼中晦澀的命名使人暈眩得需要緊握坐椅扶手，試想一個新兵到來接手這樣的代碼他會不會想當逃兵呢？
軟件的生命周期往往需要多批程序員來維護，我們往往忽略了這些后來人。為了使代碼容易被他人理解，需要在實現軟件功能時做許多額外的事件，如清晰的排版布局，簡明扼要的注釋，其中命名也是一個重要的方面。一個很好的辦法就是采用暗喻命名，即以對象實現的功能的依據，用形象化或擬人化的手法進行命名，一個很好的態度就是將每個代碼元素像新生兒一樣命名，也許筆者有點命名偏執狂的傾向，如能榮此雅號，將深以此為幸。
對于那些讓人充滿迷茫感甚至誤導性的命名，需要果決地、大刀闊斧地整容，永遠不要手下留情！
·幫助發現隱藏的代碼缺陷
孔子說過：溫故而知新。重構代碼時逼迫你加深理解原先所寫的代碼。筆者常有寫下程序后，卻發生對自己的程序邏輯不甚理解的情景，曾為此驚悚過，后來發現這種癥狀居然是許多程序員常患的"感冒"。當你也發生這樣的情形時，通過重構代碼可以加深對原設計的理解，發現其中的問題和隱患，構建出更好的代碼。
·從長遠來看，有助于提高編程效率
當你發現解決一個問題變得異常復雜時，往往不是問題本身造成的，而是你用錯了方法，拙劣的設計往往導致臃腫的編碼。
改善設計、提高可讀性、減少缺陷都是為了穩住陣腳。良好的設計是成功的一半，停下來通過重構改進設計，或許會在當前減緩速度，但它帶來的后發優勢卻是不可低估的。
二、何時著手重構（Refactoring）
新官上任三把火，開始一個全新的項目時，程序員往往也會燃起三把火：緊鑼密鼓、腳不停蹄、加班加點，一支聲勢浩大的千軍萬"碼"夾裹著程序員激情和扣擊鍵盤的鳴金奮力前行，勢如破竹，攻城掠地，直指"黃龍府"。
開發經理是這支浩浩湯湯代碼隊伍的統帥，他負責這支隊伍的命運，當齊恒公站在山頂上看到管仲訓練的隊伍整齊劃一地前進時，他感嘆說"我有這樣一支軍隊哪里還怕沒有勝利呢？"。但很遺憾，你手中的這支隊伍原本只是散兵游勇，在前進中招兵買馬，不斷壯大，所以隊伍變形在所難免。當開發經理發覺隊伍變形時，也許就是克制住攻克前方山頭的誘惑，停下腳步整頓隊伍的時候了。
Kent Beck提出了"代碼壞味道"的說法，和我們所提出的"隊伍變形"是同樣的意思，隊伍變形的信號是什么呢？以下列述的代碼癥狀就是"隊伍變形"的強烈信號：
·代碼中存在重復的代碼
中國有118 家整車生產企業，數量幾乎等于美、日、歐所有汽車廠家數之和，但是全國的年產量卻不及一個外國大汽車公司的產量。重復建設只會導致效率的低效和資源的浪費。
程序代碼更是不能搞重復建設，如果同一個類中有相同的代碼塊，請把它提煉成類的一個獨立方法，如果不同類中具有相同的代碼，請把它提煉成一個新類，永遠不要重復代碼。
·過大的類和過長的方法
過大的類往往是類抽象不合理的結果，類抽象不合理將降低了代碼的復用率。方法是類王國中的諸侯國，諸侯國太大勢必動搖中央集權。過長的方法由于包含的邏輯過于復雜，錯誤機率將直線上升，而可讀性則直線下降，類的健壯性很容易被打破。當看到一個過長的方法時，需要想辦法將其劃分為多個小方法，以便于分而治之。
·牽一毛而需要動全身的修改
當你發現修改一個小功能，或增加一個小功能時，就引發一次代碼地震，也許是你的設計抽象度不夠理想，功能代碼太過分散所引起的。
·類之間需要過多的通訊
A類需要調用B類的過多方法訪問B的內部數據，在關系上這兩個類顯得有點狎昵，可能這兩個類本應該在一起，而不應該分家。
·過度耦合的信息鏈
"計算機是這樣一門科學，它相信可以通過添加一個中間層解決任何問題"，所以往往中間層會被過多地追加到程序中。如果你在代碼中看到需要獲取一個信息，需要一個類的方法調用另一個類的方法，層層掛接，就象輸油管一樣節節相連。這往往是因為銜接層太多造成的，需要查看就否有可移除的中間層，或是否可以提供更直接的調用方法。
·各立山頭干革命
如果你發現有兩個類或兩個方法雖然命名不同但卻擁有相似或相同的功能，你會發現往往是因為開發團隊成員協調不夠造成的。筆者曾經寫了一個頗好用的字符串處理類，但因為沒有及時通告團隊其他人員，后來發現項目中居然有三個字符串處理類。革命資源是珍貴的，我們不應各立山頭干革命。
·不完美的設計
在筆者剛完成的一個比對報警項目中，曾安排阿朱開發報警模塊，即通過Socket向指定的短信平臺、語音平臺及客戶端報警器插件發送報警報文信息，阿朱出色地完成了這項任務。后來用戶又提出了實時比對的需求，即要求第三方系統以報文形式向比對報警系統發送請求，比對報警系統接收并響應這個請求。這又需要用到Socket報文通訊，由于原來的設計沒有將報文通訊模塊獨立出來，所以無法復用阿朱開發的代碼。后來我及時調整了這個設計，新增了一個報文收發模塊，使系統所有的對外通訊都復用這個模塊，系統的整體設計也顯得更加合理。
每個系統都或多或少存在不完美的設計，剛開始可能注意不到，到后來才會慢慢凸顯出來，此時唯有勇于更改才是最好的出路。
·缺少必要的注釋
雖然許多軟件工程的書籍常提醒程序員需要防止過多注釋，但這個擔心好象并沒有什么必要。往往程序員更感興趣的是功能實現而非代碼注釋，因為前者更能帶來成就感，所以代碼注釋往往不是過多而是過少，過于簡單。人的記憶曲線下降的坡度是陡得嚇人的，當過了一段時間后再回頭補注釋時，很容易發生"提筆忘字，愈言且止"的情形。
曾在網上看到過微軟的代碼注釋，其詳盡程度讓人嘆為觀止，也從中體悟到了微軟成功的一個經驗。
三、重構（Refactoring）的難題
?????? 學習一種可以大幅提高生產力的新技術時，你總是難以察覺其不適用的場合。通常你在一個特定場景中學習它，這個場景往往是個項目。這種情況下你很難看出什么會造成這種新技術成效不彰或甚至形成危害。十年前，對象技術（object tech.）的情況也是如此。那時如果有人問我「何時不要使用對象」，我很難回答。并非我認為對象十全十美、沒有局限性 — 我最反對這種盲目態度，而是盡管我知道它的好處，但確實不知道其局限性在哪兒。
?????? 現在，重構的處境也是如此。我們知道重構的好處，我們知道重構可以給我們的工作帶來垂手可得的改變。但是我們還沒有獲得足夠的經驗，我們還看不到它的局限性。
這一小節比我希望的要短。暫且如此吧。隨著更多人學會重構技巧，我們也將對它有更多了解。對你而言這意味：雖然我堅決認為你應該嘗試一下重構，獲得它所提供的利益，但在此同時，你也應該時時監控其過程，注意尋找重構可能引入的問題。請讓我們知道你所遭遇的問題。隨著對重構的了解日益增多，我們將找出更多解決辦法，并清楚知道哪些問題是真正難以解決的。
?????? 數據庫（Databases）
?????? 「重構」經常出問題的一個領域就是數據庫。絕大多數商用程序都與它們背后的database schema（數據庫表格結構）緊密耦合（coupled）在一起，這也是database schema如此難以修改的原因之一。另一個原因是數據遷移（migration）。就算你非常小心地將系統分層（layered），將database schema和對象模型（object model）間的依賴降至最低，但database schema的改變還是讓你不得不遷移所有數據，這可能是件漫長而煩瑣的工作。
?????? 在「非對象數據庫」（nonobject databases）中，解決這個問題的辦法之一就是：在對象模型（object model）和數據庫模型（database model）之間插入一個分隔層（separate layer），這就可以隔離兩個模型各自的變化。升級某一模型時無需同時升級另一模型，只需升級上述的分隔層即可。這樣的分隔層會增加系統復雜度，但可以給你很大的靈活度。如果你同時擁有多個數據庫，或如果數據庫模型較為復雜使你難以控制，那么即使不進行重構，這分隔層也是很重要的。
?????? 你無需一開始就插入分隔層，可以在發現對象模型變得不穩定時再產生它。這樣你就可以為你的改變找到最好的杠桿效應。
?????? 對開發者而言，對象數據庫既有幫助也有妨礙。某些面向對象數據庫提供不同版本的對象之間的自動遷移功能，這減少了數據遷移時的工作量，但還是會損失一定時間。如果各數據庫之間的數據遷移并非自動進行，你就必須自行完成遷移工作，這個工作量可是很大的。這種情況下你必須更加留神classes內的數據結構變化。你仍然可以放心將classes的行為轉移過去，但轉移值域（field）時就必須格外小心。數據尚未被轉移前你就得先運用訪問函數（accessors）造成「數據已經轉移」的假象。一旦你確定知道「數據應該在何處」時，就可以一次性地將數據遷移過去。這時惟一需要修改的只有訪問函數（accessors），這也降低了錯誤風險。
?????? 修改接口（Changing Interfaces）
?????? 關于對象，另一件重要事情是：它們允許你分開修改軟件模塊的實現（implementation）和接口（interface）。你可以安全地修改某對象內部而不影響他人，但對于接口要特別謹慎 — 如果接口被修改了，任何事情都有可能發生。
?????? 一直對重構帶來困擾的一件事就是：許多重構手法的確會修改接口。像Rename Method（273）這么簡單的重構手法所做的一切就是修改接口。這對極為珍貴的封裝概念會帶來什么影響呢？
?????? 如果某個函數的所有調用動作都在你的控制之下，那么即使修改函數名稱也不會有任何問題。哪怕面對一個public函數，只要能取得并修改其所有調用者，你也可以安心地將這個函數易名。只有當需要修改的接口系被那些「找不到，即使找到也不能修改」的代碼使用時，接口的修改才會成為問題。如果情況真是如此，我就會說：這個接口是個「已發布接口」（published interface）— 比公開接口（public interface）更進一步。接口一旦發行，你就再也無法僅僅修改調用者而能夠安全地修改接口了。你需要一個略為復雜的程序。
?????? 這個想法改變了我們的問題。如今的問題是：該如何面對那些必須修改「已發布接口」的重構手法？
?????? 簡言之，如果重構手法改變了已發布接口（published interface），你必須同時維護新舊兩個接口，直到你的所有用戶都有時間對這個變化做出反應。幸運的是這不太困難。你通常都有辦法把事情組織好，讓舊接口繼續工作。請盡量這么做：讓舊接口調用新接口。當你要修改某個函數名稱時，請留下舊函數，讓它調用新函數。千萬不要拷貝函數實現碼，那會讓你陷入「重復代碼」（duplicated code）的泥淖中難以自拔。你還應該使用Java提供的 deprecation（反對）設施，將舊接口標記為 "deprecated"。這么一來你的調用者就會注意到它了。
?????? 這個過程的一個好例子就是Java容器類（collection classes）。Java 2的新容器取代了原先一些容器。當Java 2容器發布時，JavaSoft花了很大力氣來為開發者提供一條順利遷徙之路。
?????? 「保留舊接口」的辦法通常可行，但很煩人。起碼在一段時間里你必須建造（build）并維護一些額外的函數。它們會使接口變得復雜，使接口難以使用。還好我們有另一個選擇：不要發布（publish）接口。當然我不是說要完全禁止，因為很明顯你必得發布一些接口。如果你正在建造供外部使用的APIs，像Sun所做的那樣，肯定你必得發布接口。我之所以說盡量不要發布，是因為我常常看到一些開發團隊公開了太多接口。我曾經看到一支三人團隊這么工作：每個人都向另外兩人公開發布接口。這使他們不得不經常來回維護接口，而其實他們原本可以直接進入程序庫，徑行修改自己管理的那一部分，那會輕松許多。過度強調「代碼擁有權」的團隊常常會犯這種錯誤。發布接口很有用，但也有代價。所以除非真有必要，別發布接口。這可能意味需要改變你的代碼擁有權觀念，讓每個人都可以修改別人的代碼，以運應接口的改動。以搭檔（成對）編程（Pair Programming）完成這一切通常是個好主意。
?????? 不要過早發布（published）接口。請修改你的代碼擁有權政策，使重構更順暢。
?????? Java之中還有一個特別關于「修改接口」的問題：在throws子句中增加一個異常。這并不是對簽名式（signature）的修改，所以你無法以delegation（委托手法）隱藏它。但如果用戶代碼不作出相應修改，編譯器不會讓它通過。這個問題很難解決。你可以為這個函數選擇一個新名字，讓舊函數調用它，并將這個新增的checked exception（可控式異常）轉換成一個unchecked exception（不可控異常）。你也可以拋出一個unchecked異常，不過這樣你就會失去檢驗能力。如果你那么做，你可以警告調用者：這個unchecked異常日后會變成一個checked異常。這樣他們就有時間在自己的代碼中加上對此異常的處理。出于這個原因，我總是喜歡為整個package定義一個superclass異常（就像java.sql的SQLException），并確保所有public函數只在自己的throws子句中聲明這個異常。這樣我就可以隨心所欲地定義subclass異常，不會影響調用者，因為調用者永遠只知道那個更具一般性的superclass異常。
?????? 難以通過重構手法完成的設計改動
?????? 通過重構，可以排除所有設計錯誤嗎？是否存在某些核心設計決策，無法以重構手法修改？在這個領域里，我們的統計數據尚不完整。當然某些情況下我們可以很有效地重構，這常常令我們倍感驚訝，但的確也有難以重構的地方。比如說在一個項目中，我們很難（但還是有可能）將「無安全需求（no security requirements）情況下構造起來的系統」重構為「安全性良好的（good security）系統」。
?????? 這種情況下我的辦法就是「先想象重構的情況」。考慮候選設計方案時，我會問自己：將某個設計重構為另一個設計的難度有多大？如果看上去很簡單，我就不必太擔心選擇是否得當，于是我就會選最簡單的設計，哪怕它不能覆蓋所有潛在需求也沒關系。但如果預先看不到簡單的重構辦法，我就會在設計上投入更多力氣。不過我發現，這種情況很少出現。
?????? 何時不該重構？
?????? 有時候你根本不應該重構 — 例如當你應該重新編寫所有代碼的時候。有時候既有代碼實在太混亂，重構它還不如從新寫一個來得簡單。作出這種決定很困難，我承認我也沒有什么好準則可以判斷何時應該放棄重構。
?????? 重寫（而非重構）的一個清楚訊號就是：現有代碼根本不能正常運作。你可能只是試著做點測試，然后就發現代碼中滿是錯誤，根本無法穩定運作。記住，重構之前，代碼必須起碼能夠在大部分情況下正常運作。
?????? 一個折衷辦法就是：將「大塊頭軟件」重構為「封裝良好的小型組件」。然后你就可以逐一對組件作出「重構或重建」的決定。這是一個頗具希望的辦法，但我還沒有足夠數據，所以也無法寫出優秀的指導原則。對于一個重要的古老系統，這肯定會是一個很好的方向。
?????? 另外，如果項目已近最后期限，你也應該避免重構。在此時機，從重構過程贏得的生產力只有在最后期限過后才能體現出來，而那個時候已經時不我予。Ward Cunningham對此有一個很好的看法。他把未完成的重構工作形容為「債務」。很多公司都需要借債來使自己更有效地運轉。但是借債就得付利息，過于復雜的代碼所造成的「維護和擴展的額外開銷」就是利息。你可以承受一定程度的利息，但如果利息太高你就會被壓垮。把債務管理好是很重要的，你應該隨時通過重構來償還一部分債務。
?????? 如果項目已經非常接近最后期限，你不應該再分心于重構，因為已經沒有時間了。不過多個項目經驗顯示：重構的確能夠提高生產力。如果最后你沒有足夠時間，通常就表示你其實早該進行重構。
四、重構（Refactoring）與設計
?????? 「重構」肩負一項特別任務：它和設計彼此互補。初學編程的時候，我埋頭就寫程序，渾渾噩噩地進行開發。然而很快我便發現，「事先設計」（upfront design）可以助我節省回頭工的高昂成本。于是我很快加強這種「預先設計」風格。許多人都把設計看作軟件開發的關鍵環節，而把編程（programming）看作只是機械式的低級勞動。他們認為設計就像畫工程圖而編碼就像施工。但是你要知道，軟件和真實器械有著很大的差異。軟件的可塑性更強，而且完全是思想產品。正如Alistair Cockburn所說：『有了設計，我可以思考更快，但是其中充滿小漏洞。』
?????? 有一種觀點認為：重構可以成為「預先設計」的替代品。這意思是你根本不必做任何設計，只管按照最初想法開始編碼，讓代碼有效運作，然后再將它重構成型。事實上這種辦法真的可行。我的確看過有人這么做，最后獲得設計良好的軟件。極限編程（Extreme Programming）[Beck, XP] 的支持者極力提倡這種辦法。
?????? 盡管如上所言，只運用重構也能收到效果，但這并不是最有效的途徑。是的，即使極限編程（Extreme Programming）愛好者也會進行預先設計。他們會使用CRC卡或類似的東西來檢驗各種不同想法，然后才得到第一個可被接受的解決方案，然后才能開始編碼，然后才能重構。關鍵在于：重構改變了「預先設計」的角色。如果沒有重構，你就必須保證「預先設計」正確無誤，這個壓力太大了。這意味如果將來需要對原始設計做任何修改，代價都將非常高昂。因此你需要把更多時間和精力放在預先設計上，以避免日后修改。
?????? 如果你選擇重構，問題的重點就轉變了。你仍然做預先設計，但是不必一定找出正確的解決方案。此刻的你只需要得到一個足夠合理的解決方案就夠了。你很肯定地知道，在實現這個初始解決方案的時候，你對問題的理解也會逐漸加深，你可能會察覺最佳解決方案和你當初設想的有些不同。只要有重構這項武器在手，就不成問題，因為重構讓日后的修改成本不再高昂。
?????? 這種轉變導致一個重要結果：軟件設計朝向簡化前進了一大步。過去未曾運用重構時，我總是力求得到靈活的解決方案。任何一個需求都讓我提心吊膽地猜疑：在系統壽命期間，這個需求會導致怎樣的變化？由于變更設計的代價非常高昂，所以我希望建造一個足夠靈活、足夠強固的解決方案，希望它能承受我所能預見的所有需求變化。問題在于：要建造一個靈活的解決方案，所需的成本難以估算。靈活的解決方案比簡單的解決方案復雜許多，所以最終得到的軟件通常也會更難維護 — 雖然它在我預先設想的方向上的確是更加靈活。就算幸運走在預先設想的方向上，你也必須理解如何修改設計。如果變化只出現在一兩個地方，那不算大問題。然而變化其實可能出現在系統各處。如果在所有可能的變化出現地點都建立起靈活性，整個系統的復雜度和維護難度都會大大提高。當然，如果最后發現所有這些靈活性都毫無必要，這才是最大的失敗。你知道，這其中肯定有些靈活性的確派不上用場，但你卻無法預測到底是哪些派不上用場。為了獲得自己想要的靈活性，你不得不加入比實際需要更多的靈活性。
?????? 有了重構，你就可以通過一條不同的途徑來應付變化帶來的風險。你仍舊需要思考潛在的變化，仍舊需要考慮靈活的解決方案。但是你不必再逐一實現這些解決方案，而是應該問問自己：『把一個簡單的解決方案重構成這個靈活的方案有多大難度？』如果答案是「相當容易」（大多數時候都如此），那么你就只需實現目前的簡單方案就行了。
重構可以帶來更簡單的設計，同時又不損失靈活性，這也降低了設計過程的難度，減輕了設計壓力。一旦對重構帶來的簡單性有更多感受，你甚至可以不必再預先思考前述所謂的靈活方案 — 一旦需要它，你總有足夠的信心去重構。是的，當下只管建造可運行的最簡化系統，至于靈活而復雜的設計，唔，多數時候你都不會需要它。
?????? 勞而無獲— Ron Jeffries
?????? Chrysler Comprehensive Compensation（克萊斯勒綜合薪資系統）的支付過程太慢了。雖然我們的開發還沒結束，這個問題卻已經開始困擾我們，因為它已經拖累了測試速度。
?????? Kent Beck、Martin Fowler和我決定解決這個問題。等待大伙兒會合的時間里，憑著我對這個系統的全盤了解，我開始推測：到底是什么讓系統變慢了？我想到數種可能，然后和伙伴們談了幾種可能的修改方案。最后，關于「如何讓這個系統運行更快」，我們提出了一些真正的好點子。
?????? 然后，我們拿Kent的量測工具度量了系統性能。我一開始所想的可能性竟然全都不是問題肇因。我們發現：系統把一半時間用來創建「日期」實體（instance）。更有趣的是，所有這些實體都有相同的值。
?????? 于是我們觀察日期的創建邏輯，發現有機會將它優化。日期原本是由字符串轉換而生，即使無外部輸入也是如此。之所以使用字符串轉換方式，完全是為了方便鍵盤輸入。好，也許我們可以將它優化。
?????? 于是我們觀察日期怎樣被這個程序運用。我們發現，很多日期對象都被用來產生「日期區間」實體（instance）。「日期區間」是個對象，由一個起始日期和一個結束日期組成。仔細追蹤下去，我們發現絕大多數日期區間是空的！
?????? 處理日期區間時我們遵循這樣一個規則：如果結束日期在起始日期之前，這個日期區間就該是空的。這是一條很好的規則，完全符合這個class的需要。采用此一規則后不久，我們意識到，創建一個「起始日期在結束日期之后」的日期區間，仍然不算是清晰的代碼，于是我們把這個行為提煉到一個factory method（譯注：一個著名的設計模式，見《Design Patterns》），由它專門創建「空的日期區間」。
?????? 我們做了上述修改，使代碼更加清晰，卻意外得到了一個驚喜。我們創建一個固定不變的「空日期區間」對象，并讓上述調整后的factory method每次都返回該對象，而不再每次都創建新對象。這一修改把系統速度提升了幾乎一倍，足以讓測試速度達到可接受程度。這只花了我們大約五分鐘。
?????? 我和團隊成員（Kent和Martin謝絕參加）認真推測過：我們了若指掌的這個程序中可能有什么錯誤？我們甚至憑空做了些改進設計，卻沒有先對系統的真實情況進行量測。
?????? 我們完全錯了。除了一場很有趣的交談，我們什么好事都沒做。
?????? 教訓：哪怕你完全了解系統，也請實際量測它的性能，不要臆測。臆測會讓你學到一些東西，但十有八九你是錯的。
五、重構與性能（Performance）
?????? 譯注：在我的接觸經驗中，performance一詞被不同的人予以不同的解釋和認知：效率、性能、效能。不同地區（例如臺灣和大陸）的習慣用法亦不相同。本書一遇performance我便譯為性能。efficient譯為高效，effective譯為有效。
?????? 關于重構，有一個常被提出的問題：它對程序的性能將造成怎樣的影響？為了讓軟件易于理解，你常會作出一些使程序運行變慢的修改。這是個重要的問題。我并不贊成為了提高設計的純潔性或把希望寄托于更快的硬件身上，而忽略了程序性能。已經有很多軟件因為速度太慢而被用戶拒絕，日益提高的機器速度亦只不過略微放寬了速度方面的限制而已。但是，換個角度說，雖然重構必然會使軟件運行更慢，但它也使軟件的性能優化更易進行。除了對性能有嚴格要求的實時（real time）系統，其它任何情況下「編寫快速軟件」的秘密就是：首先寫出可調（tunable）軟件，然后調整它以求獲得足夠速度。
?????? 我看過三種「編寫快速軟件」的方法。其中最嚴格的是「時間預算法」（time budgeting），這通常只用于性能要求極高的實時系統。如果使用這種方法，分解你的設計時就要做好預算，給每個組件預先分配一定資源 — 包括時間和執行軌跡（footprint）。每個組件絕對不能超出自己的預算，就算擁有「可在不同組件之間調度預配時間」的機制也不行。這種方法高度重視性能，對于心律調節器一類的系統是必須的，因為在這樣的系統中遲來的數據就是錯誤的數據。但對其他類系統（例如我經常開發的企業信息系統）而言，如此追求高性能就有點過份了。
?????? 第二種方法是「持續關切法」（constant attention）。這種方法要求任何程序員在任何時間做任何事時，都要設法保持系統的高性能。這種方式很常見，感覺上很有吸引力，但通常不會起太大作用。任何修改如果是為了提高性能，通常會使程序難以維護，因而減緩開發速度。如果最終得到的軟件的確更快了，那么這點損失尚有所值，可惜通常事與愿違，因為性能改善一旦被分散到程序各角落，每次改善都只不過是從「對程序行為的一個狹隘視角」出發而已。
?????? 關于性能，一件很有趣的事情是：如果你對大多數程序進行分析，你會發現它把大半時間都耗費在一小半代碼身上。如果你一視同仁地優化所有代碼，90% 的優化工作都是白費勁兒，因為被你優化的代碼有許多難得被執行起來。你花時間做優化是為了讓程序運行更快，但如果因為缺乏對程序的清楚認識而花費時間，那些時間都是被浪費掉了。
??????? 第三種性能提升法系利用上述的 "90%" 統計數據。采用這種方法時，你以一種「良好的分解方式」（well-factored manner）來建造自己的程序，不對性能投以任何關切，直至進入性能優化階段 — 那通常是在開發后期。一旦進入該階段，你再按照某個特定程序來調整程序性能。
????? 在性能優化階段中，你首先應該以一個量測工具監控程序的運行，讓它告訴你程序中哪些地方大量消耗時間和空間。這樣你就可以找出性能熱點（hot spot）所在的一小段代碼。然后你應該集中關切這些性能熱點，并使用前述「持續關切法」中的優化手段來優化它們。由于你把注意力都集中在熱點上，較少的工作量便可顯現較好的成果。即便如此你還是必須保持謹慎。和重構一樣，你應該小幅度進行修改。每走一步都需要編譯、測試、再次量測。如果沒能提高性能，就應該撤銷此次修改。你應該繼續這個「發現熱點、去除熱點」的過程，直到獲得客戶滿意的性能為止。關于這項技術，McConnell [McConnell] 為我們提供了更多信息。
?????? 一個被良好分解（well-factored）的程序可從兩方面幫助此種優化形式。首先，它讓你有比較充裕的時間進行性能調整（performance tuning），因為有分解良好的代碼在手，你就能夠更快速地添加功能，也就有更多時間用在性能問題上（準確的量測則保證你把這些時間投資在恰當地點）。其次，面對分解良好的程序，你在進行性能分析時便有較細的粒度（granularity），于是量測工具把你帶入范圍較小的程序段落中，而性能的調整也比較容易些。由于代碼更加清晰，因此你能夠更好地理解自己的選擇，更清楚哪種調整起關鍵作用。
?????? 我發現重構可以幫助我寫出更快的軟件。短程看來，重構的確會使軟件變慢，但它使優化階段中的軟件性能調整更容易。最終我還是有賺頭。
六、重構起源何處？
?????? 我曾經努力想找出重構（refactoring）一詞的真正起源，但最終失敗了。優秀程序員肯定至少會花一些時間來清理自己的代碼。這么做是因為，他們知道簡潔的代碼比雜亂無章的代碼更容易修改，而且他們知道自己幾乎無法一開始就寫出簡潔的代碼。
?????? 重構不止如此。本書中我把重構看作整個軟件開發過程的一個關鍵環節。最早認識重構重要性的兩個人是Ward Cunningham和Kent Beck，他們早在1980s之前就開始使用Smalltalk，那是個特別適合重構的環境。Smalltalk是一個十分動態的環境，你可以很快寫出極具功能的軟件。Smalltalk的「編譯/連結/執行」周期非常短，因此很容易快速修改代碼。它是面向對象，所以也能夠提供強大工具，最大限度地將修改的影響隱藏于定義良好的接口背后。Ward和Kent努力發展出一套適合這類環境的軟件開發過程（如今Kent把這種風格叫作極限編程 [Beck, XP]）。他們意識到：重構對于提高他們的生產力非常重要。從那時起他們就一直在工作中運用重構技術，在嚴肅而認真的軟件項目中使用它，并不斷精煉這個程序。
?????? Ward和Kent的思想對Smalltalk社群產生了極大影響，重構概念也成為Smalltalk文化中的一個重要元素。Smalltalk社群的另一位領袖是Ralph Johnson，伊利諾斯大學烏爾班納分校教授，著名的「四巨頭」 [Gang of Four] 之一。Ralph最大的興趣之一就是開發軟件框架（framework）。他揭示了重構對于靈活高效框架的開發幫助。
????? Bill Opdyke是Ralph的博士研究生，對框架也很感興趣。他看到重構的潛在價值，并看到重構應用于Smalltalk之外的其它語言的可能性。他的技術背景是電話交換系統的開發。在這種系統中，大量的復雜情況與時俱增，而且非常難以修改。Bill的博士研究就是從工具構筑者的角度來看待重構。通過研究，Bill發現：在C++ framework開發項目中，重構很有用。他也研究了極有必要的「語義保持性（semantics-preserving）重構」及其證明方式，以及如何以工具實現重構。時至今日，Bill的博士論文 [Opdyke] 仍然是重構領域中最有價值、最豐碩的研究成果。此外他為本書撰寫了第13章。
?????? 我還記得1992年OOPSLA大會上見到Bill的情景。我們坐在一間咖啡廳里，討論當時我正為保健業務構筑的一個概念框架（conceptual framework）中的某些工作。Bill跟我談起他的研究成果，我還記得自己當時的想法：『有趣，但并非真的那么重要』。唉，我完全錯了。
?????? John Brant和Don Roberts將重構中的「工具」構想發揚光大，開發了一個名為「重構瀏覽器」（Refactoring Browser）的Smalltalk重構工具。他們撰寫了本書第14章，其中對重構工具做了更多介紹。
?????? 那么，我呢？我一直有清理代碼的傾向，但從來沒有想到這會有那么重要。后來我和Kent一起做了個項目，看到他使用重構手法，也看到重構對生產性能和產品質量帶來的影響。這份體驗讓我相信：重構是一門非常重要的技術。但是，在重構的學習和推廣過程中我遇到了挫折，因為我拿不出任何一本書給程序員看，也沒有任何一位專家打算寫出這樣一本書。所以，在這些專家的幫助下，我寫下了這本書。
?????? 優化一個薪資系統— Rich Garzaniti
?????? 將Chrysler Comprehensive Compensation（克萊斯勒綜合薪資系統）交給GemStone公司之前，我們用了相當長的時間開發它。開發過程中我們無可避免地發現程序不夠快，于是找了Jim Haungs — GemSmith中的一位好手 — 請他幫我們優化這個系統。
?????? Jim先用一點時間讓他的團隊了解系統運作方式，然后以GemStone的ProfMonitor特性編寫出一個性能量測工具，將它插入我們的功能測試中。這個工具可以顯示系統產生的對象數量，以及這些對象的誕生點。
?????? 令我們吃驚的是：創建量最大的對象竟是字符串。其中最大的工作量則是反復產生12,000-bytes的字符串。這很特別，因為這字符串實在太大了，連GemStone慣用的垃圾回收設施都無法處理它。由于它是如此巨大，每當被創建出來，GemStone都會將它分頁（paging）至磁盤上。也就是說字符串的創建竟然用上了I/O子系統（譯注：分頁機制會動用I/O），而每次輸出記錄時都要產生這樣的字符串三次﹗
?????? 我們的第一個解決辦法是把一個12,000-bytes字符串緩存（cached）起來，這可解決一大半問題。后來我們又加以修改，將它直接寫入一個file stream，從而避免產生字符串。
?????? 解決了「巨大字符串」問題后，Jim的量測工具又發現了一些類似問題，只不過字符串稍微小一些：800-bytes、500-bytes……等等，我們也都對它們改用file stream，于是問題都解決了。
?????? 使用這些技術，我們穩步提高了系統性能。開發過程中原本似乎需要1,000小時以上才能完成的薪資計算，實際運作時只花40小時。一個月后我們把時間縮短到18小時。正式投入運轉時只花12小時。經過一年的運行和改善后，全部計算只需9小時。
?????? 我們的最大改進就是：將程序放在多處理器（multi-processor）計算器上，以多線程（multiple threads）方式運行。最初這個系統并非按照多線程思維來設計，但由于代碼有良好分解（well factored），所以我們只花三天時間就讓它得以同時運行多個線程了。現在，薪資的計算只需2小時。
?????? 在Jim提供工具使我們得以在實際操作中量度系統性能之前，我們也猜測過問題所在。但如果只靠猜測，我們需要很長的時間才能試出真正的解法。真實的量測指出了一個完全不同的方向，并大大加快了我們的進度。
轉載于:https://my.oschina.net/shizhoubo/blog/4279
總結
- 上一篇： 【实战项目】采用jeecg3.2框架，一
- 下一篇： 交互设计学习