代碼優化是把雙刃劍

        代碼優化的好處多多，但是這并不意味著所有的代碼都需要進行優化，有時過度的優化反而適得其反——費時、費力、不討好。

        “現代計算機科學的鼻祖”Donald Knuth 曾說過“過早的優化是萬惡之源”，因為：讓正確的程序更快，要比讓快速的程序正確容易得多。

        在項目開發中，總是有程序員浪費寶貴的時間去改進那些不需要改進的代碼，而沒有通過所做的改進增加價值。在對項目進行優化時，究竟哪些地方應該優化，應該如何優化，哪些不應該優化呢？你需要先來了解一下本文所說的這 7 件事。

        1. 究竟要優化什么？

        在優化工作開始的時候，你還尚未明確優化內容和目的，那么你很容易陷入誤區。在一開始，你就應該清楚地了解你要達到的效果，以及其他優化相關的 各種問題。這些目標需要明確指出（至少精通技術的項目經理可以理解和表達它），接下來，在整個優化過程中，你需要堅持這些目標。

        在實際的項目開發中，經常會存在各種各樣的變數。可能一開始時要優化這一方面，隨后你可能會發現需要優化另一方面。這種情況下，你需要清晰地了解這些變化，并確保團隊中的每個人都明白目標已經發生了變化。

        2. 選擇一個正確的優化指標

        選擇正確的指標，是優化的一個重要組成部分，你需要按照這些指標來測量優化工作的進展情況。如果指標選擇不恰當，或者完全錯誤，你所做的努力有可能白費了。

        即使指標正確，也必須有一些辨別。在某些情況下，將最多的努力投入到運行消耗時間最多的那部分代碼中，這是實用的策略。但也要記住，Unix/Linux 內核的大部分時間花費在了空循環上。

        需要注意的是，如果你輕易選擇了一個很容易達到的指標，這作用不大，因為沒有真正解決問題。你有必要選擇一個更復雜的、更接近你的目標的指標。

        3. 優化在刀刃上

        這是有效優化的關鍵。找到項目中與你的目標（性能、資源或其他）相背的地方，并將你的努力和時間用在那里。

        舉一個典型的例子，一個 Web 項目速度比較慢，開發者在優化時將大部分精力放在了數據庫優化上，最終發現真正的問題是網絡連接慢。

        另外，不要分心于容易實現的問題。這些問題盡管很容易解決，但可能不是必要的，或與你的目標不相符。容易優化并不意味著值得你花費工夫。

        4. 優化層次越高越好

        在一般情況下，優化的層次越高，就會越有效。根據這個標準，最好的優化是找到一個更有效的算法。

        舉個例子，在一個軟件開發項目中，有一個重要的應用程序性能較差，于是開發團隊開始著手優化，但性能并沒有提升太多，之后，項目人員交替，新的開發人員在檢查代碼時發現，性能問題的核心是由于在表中使用了冒泡排序算法，導致成千上萬項的增加。

        盡管如此，高層次的優化也不是“銀彈”。一些基本技術，如將所有東西移到循環語句外，也可以產生一些優化的效果。通常情況下，大量低層次的優化可以產生等同于一個高層次優化的效果。

        還需要注意的是，高層次優化，會減少一些代碼塊，那么你之前對這些代碼塊所做的優化就沒有任何意義了，因此，剛開始就應該考慮高層次的優化。

        5. 不要過早優化

        在項目早期就進行優化，會導致你的代碼難以閱讀，或者會影響運行。另一方面，在項目后期，你可能會發現之前所做的優化沒有起到任何作用，白白浪費了時間和精力。

        正確的方式是，你應該將項目開發和優化當作兩個獨立的步驟來做。

        6. 依賴性能分析，而不是直覺

        你往往會認為你已經知道哪里需要優化，這是不可取的，尤其是在復雜的軟件系統中，性能分析數據應該是第一位的，最后才是直覺。

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

        7. 優化不是萬金油

        優化最重要的規則之一是，你無法優化一切，甚至無法同時優化兩個問題。比如，優化了速度，可能會增加資源利用；優化了存儲的利用率，可能會使其他地方放慢。你需要權衡一下，哪個更符合你的優化目標。

        英文原文：Code Optimization as a Double-Edged Sword