关于代码效率提升的方法心路历程（购物车）

关于代码效率提升的方法心路历程（购物车）

给为园友们，大家好，最近一直解决执行提速，分析老代码的逻辑并提出优化方案，在这个过程中发现了很多不好的习惯，导致很多程序逻辑执行效率低下，现在将其总结一下，如果大家觉得有参考意义，就看一下，如果觉得有问题，多多指点，如果觉得写的不好，也勿喷，谢谢！

案例分析：

关于购物车效率的提升，在优化前，购物车需要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、多给自己充电，积累经验，这样才能够找到合理的方法

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