性能管理常被視為一種「黑魔法」，因為性能問題通常在應用程式開發完成後才浮現，此時要追根究底極為困難。然而，一旦精準定位問題根源，修復往往相對簡單。工程師在尋找更有效執行特定任務的方法上極具創造力（有時甚至過度創新）。對於給定的性能問題，解決方案可能只是透過快取減少冗餘計算、增加硬體資源，或替換為更高效的演算法。但要清晰識別問題根源、設計複雜程式更是難上加難，因此首要任務是從一開始就預防性能問題。
雖然演算法選擇不當、無法重用先前計算結果、資源管理不善等程式設計決策被視為性能問題的直接原因，但大多數性能問題的更深層成在於：未能將性能管理、目標與測量整合進開發流程中。
您如何知道何時存在性能問題？對大多數開發團隊而言，答案（引用美國最高法院大法官 Potter Stewart 描述淫穢內容的名言）是：「遇到時才知道。」這正是核心癥結 — 性能目標、度量與測量常被忽略，等到發現時已為時過晚。
最常見的性能管理策略其實是「無策略」，通常呈現兩種形式：
這兩種策略共同的根本問題在於：它們未將性能管理視為開發流程的整合部分。
第一種方法將性能視為專案尾聲才處理的雜務，基本靠運氣。問題在於：當性能問題爆發時，您缺乏處理、定位根源、針對性解決的框架，也未在開發規劃中預留性能測量與調優時間。這類似於網站僅安裝預設配置的防火牆卻無連貫安全策略，一旦被入侵便不知從何著手。
另一常見但更糟的方法是讓微小性能考量驅動架構與設計決策。開發人員喜歡優化程式碼，理由是令人滿足且有趣。但知道何時優化、優化哪段程式碼，以及在開發週期何時解決性能問題更為重要。遺憾的是，開發人員通常無法憑直覺判斷性能問題實際會出現在應用程式的哪個位置。結果導致大量精力浪費在極少執行的程式碼路徑上，甚至為了優化原本無性能問題的元件而破壞良好的設計與開發實踐。當您埋首編寫程式碼時，很容易在性能問題上「只見樹木不見森林」。
讓每個程式碼路徑盡可能快速執行，並不保證最終產品表現良好。再多的局部優化也無法彌補根本效率低落的設計。開發時優化策略用關注低層級性能考量取代了整個專案的性能策略，讓您無法確信是否真正擁有性能策略。
開發時優化的眾多問題之一在於忽略了優化的固有風險。少數優化能改善設計、減少錯誤，但屬例外。通常優化涉及性能與其他考量（如乾淨設計、明確性、靈活性、功能性）的權衡。優化有成本與風險：可能引入錯誤、限制功能、增加使用或維護難度。在承擔這些成本前，請確保值得。
從一開始就應將性能測量與規劃整合進開發流程，對開發與性能測量調優進行單獨、交錯的迭代。這意味著設定性能目標、準備性能測量方案、在開發程式碼時頻繁複查效能。最好將舊測試結果存入資料庫，以便在修改程式碼時輕鬆比較性能變化。
分離開發與性能迭代，讓您在開發迭代期間專注編寫正確無誤的程式碼，同時知道不久將有適當機會改進性能。若想到讓程式碼跑得更快的巧思，先在程式碼加註釋記錄想法，但暫不實作！當下不是優化時機。若最終確有必要，待專注性能階段再回頭處理。性能優化應由性能目標驅動、受性能測量支撐，其他不過是「次要的」。
測量是性能管理的關鍵。想一想：某個妙招真的能讓程式碼跑得更快嗎？我們準備驗證。在實施妙招前後，使用性能測量工具測試效能。若測不出改進，就收回妙招。若測不出益處，為何要冒破壞正常運作程式碼的風險？
在性能迭代期間，測量應用程式或其元件效能，並與前次迭代測量比較。有變慢的地方嗎？找出原因。若未達性能目標，不一定非得立即修改，但您已獲得寶貴反饋 — 了解變更對性能的影響。
若無量化性能目標與支撐的測量規劃，性能調優似乎毫無意義。您如何知道已達標？其他開發階段（編碼、測試、打包）都有明確目標 — 實現這組功能、修復那些錯誤等。性能階段也應有結構與目標。
當性能關注源自外部（客戶或公司其他部門）時，性能目標尤為重要。當有人要求讓程式跑得更快，您應先問：「必須快多少？」否則可能在調優上投入過多資源却仍無法滿足客戶。投入十二分努力使速度提升 30%，卻聽到「我原希望提升 50%」，這會讓人相當挫折。
性能管理遠不止優化。它提供一個框架，決定何時優化、何時不優化。決策應基於明確的性能目標、測量與規劃，而非直覺。
