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

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

案例分析：

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

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