關于代碼效率提升的方法心路歷程（購物車）

　　給為園友們，大家好，最近一直解決執行提速，分析老代碼的邏輯并提出優化方案，在這個過程中發現了很多不好的習慣，導致很多程序邏輯執行效率低下，現在將其總結一下，如果大家覺得有參考意義，就看一下，如果覺得有問題，多多指點，如果覺得寫的不好，也勿噴，謝謝！

案例分析：

　　關于購物車效率的提升，在優化前，購物車需要3-5秒才能夠查詢出來數據，并且購物所有商品全部刷新重新渲染。對此，我將整理執行邏輯分析了一下，發現有很大的提升空間，下面的是我一個分析邏輯：

　　我分析了一下現在購物的代碼調用執行邏輯

　　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：遍歷商品

　　　　d1：根據獲取到價格因子，計算價格

　　　　d2：根據獲取到的倉庫消息，計算最近的倉庫配置地

? 優化后的結果：

　　1、初始化購物車40個商品也就只需要1S不到

　　2、商品加減操作，響應速度毫秒級

　　　　為了讓整方案能夠實施起來，也是提了幾次建議，最后才接收采納，現在想來不容易啊，自己都不知道為什么執行起來這么曲折。

　　當然，目前的效果，也還有優化提升的空間，我也給了一下建議

　　1、可以加上一些緩存機制，比如服務端對用戶購物車數據緩存5分鐘

???????　　對于大部分用戶來說，在購物車操作一次數據不會等待5分鐘

　　　　這樣還能進一步提高效率

　　2、價格計算可以放到前端計算，這而可以加一下策略機制

　　　　比如在購物車頁面停留達到一定時間，前端重新取一次最新的價格因子等信息

???　　　為什么說，可以將價格計算在前端算，我個人理解，在購物車的價格只是一個展示，并不是用戶的最終購物價格，最終價格都是在結算頁面下單時計算為準。即使價格每次采用后端計算，那么用戶在結算的時候，也不一定就是購物車展示的價格，因為，在用戶在購物車停留期間，也有可能后臺價格因子發改變，到賬到結算頁面的最終價格與購物車價格不一致。

小結

通過上面的購物車改進案例分析，總結如下：

1、在優化某一功能時，一定要站在全局去剖析問題

2、在具體的優化點上，一定要考慮分析問題的瓶頸點，

　　找到最優的解決辦法，而不是只是把功能實現就完事了

　　多問一個為什么要這樣處理？還有最優的策略嗎？

　　不然，我們和初級程序員有什么優勢呢？

3、多給自己充電，積累經驗，這樣才能夠找到合理的方法

?　　??要善于接受新的事物，不然自己就會慢慢的跟不上節奏。

轉載于:https://www.cnblogs.com/xiaoXuZhi/p/code_optimization.html

總結

以上是生活随笔為你收集整理的关于代码效率提升的方法心路历程（购物车）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。