### 重構與性能（Performance） 譯注：在我的接觸經驗中，performance—詞被不同的人予以不同的解釋和認知：效率、性能、效能。不同地區（例如臺灣和大陸）的習慣用法亦不相同。本書一遇performance我便譯為性能。effcient譯為高效，effective譯為有效。 關于重構，有一個常被提出的問題：它對程序的性能將造成怎樣的影響？為了讓軟件易于理解，你常會做出一些使程序運行變慢的修改。這是個重要的問題。我并不贊成為了提高設計的純潔性或把希望寄托于更快的硬件身上，而忽略了程序性能。己經有很多軟件因為速度太慢而被用戶拒絕，日益提高的機器速度亦只不過略微放寬了速度方面的限制而已。但是，換個角度說，雖然重構必然會使軟件運行更慢，但它也使軟件的性能優化更易進行。除了對性能有嚴格要求的實時（real time）系統，其他任何情況下「編寫快速軟件」的秘密就是：首先寫出可調〔tunable）軟件，然后調整它以求獲得足夠速度。 我看過三種「編寫快速軟件」的方法。其中最嚴格的是「時間預算法」（time budgeting)，這通常只用于性能要求極高的實時系統。如果使用這種方法，分解你的設計時就要做好預算，給每個組件預先分配一定資源——包括時間和執行軌跡 (footprint）。每個組件絕對不能超出自己的預算，就算擁有「可在不同組件之間調度預配時間」的機制也不行。這種方法高度重視性能，對于心律調節器一類的系統是必須的，因為在這樣的系統中遲來的數據就是錯誤的數據。但對其他類系統(例如我經常開發的企業信息系統）而言，如此追求高性能就有點過份了。 第二種方法是「持續關切法」（ constant attention）。這種方法要求任何程序員在任何時間做任何事時，都要設法保持系統的高性能。這種方式很常見，感覺上很有吸引力，但通常不會起太大作用。任何修改如果是為了提高性能，通常會使程序難以維護，因而減緩開發速度。如果最終得到的軟件的確更快了，那么這點損失尚有所值，可惜通常事與愿違，因為性能改善一旦被分散到程序各角落，每次改善都只不過是從「對程序行為的一個狹隘視角」出發而已。 關于性能，一件很有趣的事情是：如果你對大多數程序進行分析，你會發現它把大半時間都耗費在一小半代碼身上。如果你一視同仁地優化所有代碼，90%的優化工作都是白費勁兒，因為被你優化的代碼有許多難得被執行起來。你花時間做優化是為了讓程序運行更快，但如果因為缺乏對程序的清楚認識而花費時間，那些時間都是被浪費掉了。 第三種性能提升法系利用上述的“90%”統計數據。采用這種方法時，你以一種「良好的分解方式」（well-factored manner）來建造自己的程序，不對性能投以任何關切，直至進入性能優化階段——那通常是在開發后期。一且進入該階段，你再按照某個特定程序來調整程序性能。 在性能優化階段中，你首先應該以一個量測工具監控程序的運行，讓它告訴你程序中哪些地方大量消耗時間和空間。這樣你就可以找出性能熱點〔hot spot）所在的一 小段代碼。然后你應該集中關切這些性能熱點，并使用前述「持續關切法」中的優化手段來優化它們。由于你把注意力都集中在熱點上，較少的工作量便可顯現較好的成果。即便如此你還是必須保持謹慎。和重構一樣，你應該小幅度進行修改。每走一步都需要編譯、測試、再次量測。如果沒能提高性能，就應該撤銷此次修改。你應該繼續這個「發現熱點、去除熱點」的過程，直到獲得客戶滿意的性能為止。 關于這項技術，McConnel [McConnel]為我們提供了更多信息。 一個被良好分解（well-factored）的程序可從兩方面幫助此種優化形式。首先，它讓你有比較充裕的時間進行性能調整（performance tuning），因為有分解良好的代碼在手，你就能夠更快速地添加功能，也就有更多時間用在性能問題上（準確的量測則保證你把這些時間投資在恰當地點）。其次，面對分解良好的程序，你在進行性能分析時便有較細的粒度（granularity），于是量測工具把你帶入范圍較小的程序段落中，而性能的調整也比較容易些。由于代碼更加清晰，因此你能夠更好地理解自己的選擇，更清楚哪種調整起關鍵作用。 我發現重構可以幫助我寫出更快的軟件。短程看來，重構的確會使軟件變慢，但它使優化階段中的軟件性能調整更容易。最終我還是有賺頭。