之前想过一次相关东西，提升解决问题能力的思考，不过真正做事的时候，还是有问题。如果不出问题，人可能会无聊吧，出了问题，才有机会找到自己的盲区进行弥补。
年前的时候有发现一个问题，当时想的推到年后再解决吧，果然年后问题又暴露了。
问题
支付宝在预授权冻结成功的时候会给我们发送通知，这个是官方消息比较可靠。但是失败的时候，我们无法立刻得知结果，而业务进行实际免押按钮要置灰的话，需要知道及时的结果。
因此需要知道冻结失败，轮询支付宝不好，就采用接受mapi传过来的结果。
问题是mapi传过来的结果不可信，另外在客户端预授权冻结失败的时候，支付宝app没有返回标志性信息，标志性信息需要客户端维护。最终导致mapi传给我们混乱数据，并且我们没有做有效验证。
这个东西客户端是第一手数据源，客户端告诉我们数据是什么，然后来问我们数据是什么，我觉得这样多个步骤也容易出问题。
思考
- 很多时候我们面临的情况是未知的，边走边想怎么处理的。但是团队协作的时候，最好养成大家一起讨论的习惯。
支付宝app在预授权失败的时候没有返回有效的标志时，这个信息流到我这里就没有再往下走了，我就和mapi商量，让他直接传给我标记，当时想的是这种模糊的东西，离数据的源头越远越不好。讨论方案没问题，但是这种冻结失败没有有效数据的，貌似团队的人都不知道。
一个人的力量是小的，团队的力量是大的，虽然东西不在我们这里解决，但是有问题起码让大家知道。
- 多想一步，其实还是刨根问底。
在客户端都无法获取有效标记的时候，mapi面临的处境和我是一样的，接触的都不是最源头的数据。都可能是错误的数据，这个时候其实自己可以多关注mapi是如何处理的。问清楚具体怎么弄的。
而目前自己的做法是，这个数据离我太远了，让mapi处理吧，然后不管了。我自己都不太清楚怎么处理的时候，mapi难道一定知道怎么处理吗？不要把锅丢给别人就不管了。
自己比较迷糊的地方，要问清楚，留下疑点不好
- 外部系统都可能会出错，不要放过出错的可能性。
在开发的时候，脑子里闪过这个念头，“mapi会不会把支付宝请求号弄错？毕竟不好获取”，当时就是想了这个问题，然后就自己回答：“应该没问题”
太乐观了，突然想到“明修栈道暗度陈仓”，项羽太自信就给了刘邦机会过来打败自己。
开发的时候保持悲观的思考，比太自信强。如果有疑问，最好把它揪出来，而不是偷懒。我这里也是想到了外部可能会出错，但是还是放过它了。
额外
出了问题，才想这个东西有什么影响时，有点晚了，最好再设计的时候就要想清楚这个东西有什么影响。各种问题可能有什么情况，在设计的时候如果考虑影响，也是考虑的更加全面的一种方式。
如果出了问题，提前想的话，就能更快的想到影响，采取的方案。方案设计的时候，除了正常情况，考虑异常的时候如何进行降级，高可用的处理。
稳定性，灾备，常规稳定性保障流程及手段，业务存在不合理的地方，需要流程梳理并优化的地方，是不是要从业务角度出发，做隔离，降级，高可用的手段。
而不是仅仅简单的思考：“应该没问题”
最后
做事多想一步，提前想到。
-
出现状况拿出来和大家一起讨论
-
养成不放过任何疑点的习惯
-
刨根问底，有时候怕麻烦别人，但是有问题，就是麻烦自己了
网友评论