这种如何怎么怎么地，都是个人的思考，不一定非常的有效，就是为了适应目前的状态。作为开发，日常工作不少时候就是为了考虑到所有可能出现到的可能性，然后针对每种可能性做对应的处理。
如果考虑不周到，工具不够好，很容易把自己搞晕。
案例
app版本1：
用户下订单成功之前，我们存一个芝麻单子记录，但是状态为无效
芝麻单子免押成功，用户才能下订单，之后发送消息1给我们，更新芝麻单子为有效
app版本2：
用户下单之前，发送消息2给我们，存储预计的免押类型
用户下单之后不处理，下单之后进行免押，点击免押，我们存一个芝麻单子记录，但是状态为无效
免押成功，发送消息3给我们，存储实际的免押类型
条件：
- 免押成功 (成功，失败)
- 状态 (有效，无效) -> 对应订单有效，无效
- 版本2新记录 (有记录，无记录)
- 版本1记录 (在某些条件下，记录中同时存储了记录2)
需求：
撤销免押成功的，但是版本1，和版本2 订单无效的数据
- 对于版本1，免押成功，但是未下单
- 对于版本2，下单成功，但是实际免押类型不是芝麻单子
设计：
1 . 区分版本1和版本2数据
- 数据是订单传过来的，我们无法确定，要调用订单
- 有效数据一概不处理，无效状态数据包括(版本2的所有单子，版本1的未下单单子)
- 可以直接调用订单得知是哪个版本的单子(也可以根据自己已有的数据做一些简化)
2 . 针对不同版本，进行撤销
设计的问题：
假如消息不可信，会出现什么情况？
- 版本1，有效的单子但是目前是无效的
- 版本2，新纪录没有(这些没有记录的数据仍然可以调用订单)
反思
以上过程不是自己简化太多，这些东西不懂内部的业务短时间内不太容易和外人讲明白，但理清楚逻辑应该是相通的。
没有一个好的处理各种可能出现情况的工具，全靠字，靠说，不容易理清楚
- 产品版本的变化
- 考虑数据的不可信
- 数据变化的时机
做开发就是为了将这些变化进行提取抽象为可以控制的因素：
- 如何确定版本
- 数据不可信的话出现什么情况，怎么解决
- 数据变化时机要对业务熟悉，明白所有变化的情况，以及变化了什么东西
现实世界还是太复杂，程序却是很简单，理的头都大了，但是可能是这种挑战性，会慢慢的让自己进步。
最后
变化太多了，靠字，这些苍白的东西，效率低，没有记录的话，大家在一起干讨论，有时候就会发生讨论了1个小时，“哎，还是原来的方案有效”，好像上完了一堂课，突然发现这堂课早先上过了。
怎么把情形想的更全面，我想这是接下来要锻炼的吧。
网友评论