购物车设计
2017-02-03
简介
新版购物车是我在入职厨房后写的第一个大的项目，前前后后花了大概一个多月的时间，中间也伴随着部分代码的重构。在学校待了半年，虽然给老师干活也写了不少代码，不过差别还是挺大的，写完这个项目后感觉算是找到了工作的感觉。
不多说，开始入正题。
旧版购物车分析
先来分析一下旧版购物车的问题，如下图:
旧版购物车印象中一直都是这个样子，至少从我15年初成为厨房用户到16年8月升级这段时间一直没什么大变化，乍一看上去感觉挑不出什么问题，但是实际在用的时候，特别是遇到促销这种活动的时候，局限性就显示出来了。
首先，信息量太少，这是个很直观的感觉，除了店铺、商品、商品状态、单价还有数量外没有其他信息了，这样就有很多问题：
- 店铺以及商品上的优惠无法体现
- 领店铺券的操作比较复杂
- 商品失效原因不明
- 存在优惠，所以这里显示的单价和结算页面的单价是不一样的，对用户来说会很混乱
- 促销活动时的商品无标签，加购后很难区分
上面这几条是单就使用和平时运营层面上讲考虑到的问题，作为平台方最期望的事情还是用户直接下单或者加购后尽快下单，而对用户来讲，同样的东西越少钱买到越好，所以 这里面的优惠信息以及领券就很重要了；还有一点是在 API 层面上，旧版购物车 API 在返回购物车 item 的时候不是按照店铺来返回，而是按照更新时间直接返回的 购物车 item 的列表，而按店铺分开的操作都是客户端做的，这样的一个问题是，每个 item 除了商品信息还要附带一个店铺信息，一个极端的例子就是如果用户加购了 一家店铺的100件商品，在购物车的那个 API 里，有99个 item 里面的店铺信息都是多余的。
基于上面这些原因，升级购物车是必然的，途中主要参考的是淘宝的购物车，然后根据我们自己的情况将整个购物车模块进行了重构。
新版购物车分析
然后这里是新版的购物车，如下图：
首先，将失效商品和有效商品分开
首先，在购物车内可以直接领店铺券，店铺有优惠券会在店铺右边有一个领券按钮，这样服务端可以复用已有的领券 API，客户端这里也可以复用已有的组件。
———–2019年3月更新—————-
开发过程
略。。。
API 设计
略。。。
心得和总结
- 做好代码的抽象和拆分
- CRUD 操作要时刻考虑性能问题
- 复杂逻辑写好注释
- 黑魔法少用，可维护性姑且算是第一