码迷,mamicode.com
首页 > 其他好文 > 详细

炼金术(3): 怎样做好1个业务流程的接口对接

时间:2020-01-10 00:42:22      阅读:85      评论:0      收藏:0      [点我收藏+]

标签:时序图   正式   自己的   二维   过程   需求确认   命令   关心   核心   

假设一个完整的项目,包含了6个不同的【端】:PC客户端、移动端、官网、支付页面、活动页面、以及后端、以及底层的核心功能组件开发。

假设有5个人分别负责5个【有脸】的【端】:PC客户端、移动端、官网、支付页面、活动页面;假设1个人负责开发后端,实际多少人不知道,这1个人是一个代表;假设2个人负责开发底层核心功能组件,实际多少人不知道,这2个人是一个代表;假设1个跟进的测试。

假设产品上,做好了MVP功能分析和设计,写了每个端的设计文档。此时产品【不能】直接把文档给每个端的负责人后,就等待着每个端的人做开发。此时需要做【需求确认】:跟每个端的负责人【正式】的开一个讨论,【逐条】核对设计,确认彼此对这个端需求的第一次【共识】。如果【没有】这一个必要的讨论,设计只存在于产品自己的脑子里。其他人可能会只看个大概,就开始写代码而已开始就留下和第1版需求不匹配的问题。

在开发中,不同的端会先从不依赖其他端的功能开始实现,涉及到需要和其他端对接的接口时。就一定要停下手里的工作,【优先】做【接口确认】:找其他端的负责人确认一个业务模型的接口设计,此时不应该只考虑这两个端之间,而应该能从整体构架上考虑,多个端之间的接口之间,应该有一个时序图,这个时序图展示了一条完整的业务流程:

  1. 从哪些入口开始发起业务,假设在A端,调用了入口startXXX。
  2. 从入口开始考虑完整的接口调用【闭环】:
    • 依赖了其他端的哪些接口,比如像后端调用1个或N个接口。
    • 监听了其他端的哪些事件,比如监听了后端的1个或N个事件。
    • 过程中是否跳转到了其他端,例如显示一个二维码,扫码后跳转到了网页,在网页那边做了什么处理,例如调用了后端接口,后端接口又触发了事件给A端。

经过这个讨论,每个端确认了自己这端的逻辑在1个业务流程中的【位置】和作用,同时对流程的全局有清晰的认识。

在理解这条业务流程后,达成了共识,但是还不够。在构架上,这些分散的流程点,应该被封装在一个公共组件中,每个端都依赖这个公共组件的接口和事件。假设该组件是C,那么:

  1. C应该提供一组【满足不同需求的入口】接口,以便满足不同端的不同场景入口调用需求。
  2. C应该提供一套标准的事件,不同的入口都应该触发后续【一致的事件流】。使得每个端针对同一个业务要关心的事件流是一致的。
  3. C应该把细节隐藏在内部,在内部做好【完整的状态机】,以及做好完整的错误处理、超时处理、重试机制等等。

应该针对这一条业务流程,以这个公共组件为入口,写【基于命令行】的【情景测试】代码。经过基本测试可用后,才提交接口实现,并通知其他端接口和组件可用。

从覆盖率上考虑,应该针对每个独立的接口,编写针对接口的单元测试。包含正常的数据和不正常的数据的测试和断言等。可以由开发人员编写,或者【分工】给有编写单元测试代码能力的测试编写。

到这里,针对1个业务流程,形成涉及多端的设计、对接、封装、测试的【闭环】,而不致于变成每个端都一知半解的【玩具接口对接】。在多次迭代中,会持续对这个链条做调整,逐步完成对链条的完整认识。程序开发环境一直在分裂,客户端多多样化,后端的分布式化,开发环境在【裂化】,做好1个业务流程的接口设计和对接,需要有整体的闭环,以规避程序开发中“不识庐山真面目,只缘身在此山中”问题。

--end--

炼金术(3): 怎样做好1个业务流程的接口对接

标签:时序图   正式   自己的   二维   过程   需求确认   命令   关心   核心   

原文地址:https://www.cnblogs.com/math/p/rule-003.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!