面向复杂度编程随笔—其一

问题背景

前几天，和同事聊了这么一个场景：
交易系统，同时下单了商品 A & 商品 B，其中 A 商品买了10件，B 商品买了 20 件。正向订单已经签收，订单流转至完成态，此时正向订单里的两个商品 A & B 都可以分别申请售后（逆向订单）。

但是为了保证不至于买了 10 件，退了 11 件这种情况发生。逆向订单创建的时候，需要知道发起逆向的时候，正向订单已经发起了几件商品的逆向，据此决定本次逆向最多可以退多少件。

问题

此时有两个方案：

1. 正向订单的商品行上，冗余记录一个落库的 “可申请逆向数量” 字段。其维护的生命周期主要有两处：
   a. 正向订单流转至完结态时，此字段被设置为正向订单的商品行所购买数量
   b. 逆向订单创建时，此字段被扣减掉该次逆向订单申请的数量
2. 不再持久化“累计申请逆向数量”字段，改为每次要用的时候，根据正向订单关联的逆向订单实时计算。

该选哪个

客观来说，在一个自营的交易系统里，逆向订单数据量不大的情况下，两种方案都可以。

• 第一个方案，复杂度主要是逆向订单以及正向订单的其他流程里需要多维护一个字段，因为每用都直接取值 ，所以性能比较友好。
• 第二个方案，因为每用每算，所以性能上会差一点。但是在订单数据量不大的前提下，似乎也不是什么大问题。
  这样看，似乎应该选第一个方案才好。 但是实际上，此处我和同事商量后，更建议选第二个方案。

第一个方案，申请逆向本身的关键参数，依赖了正向订单，以及申请逆向时的多余参数，这会带来额外的理解成本。

因为需要确保设计功能需求时其他可能影响到 “可申请逆向数量” 的场景也必须保证自己能意识到这个字段的维护必要性和上下文。
试想，我们目前在做一个中台产品，又或者团队的核心人员有离职情况。
- 正向订单完结需要填充 “可申请逆向数量” 这一知识，可能被离职人员带走而导致后续维护人员忽略。
- 2B领域，针对其他团队二次开发则更是如此，没有哪个二开团队能主动注意到这一详细的细节。

第二个方案，因为申请逆向单流程每用每算，“可申请逆向数量” 这个字段自始至终，都被使用场景的代码持有和感知，因此，不管是核心人员有离职还是其他团队二次开发，均不会带来衍生的理解成本。因此，我们更建议这两种方案进行抉择时，选择第二种方案。大数据量的性能下降，就留给查询阶段做性能优化吧。

衍生思考

方案决策，不存在模棱两可的情况，A方案可以，B方案也可以的情况下，一定存在一个强理由，决定了你此时就应该选择 A方案抑或是 B方案。

这背后反应的是你一整套方案考量的时候，到底什么才是核心问题，这个问题自己一定要很清楚，确定清楚主次要矛盾，这远比问题的答案更关键。