标签:时序图 正式 自己的 二维 过程 需求确认 命令 关心 核心
假设一个完整的项目,包含了6个不同的【端】:PC客户端、移动端、官网、支付页面、活动页面、以及后端、以及底层的核心功能组件开发。
假设有5个人分别负责5个【有脸】的【端】:PC客户端、移动端、官网、支付页面、活动页面;假设1个人负责开发后端,实际多少人不知道,这1个人是一个代表;假设2个人负责开发底层核心功能组件,实际多少人不知道,这2个人是一个代表;假设1个跟进的测试。
假设产品上,做好了MVP功能分析和设计,写了每个端的设计文档。此时产品【不能】直接把文档给每个端的负责人后,就等待着每个端的人做开发。此时需要做【需求确认】:跟每个端的负责人【正式】的开一个讨论,【逐条】核对设计,确认彼此对这个端需求的第一次【共识】。如果【没有】这一个必要的讨论,设计只存在于产品自己的脑子里。其他人可能会只看个大概,就开始写代码而已开始就留下和第1版需求不匹配的问题。
在开发中,不同的端会先从不依赖其他端的功能开始实现,涉及到需要和其他端对接的接口时。就一定要停下手里的工作,【优先】做【接口确认】:找其他端的负责人确认一个业务模型的接口设计,此时不应该只考虑这两个端之间,而应该能从整体构架上考虑,多个端之间的接口之间,应该有一个时序图,这个时序图展示了一条完整的业务流程:
经过这个讨论,每个端确认了自己这端的逻辑在1个业务流程中的【位置】和作用,同时对流程的全局有清晰的认识。
在理解这条业务流程后,达成了共识,但是还不够。在构架上,这些分散的流程点,应该被封装在一个公共组件中,每个端都依赖这个公共组件的接口和事件。假设该组件是C,那么:
应该针对这一条业务流程,以这个公共组件为入口,写【基于命令行】的【情景测试】代码。经过基本测试可用后,才提交接口实现,并通知其他端接口和组件可用。
从覆盖率上考虑,应该针对每个独立的接口,编写针对接口的单元测试。包含正常的数据和不正常的数据的测试和断言等。可以由开发人员编写,或者【分工】给有编写单元测试代码能力的测试编写。
到这里,针对1个业务流程,形成涉及多端的设计、对接、封装、测试的【闭环】,而不致于变成每个端都一知半解的【玩具接口对接】。在多次迭代中,会持续对这个链条做调整,逐步完成对链条的完整认识。程序开发环境一直在分裂,客户端多多样化,后端的分布式化,开发环境在【裂化】,做好1个业务流程的接口设计和对接,需要有整体的闭环,以规避程序开发中“不识庐山真面目,只缘身在此山中”问题。
--end--
标签:时序图 正式 自己的 二维 过程 需求确认 命令 关心 核心
原文地址:https://www.cnblogs.com/math/p/rule-003.html