鄭建勳：程式碼優化的三重境界

▶︎   合理的程式碼，在高階開發者的指尖自然流淌

優秀的開發者 ， 能夠在頭腦中想象出不同程式執行的過程和結果。只有在我們掌握了這樣的技能之後，才能學會如何可靠地構建起能夠表現出所需行為和結果的程式。

舉一個例子，下圖是用遞迴實現的斐波拉契數列，以及其執行的示意圖。遞迴形式，是程式中比較複雜的一種過程了。高階開發者在書寫這樣的程式時，實際上腦海中就已經有了程式 每一步如何執行的完整影像，看到程式過程的脈絡。時間和空間複雜度盡收眼底。

Go語言擁有強大的標準庫和保姆級別的執行時，這意味著對Go程式執行過程的把握，同樣離不開對於程式碼表象背後底層原理的深入理解，才能夠將看到的毛細血管延伸得更細緻一些。

▶︎   制度約束，保證程式在正常的軌道執行

合理的程式碼看起來是如此自然，然而對開發者的個人素質要求卻極高。由於開發者對語言和程式設計理解上的差異，常常開發出來的程式碼風格迥異。因此，我們需要一些制度和規範，來幫助我們寫出更符合規範的程式碼。

這些規範涉及程式開發的方方面面，從目錄結構規範、測試規範、版本規範、目錄結構規範、程式碼評審規範、開發規範等等。 這部分，你還 可以參考一下 UBER 開源的Go語言開發中的約定規範 ，連結我放這裡，方便你檢視 ： 。

只需要遵守一些簡單的規則，就能夠更多 地 減少之後效能上的困擾。

這裡舉一個《Efficient Go》中的例子 吧 ，下面的程式從功能上來看是沒有問題的，往切片中新增元素 。

但是這種寫法卻忽略了一個事實，即 切片在自動擴容過程中， Go執行時會建立新的記憶體空間，並執行拷貝（參見《Go語言底層原理剖析》）。

#prefer-specifying-container-capacity 。

上述程式可以改寫如下，在初始化時指定切片容量：

除了切片的動態擴容，雜湊表的動態擴容也有類似的情況。這都是新手比較容易犯錯的地方。這啟發我們，即便是一開始不太理解底層的實現邏輯，也需要準守一些基本的規則和常見的效能陷阱規避，從小事情上開始優化程式碼習慣。

書寫合理程式碼的第二方面，涉及到具體功能的演算法和資料結構的設計與改造。有人說“程式=演算法+資料結構”，可見其二者的重要性。 在接觸到很多業務屎山程式碼之後，我們總是感嘆，有時候真的稍微寫得合理一點，就可以避免掉後期理解成本與重構成本的大大增加。

對於演算法， 通常對於關鍵演算法的調整，能帶來數倍效能的提升。例如將氣泡排序（o(n^2)），替換為快速排序(o(n*logn))，將線性查詢(o(n)) 替換為二分查詢（o(log n)），甚至到雜湊表的方式（o(1)），都是常見演算法導致的效能提升。

對於資料結構，指的是新增或更改正在處理的資料的表示。這種表示很大程度上決定了資料的處理方式，進而決定了時間與空間複雜度。舉一個簡單的例子，如果在連結串列中，能夠在頭部節點新增一個表明連結串列長度的欄位，則不必遍歷連結串列來得到連結串列的總長度。

圖 - 連結串列節點增加總長度

有時候，我們需要做一些以空間換時間的tradeoff。快取就是一種提高效能，減少資料庫訪問和防止全域性結構鎖的機制。快取這種空間換時間的策略，在高併發程式中應用廣泛，例如 不管是CPU多級快取，還是Go執行時排程器，Go記憶體分配管理，甚至到標準庫中sync.pool的設計，都體現了利用區域性快取提高整體併發速度的設計。

開發中通常在記憶體，或者藉助redis等資料庫快取資料，減輕對原有資料訪問的壓力。當然，這中間如何提高快取的命中率，如何設計快取失效策略考驗的，這取決於開發者基於實際場景對演算法和業務的理解程度。

在 設計演算法與資料結構時，要考慮的另一個重要因素，是關於實現的複雜度。例如Go1.13前記憶體分配使用了Treap平衡樹，Treap 是一種引入了隨機數的二叉樹搜尋樹，其實很簡單，並且引入的隨機數以及必要時的旋轉，保證了比較好的平衡特性。又如redis中選擇跳錶，都是因為實現複雜度考慮，而沒有選擇實現更加複雜的紅黑樹。

當完成重要過程的優化之後，鼓勵大家對於功能進行benckmark效能測試，並通過benchstat 工具，對比兩次benckmark的差別，做到心中有數。

可以對程式刻意優化的點很多，例如：

放入介面中的資料會進行記憶體逃逸，需不需要優化？

位元組陣列與string互轉的效能損失需不需要優化？

無用的記憶體需不需要複用？

這裡我不考慮這種細節，一方面其依賴於開發者的水平和細膩程度，另一方面這些微小的效能損失很少成為瓶頸，至少在專案開發的初期是這樣。

因此這裡我想要討論的刻意優化，指的是在專案開發和迭代過程中，為了達成需求目標而刻意對於效能瓶頸的優化。只關注最核心要解決的問題。總地來說，基於兩者在通訊層面的對比，我們因此能總結出它們本質上的差異：SOA基於配置，微服務則基於約定。