1. 程式人生 > >關於程式碼效率提升的方法心路歷程(購物車)

關於程式碼效率提升的方法心路歷程(購物車)

關於程式碼效率提升的方法心路歷程(購物車)

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

案例分析:

關於購物車效率的提升,在優化前,購物車需要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、多給自己充電,積累經驗,這樣才能夠找到合理的方法

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