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

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

　　本文地址：http://www.javashuo.com/article/p-mwnfhzwz-kk.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，即便只是打一个日志。

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

　　

 

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