对一次架构设计的总结和反思

　　最近做了一次架构（流程）的设计，简单来说，是设计一个流程，提供相应的API，方便其他程序员将业务逻辑逐步迁移到另一套框架。在完成这次设计的过程中，还是有许多经验、教训，值得思考和记录。其实，这些经验总结，可能在其他地方看到过，也听别人分享过，不过只是“夫子言之,于我心有戚戚焉”，只有当自己亲身经历过，才会更加深刻。

　　本文地址：https://www.cnblogs.com/xybaby/p/9763030.html

简单就是美

　　zen of python中提到 Simple is better than complex.

　　在google bigtable论文中也提到 The most important lesson we learned is the value of simple designs.

　　具体回到这次设计，由于这些流程都是异步的，且要保证一定的原子性，所以当交互的流程越多，需要维护的状态也会增多，出问题的概率也越大，这样在中途失败的情况回滚也会更麻烦。在最初版的设计中，流程图差不多有一页A4纸，通过缩减不必要的流程，最终方案流程图不到半页A4纸，最主要的是，这个流程维护起来更容易，出错的概率更低。

　　当然，流程的简化其实会在某些异常情况下有最终的业务有一定的影响，这其实也是要考虑性价比。

　　奥卡姆剃刀原理：如无必要，勿增实体。

　　

 多跟人讨论

　　虽然这个工作主要由我负责，但我发现经常与人讨论还是很有用的，不管讨论的对象是老手、还是小白。

　　如果是有相关经验的老手，往往能一针见血的指出问题所在，比如上面提到的流程简化，就是老手指出来的。如果对方对整个设计比较感兴趣，会问一些为什么，这些为什么其实能帮助自己思考，因为很多时候，自己并没有思考过为什么。即使对方不太明白我在干啥，在描述、解释一个细节的时候也常常会有茅塞顿开的感觉，与小黄鸭调试法异曲同工之妙。

　　

用数据说话，而不是脑补

　　这一点其实与第一点相关，流程简化之后，某些情况下部分用户会受到影响，这个产品经理的第一反应是不能接受的。但为了处理这部分异常情况就会使流程变得复杂，技术这边觉得性价比低。最后的方案是埋点测试，数据表明会影响的玩家比例很小，PM也就接受了简化后的流程。

Talk is cheap，show me the DATA!

与使用者沟通，尽早给出可体验的原型

　　这套流程主要是给项目内的其他程序使用，刚开始的时候只与核心程序讨论，而且是泛泛的讨论，导致流程并不完全符合实际情况。

　　

接口设计追求One Take

　　接口很重要，一旦交付使用，就很难在修改。

　　这一点是呈上的，由于开始的流程设计无法满足某些业务场景，导致需要修改一些API，但前一版本的API已经在代码中使用，为了修改这些API，需要去与相应程序沟通，大家集中替换、测试。幸好这些接口都还在内部系统使用，不涉及到线上业务，否则要修改起来就很困难了。

　　

好的接口 

　　easy to use，hard to misuse，来自 How to Design a Good API and Why it Matters

　　呈上，在流程中，会有一些默认的action，默认的参数，设计的原则是，这些默认值最多是代码不能正常工作，而绝对不能默默地以错误的方式工作。

流程图 状态机帮助思考与讨论

　　在这次设计中，经常对着流程图、状态机发呆，发现还是很有用，可以帮助理清思路，发现异常。跟他人讨论的时候，流程图也比口头描述直观很多。

墨菲定律

　　每一步都要有异常应对，有if 那么就应该对应 else，即使只是打一个日志。

　　在一个复杂的流程系统中，状态的自愈非常重要，这样即使出现一些异常，也能正常工作

　　

 

　　总结了感触最深的几点，不是很系统。