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


  最近做了一次架构(流程)的设计,简单来说,是设计一个流程,提供相应的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,即使只是打一个日志。

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

  

 

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

posted @ 2018-10-14 12:03 xybaby 阅读(...) 评论(...) 编辑 收藏