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

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

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

案例分析:

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

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券