關於程式碼效率提升的方法心路歷程(購物車)
關於程式碼效率提升的方法心路歷程(購物車)
給為園友們,大家好,最近一直解決執行提速,分析老程式碼的邏輯並提出優化方案,在這個過程中發現了很多不好的習慣,導致很多程式邏輯執行效率低下,現在將其總結一下,如果大家覺得有參考意義,就看一下,如果覺得有問題,多多指點,如果覺得寫的不好,也勿噴,謝謝!
案例分析:
關於購物車效率的提升,在優化前,購物車需要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、多給自己充電,積累經驗,這樣才能夠找到合理的方法
要善於接受新的事物,不然自己就會慢慢的跟不上節奏。