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