代碼優化的好處多多，但是這並不意味着所有的代碼都需要進行優化，有時過度的優化反而適得其反——費時、費力、不討好。
“現代計算機科學的鼻祖”Donald Knuth曾說過“過早的優化是萬惡之源”，因爲：讓正確的程序更快，要比讓快速的程序正確容易得多。
在項目開發中，總是有程序員浪費寶貴的時間去改進那些不需要改進的代碼，而沒有通過所做的改進增加價值。在對項目進行優化時，究竟哪些地方應該優化，應該如何優化，哪些不應該優化呢？你需要先來了解一下本文所說的這7件事。
1. 究竟要優化什麼？
在優化工作開始的時候，你還尚未明確優化內容和目的，那麼你很容易陷入誤區。在一開始，你就應該清楚地瞭解你要達到的效果，以及其他優化相關的各種問題。這些目標需要明確指出（至少精通技術的項目經理可以理解和表達它），接下來，在整個優化過程中，你需要堅持這些目標。
在實際的項目開發中，經常會存在各種各樣的變數。可能一開始時要優化這一方面，隨後你可能會發現需要優化另一方面。這種情況下，你需要清晰地瞭解這些變化，並確保團隊中的每個人都明白目標已經發生了變化。
2. 選擇一個正確的優化指標
選擇正確的指標，是優化的一個重要組成部分，你需要按照這些指標來測量優化工作的進展情況。如果指標選擇不恰當，或者完全錯誤，你所做的努力有可能白費了。
即使指標正確，也必須有一些辨別。在某些情況下，將最多的努力投入到運行消耗時間最多的那部分代碼中，這是實用的策略。但也要記住，Unix/Linux內核的大部分時間花費在了空循環上。
需要注意的是，如果你輕易選擇了一個很容易達到的指標，這作用不大，因爲沒有真正解決問題。你有必要選擇一個更復雜的、更接近你的目標的指標。
3. 優化在刀刃上
這是有效優化的關鍵。找到項目中與你的目標（性能、資源或其他）相背的地方，並將你的努力和時間用在那裏。
舉一個典型的例子，一個Web項目速度比較慢，開發者在優化時將大部分精力放在了數據庫優化上，最終發現真正的問題是網絡連接慢。
另外，不要分心於容易實現的問題。這些問題儘管很容易解決，但可能不是必要的，或與你的目標不相符。容易優化並不意味着值得你花費工夫。
4. 優化層次越高越好
在一般情況下，優化的層次越高，就會越有效。根據這個標準，最好的優化是找到一個更有效的算法。
舉個例子，在一個軟件開發項目中，有一個重要的應用程序性能較差，於是開發團隊開始着手優化，但性能並沒有提升太多，之後，項目人員交替，新的開發人員在檢查代碼時發現，性能問題的核心是由於在表中使用了冒泡排序算法，導致成千上萬項的增加。
儘管如此，高層次的優化也不是“銀彈”。一些基本技術，如將所有東西移到循環語句外，也可以產生一些優化的效果。通常情況下，大量低層次的優化可以產生等同於一個高層次優化的效果。
還需要注意的是，高層次優化，會減少一些代碼塊，那麼你之前對這些代碼塊所做的優化就沒有任何意義了，因此，剛開始就應該考慮高層次的優化。
5. 不要過早優化
在項目早期就進行優化，會導致你的代碼難以閱讀，或者會影響運行。另一方面，在項目後期，你可能會發現之前所做的優化沒有起到任何作用，白白浪費了時間和精力。
正確的方式是，你應該將項目開發和優化當作兩個獨立的步驟來做。
6. 依賴性能分析，而不是直覺
你往往會認爲你已經知道哪裏需要優化，這是不可取的，尤其是在複雜的軟件系統中，性能分析數據應該是第一位的，最後纔是直覺。
優化的一個有效的策略是，你要根據所做工作對優化效果的影響來進行排序。在開始工作之前找到影響最大的“路障”，然後再處理小的“路障”。
7. 優化不是萬金油
優化最重要的規則之一是，你無法優化一切，甚至無法同時優化兩個問題。比如，優化了速度，可能會增加資源利用；優化了存儲的利用率，可能會使其他地方放慢。你需要權衡一下，哪個更符合你的優化目標。