關於程式碼效率提升的方法心路歷程（購物車）
關於程式碼效率提升的方法心路歷程（購物車）
給為園友們，大家好，最近一直解決執行提速，分析老程式碼的邏輯並提出優化方案，在這個過程中發現了很多不好的習慣，導致很多程式邏輯執行效率低下，現在將其總結一下，如果大家覺得有參考意義，就看一下，如果覺得有問題，多多指點，如果覺得寫的不好，也勿噴，謝謝！
案例分析：
關於購物車效率的提升，在優化前，購物車需要3-5分鐘才能夠查詢出來資料，並且購物所有商品全部重新整理重新渲染。這個購物車計算價格的程式碼還是一個工作20年左右的前輩寫的，並且找了很久的優化方案（只侷限在自己的介面程式碼邏輯），覺得邏輯已經不能在優化了。對此，我將整理執行邏輯分析了一下，發現有很大的提升空間，下面的是我一個分析邏輯：
我分析了一下現在購物的程式碼呼叫執行邏輯
1、初始化購物車時，購物車全商品渲染（獲取商品、獲取優惠券等）（沒問題）
2、購物車商品增減操作步驟
2.1：呼叫獨立介面只更新對應的商品數量
2.2：數量更新後，在按照初始化購物的邏輯一樣
重新獲取資料渲染頁面
3、後端介面計算價格邏輯
3.1：獲取根據使用者獲取購物車商品
3.2：遍歷每一個商品計算對應的價格
3.2.1：獲取該商品的價格因子資料
3.2.2：根據商品查詢最近的配送倉庫
3.3：其他業務邏輯處理
這樣下來，一個商品的價格計算完成，都是需要呼叫10次左右的資料庫
購物車商品數量越多，資料庫操作次數是成倍數增加
其實，經驗好一點的同學，一看就知道里面的問題所在
我給出的優化方案從兩個點出發，其一、前後端資料互動上改進；其二、介面計算價格邏輯改進，具體如下：
其一、前後端資料互動上改進
減少不必要的資料互動方式，具體體現在：
a、購物車商品數量傳送改變時，不在整體渲染購物車列表
b、購物車商品數量傳送改變時，去掉不必要的介面呼叫
c、最終數量改變，只調用一個介面搞定，介面的具體功能是：
c1：對該使用者的該商品的購物車資料做加減
C2：如果操作成功，那麼重新計算該商品對應的店鋪的購物車商品價格資料，並返回前端，前端只渲染處理該店鋪的商品資料即可
其二、後端計算價格邏輯改造
改造簡單思路是：想獲取所有資料集合，具體的資料組裝加工放在記憶體中加工，這樣減少資料庫操作，
a：獲取根據使用者獲取購物車商品
如果是更新購物車數量計算價格，需要加一個店鋪限制條件
b：根據獲取到的所有商品，批量獲取影響這一些商品的價格因子集合
c：根據獲取到的所有商品，批量獲取對應的店鋪的倉庫訊息集合
d：遍歷商品
根據獲取到價格因子，計算價格
根據獲取到的倉庫訊息，計算最近的倉庫配置地
優化後的結果：
1、初始化購物車40個商品也就只需要1S不到
2、商品加減操作，響應速度毫秒級
為了讓整方案能夠實施起來，也是提了幾次建議，最後才接收採納，現在想來不容易啊，自己都不知道為什麼執行起來這麼曲折。
當然，目前的效果，也還有優化提升的空間，我也給了一下建議
1、可以加上一些快取機制，比如服務端對使用者購物車資料快取5分鐘
對於大部分使用者來說，在購物車操作一次資料不會等待5分鐘
這樣還能進一步提高效率
2、價格計算可以放到前端計算，這而可以加一下策略機制
比如在購物車頁面停留達到一定時間，前端重新取一次最新的價格因子等資訊
為什麼說，可以將價格計算在前端算，我個人理解，在購物車的價格只是一個展示，並不是使用者的最終購物價格，最終價格都是在結算頁面下單時計算為準。即使價格每次採用後端計算，那麼使用者在結算的時候，也不一定就是購物車展示的價格，因為，在使用者在購物車停留期間，也有可能後臺價格因子發改變，到賬到結算頁面的最終價格與購物車價格不一致。
小結
通過上面的購物車改進案例分析，總結如下：
1、在優化某一功能時，一定要站在全域性去剖析問題
2、在具體的優化點上，一定要考慮分析問題的瓶頸點，
找到最優的解決辦法，而不是隻是把功能實現就完事了
多問一個為什麼要這樣處理？還有最優的策略嗎？
不然，我們和初級程式設計師有什麼優勢呢？
3、多給自己充電，積累經驗，這樣才能夠找到合理的方法
要善於接受新的事物，不然自己就會慢慢的跟不上節奏。