代碼優化的另一面

　　優化軟件是一件好事，但如果使用不當，就會好事變壞事。如果你在優化代碼時走向了錯誤的道路，那么這種優化會提高開發成本、降低生產力。在軟件開發過程中，成本需要時刻謹記在心。一般來說，優化的軟件需要花費更長的時間來交付，因為你需要花費精力使它質量更高。有時候，你并不是為了運行速度而做優化。對于嵌入式系統來說，可能是減少內存使用，對于手持設備，可能是硬件資源限制。優化的代碼通常難以調試和維護，因為你需要犧牲一些代碼可讀性。優化良好的軟件帶來的好處要多于壞處，但是如果你做了錯誤的優化，那么結果恰恰相反。

　　到底怎么才能做好代碼優化呢？Rick Cook 給出了一些有用的建議。

　　你到底為了什么而優化

　　如果在優化過程啟動時搞不清楚為什么而優化，那么你基本會走向錯誤的道路。你需要清楚的理解你準備完成的目標和相關的優化選擇。這些目標需要清晰而且簡潔，簡單到項目經理能夠理解它，你需要在優化過程中始終堅持這些目標。在軟件開發過程中，變更是常有的事情。你可能一開始想優化這個目標，然后又發現需要優化其他目標。事實也是如此，但是請把這些目標的變更記錄清楚。

　　性能測試團隊報告的性能缺陷可能是優化的主要目標，一方面它來自于開發人員之外的客觀性能問題，另一方面這些缺陷報告會明確的指出存在哪些問題，是運行緩慢，還是磁盤換頁頻繁等等。開發人員從這些缺陷中開始入手優化，比自己空想出的性能目標要合理、客觀的多。

　　小心對待優化的衡量標準

　　選擇正確的衡量標準是優化的重要步驟。你需要利用這些標準來衡量自己的優化進度。如果衡量標準是錯誤的，那么你的努力就白費了。即使是正確的標準，也需要正確的運用。有時候，把主要精力放在應用程序運行時間最多的代碼部分上市正確的做法。不過請記住，Unix/Linux 內核在空閑循環（idle loop）中花費的時間最多。這里的問題是，如果你不小心對待，那么你可能會選擇一個不能幫助你解決問題的衡量標準。

　　衡量標準的選擇應該取決于哪些標準能夠確實提高用戶體驗。例如，有關數據庫的性能分析指標有很多，開發人員和性能測試人員需要確定哪些指標是真正影響應用程序速度的，是 bufferpool 的大小，還是數據庫連接池的大小。這是一個漸進的認識過程。

　　優化且只優化關鍵部分

　　這是有效優化的關鍵。尋找能夠達到目標（性能、資源）的代碼部分并集中精力。一個典型的例子是把時間花費在優化數據庫上，而實際的性能殺手是緩慢的網絡連接。

　　不要被映入眼簾的表象所吸引。這些表象并不一定會解決你的問題。只是因為某些事情易于發現而且易于優化并不意味著它們值得關注。 

　　高層次優化更好

　　一般來說，優化的層次越高，優化的效果就越明顯。按此標準，最好的優化方法是尋找更好的算法。例如，在一些 IT 部門，員工花費幾個月的時間來對某個軟件做優化但是沒有進展，然后找來一批新員工來做這些優化，他們很快就會發現性能的問題在于代碼某處使用了冒泡排序或者某張數據庫表增加了數以萬條的記錄等等。

　　建議大家花時間看看基本的應用架構，找找有沒有可以優化的線索。但是，高層次優化不是銀彈。一些基本的技術，比如把代碼盡可能的移到循環體外面等等。

　　另外，高層次優化可以避免對代碼細節的復雜重構。開發人員往往對低層次的優化最感興趣，請控制住自己的欲望，從高處著手！ 

　　不要過早優化

　　開發人員有一種沖動，那就是在編碼的時候就準備優化了。一般來說，這不是個好主意。有時候，開發人員并不確定這樣的優化工作是否值得。例如，你可能通過移位操作來代替乘法操作，但是這種性能優化的做法會產生讓人非常難以理解的代碼。

　　最好把開發和優化工作分開，先開發出正確的代碼，然后再優化。過早優化的問題在于開發人員會有意的對軟件的架構設計和代碼結構等做一些預先的設想，而其中有相當一部分都是多余操心的，你可能不得不對這些多余的部分再做優化。

　　依靠性能分析數據，而不是直覺

　　你以為自己知道軟件系統哪里需要優化，但是直覺是第二位的，數據是第一位的。否則，你會發現可能把一段代碼優化的非常快，但是實際上很少被調用。

　　優化的一個有效的策略是，你要根據所做工作對優化效果的影響來進行排序。在開始工作之前找到影響最大的“路障”，然后再處理小的“路障”。 

　　不能指望優化解決所有問題

　　優化的重要法則之一是不能讓優化解決所有問題，比如，提高運行速度會耗費更多系統資源。你必須為了主要的優化目標做出權衡。

　　讀者對代碼優化有什么看法，歡迎發表自己的意見！