关于代码效率提升的方法心路历程（购物车）
给为园友们，大家好，最近一直解决执行提速，分析老代码的逻辑并提出优化方案，在这个过程中发现了很多不好的习惯，导致很多程序逻辑执行效率低下，现在将其总结一下，如果大家觉得有参考意义，就看一下，如果觉得有问题，多多指点，如果觉得写的不好，也勿喷，谢谢！
案例分析：
关于购物车效率的提升，在优化前，购物车需要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、多给自己充电，积累经验，这样才能够找到合理的方法
要善于接受新的事物，不然自己就会慢慢的跟不上节奏。
原文地址：https://www.cnblogs.com/xiaoXuZhi/p/code_optimization.html