如無必要，勿增實體。

過早的優化是萬惡之源。

背景

一個抽獎活動，要求在展示獎品股票時，顯示股票價格。開發在實現這個功能的時候，用redis快取每隻股票的價格，每兩小時呼叫行情服務更新一次。

問為什麼要做個快取，而不是直接訪問行情服務直接讀取，給出了幾個理由：

1. 減少對行情的請求，直接訪問redis一次就能查很多。
2. 用快取速度快。
3. 獎品展示、獲獎排行榜都要用行情資料，防止不一致。
4. 用行情的地方很多，不用每次請求行情服務。
5. 前端需要拉取的資料，在需求範圍內，可以接受兩小時不變，不用每次重新計算。

但是這些理由都站不住腳，直接訪問行情服務並不會有問題。
優化過渡，過早加了快取，增加了程式碼的複雜度，產生了資料的不一致性。
沒有解決具體的問題，看到的只是一些表象，看似解決了問題。

思考

逐條思考下上面的幾點理由。

理由1. 減少對行情的請求，直接訪問redis一次就能查很多。

說法是對的，確實減少了對行情的訪問。但是為什麼要減少對行情的訪問呢？
行情的服務很穩定，而且效能也很好，並沒有什麼問題。沒有解決具體問題。

理由2. 用快取速度快。

如果直接訪問行情資料來源速度是瓶頸嗎，有遇到效能問題嗎？沒有。行情也是記憶體訪問，速度不一定比redis慢的。而且開發也沒有資料支撐。

理由3. 獎品展示、獲獎排行榜都要用行情資料，防止不一致。

為什麼要一致，不一致有什麼問題？對於排行榜，大家都有預期，是一定時間才更新一次的，只要在排行榜介面有說明即可。就像遊戲的排行榜，很多都是24小時更新一次。沒有必要為了和排行榜資料一致，而修改程式碼。這個問題在產品形態上就能解決，也是個偽問題。

理由4. 用行情的地方很多，不用每次請求行情服務。

同理由1，多怎麼了？正常訪問就可以了，如果效能瓶頸再優化。

理由5. 前端需要拉取的資料，在需求範圍內，可以接受兩小時不變，不用每次重新計算。

具體的產品形態，可以有加快取的餘地，但不意味著必須要加快取。除非遇到有效能問題，否則程式碼的可維護性、穩定性是最重要的。

再換個角度，如果行情的介面效能真的很慢，要怎麼優化呢？

不是直接暴露redis介面的，有更好的方法。
把行情獲取部分單獨封裝成為一個獨立函式，對外不依賴具體的內部實現。
不管是直接訪問行情服務、讀快取，還是訪問一個單獨封裝的優化行情服務模組，對外介面都不變。

整理下常見的避免過渡優化場景：

1、能同步實現的程式碼，就不要用非同步；

2、能實時實現的程式碼，就不要用定時；

3、能用資料來源讀取的，就不要用快取。

先保證程式簡潔，滿足效能要求，等遇到問題的時候，再去優化，避免過早優化，引入問題。

總結

解決問題前，先思考是否有問題，問題是什麼，而不是直接去做。

「如無必要，勿增實體」程式碼模組中，在沒有遇到問題時，不要引入過多的模組，快取，增加程式碼的複雜性。既不易於閱讀，也不易於維護。

遇到效能優化，不優化有問題，優化過渡，即使沒產生問題，也是浪費。