前后端数据接口协作提效实践

2022 年 8 月 30 日
上海
本文字数：2446 字
阅读完需：约 8 分钟

作者 | YP

导读：在大部分场景中，前后端可以在开发前约定好数据接口，双方能够围绕约定并行地完成开发和自测。然而在大型系统中一些后端模块有时并非直连前端，在它们之间可能包含一些其它模块的处理过程，为了保证数据真实有效，前端需要搭建整套环境来调试渲染效果，导致效率和研发体验不断劣化。本文主要介绍百度商业前端团队结合接口平台和数据直达能力优化前后端协作效率的尝试，有效的提升了团队协作效能。
全文 2533 字，预计阅读时间 7 分钟。

一、实践方案

我们的实践主要分为两大阶段：

1. 协作提效；

2. 质量保障 &体验优化。

其中协作提效包括基础能力建设和协作模式升级落地；质量保障 &研发体验是在协作提效的基础上，对业务质量保障和极端场景所遇到的问题提出的一些解决方案。

二、数据直达能力

我们团队所维护的后端模块是一个 BFF 层，负责适配上游和前端模块的数据，和前端业务联系非常紧密。然而由于该层和前端之间还包含了一些策略和聚合的处理逻辑，大家在开发自测过程中没办法直接使用桩数据来预览效果，前端为了调试功能只能维护多套环境，除去环境搭建本身需要消耗大把时间之外，模块连通性排查、资源协调，环境更新都会影响前端的工作效率。

为了减少维护环境带来的精力消耗，我们在实践初期尝试过多次环境管理优化，效果都不是很理想，一方面有限的环境资源始终没办法很好地满足频繁迭代的需要，另一方面环境提供方也疲于应对各种各样的问题，所以我们就想能不能不再维护线下环境，而是将开发测试的工作转移到线上环境上去进行，也就是让后端能够同时处理线上和线下数据请求，使前端在连接线上环境时看到线下数据的渲染结果。

基于这个思路，我们在后端隔离出一套旁支逻辑定时地从 Redis 拉取线下物料数据和对应的设备信息，其中设备信息是某台手机或者某个浏览器唯一 id，当这些设备所对应的请求到达时，后端就把它当作一个特殊请求替换原有请求成线下数据，接着继续之后的处理过程，前端只需要将数据和设备信息写入到 Redis 就能接收到线下数据的处理结果，这样前端就像在使用一套始终保持最新版本的常驻环境，不会再被各种各样的环境维护问题消耗精力，双方都能在协作过程中更关注业务逻辑本身。

三、升级协作模式

借助数据直达能力，我们成功解决了环境维护困难的问题，大幅地提升了联调阶段的效率，但其实我们在开发阶段的协作仍然存在着一些问题。在能力建设初期我们只支持了请求数据的替换，前端没办法在后端代码上线之前开始开发，这样串行的协作模式显然是有问题的，所以我们就想能不能基于数据直达能力扩展出一套常规的桩服务。

为了实现桩服务，我们在需要作为桩输出给前端的数据上添加了特殊标识，当后端识别到携带特殊标识的数据请求时就会跳过后续的处理逻辑，直接返回结果给下游模块。这种替换返回的模式能够让后端在开发前就将线下桩数据交付给前端使用，使前后端能够并行协作。

为了减少学习和操作成本，我们将以上所介绍的能力封装成平台提供给团队使用，后端可以按照项目为维度编辑和交付数据，前端可以拿这些数据去和设备做连接，然后直接在 app 上刷新就可以看到效果。

四、数据分级

为了改造前后端协作模式，我们在开发过程中使用的其实都是桩数据，这样可能会导致数据和最后真实逻辑所输出的结果存在差异，这些差异可能会暴露到线上影响业务功能，所以如果缺少有效的措施去约束数据使用的话，那么质量风险会变得难以控制。

为此，我们将数据的使用根据规则和应用场景划分成三种类型：手动生成、线下后端生成、线上后端生成。

可以看到，数据的约束规则随着项目的推进是逐步收紧的。在开发前期后端能使用编辑生成出的桩数据快速交付给前端，让前端完成单模块开发自测；在联调阶段，我们的数据是由后端所开发完成的代码逻辑生成而来的，由于这部分数据需要保证一定真实性，所以不再支持编辑，这样数据就能够匹配上后端即将上线的逻辑；而在后端上线完成之后，前端能够从线上检索系统采集到真实物料数据，通过扫码等方式进行效果预览，这样同时从数据和代码逻辑两方面保证了真实性。

通过上述对数据分级的规划，我们保证了协作过程在高效并行运转的同时，始终遵循一套流程标准，能够有效地保障了业务的交付质量。

五、优化平台体验

经过前面三个步骤的优化，我们在大部分的项目中已经能让前后端解耦协作，然而在一些复杂项目中这套流程反而会降低工作效率，这是因为复杂项目往往需要覆盖的功能点更多，数据组合也相应的更多，我们发现部分项目所需要的数据条数甚至超过两百条，这样后端就要花费大量的时间和精力去录入和编辑数据，在这种极端需求下数据准备时间就成为了效率瓶颈，使得研发体验急剧下降。

为了解决这个问题，我们围绕“片段”概念支持了对数据批量编辑的功能，可以让后端在编辑数据的过程中，将编辑的操作以“片段”的形式保存下来，每一个“片段”包含编辑的位置和值，这些“片段”可以继续应用到多个数据上，这样编辑工作就从多次变成一次，大大减少了重复工作量。

同时，由于前端需要频繁对同一个功能进行例如版本兼容、标题长度兼容等细分情况的验证，为了更好的支持这种需求，我们支持了“片段”的版本的功能，也就是在保持“片段”操作位置不变的前提下，为“片段”赋予不同的值，前端可以通过切换“片段”的不同版本，快速拿到同个功能下携带不同细节的数据去快速地验证一些兼容效果。