STAR法则

即为Situation Task Action Result的缩写，具体含义是:

• Situation: 事情是在什么情况下发生
• Task: 你是如何明确你的任务的
• Action: 针对这样的情况分析，你采用了什么行动方式
• Result: 结果怎样，在这样的情况下你学习到了什么

掌柜宝网关系统

1. 项目简介

掌柜宝是一个面向小B用户进货的APP，小B用户指的是各个小超市，小门店，零售店老板。
掌柜宝网关系统，顾名思义，是对掌柜宝提供数据的网关系统。

2. 项目内容

所以掌柜宝就和正常的购物APP一样，需要有商品，促销，订单，用户，库存，物流这些基础模块。对应到页面就是，首页，活动页，列表页，商详页，搜索页，购物车，“我的”页。

3. 我的职责

我在项目中主要负责购物车、商详页和搜索页。

4. 购物车 问题 解决方案 学到什么

我们的基础数据都是通过RPC框架调用B2B业务的接口，其中购物车调用接口可以拿到商品信息、价格信息、促销信息。然后我们需要根据用户的收货地址，查询商品的库存，用于校验购物车数据，反选无货的商品、赠品，自动勾选满足促销的赠品。最后我们会根据业务规则设置相应的促销文案。

购物车的性能问题一直是我们的瓶颈，因为不停的迭代，从一个简单的购物车变成了复杂的包含各种业务逻辑的购物车。涉及到对RPC获取到的数据的格式转换，需要反复调用RPC的操作，例如：购物车库存查询、无货反选、限购数量重置，还有下架商品置底、促销文案设置、促销数据设置等等操作。因为一些重复的RPC调用和复杂的逻辑操作导致性能下降。

所以我们把RPC操作和本地操作区分开。获取到购物车数据后，我们先进行RPC操作，例如：重置不正确的数量，查库存，根据库存反选或选中主商品、赠品，最后我们再进行数据的本地操作，包括促销文案，下架商品置底这样的。

这个问题的处理让我认识到两个问题的重要性，第一，是在做最初设计的时候，应尽可能的考虑到功能的扩展性，第二，是重构的重要性，因为互联网现在就是做产品，业务需求是不会断的，所以我们在不能看清将来会产生何种问题的情况下，应考虑对功能的扩展性。然后随着业务的发展，不断的重构在保证功能完整性的同事还能保证代码的健壮性。

5. 商详页 问题 解决方案 学到什么

商详页也遇到了性能问题，因为我们商详页是一个接口返回商详页所有数据，在做缓存的时候也是缓存整个商详页的数据。
随着业务的复杂，商详页原始的一个接口同步返回所有数据在性能上不再那么理想。

所以我们做了动静分离，把商品的基本信息以及一些静态的扩展数据在一个接口返回，而且通过redis缓存这些不经常变的数据10S，其他像价格，库存，促销等这些实时性要求较高的数据我们实时调用RPC获取数据通过另一个新接口返回，当然价格库存之类的数据我们也会做缓存，只不过缓存时间很多，可以近似看做是实时获取。前端获取静态数据进行页面的渲染，异步调用动态数据接口对价格和库存等信息动态渲染。这样的话，用户在商详页看到的数据加载就会快很多。

这个问题的处理让我学习到针对不同的业务功能，我们可以做到功能的细化和拆分，通过合理的解耦，可以降低各模块的依赖性，优化各模块的性能，提升用户体验。