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

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

导读

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

一、实践方案

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

1. 协作提效；

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

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

二、数据直达能力

三、升级协作模式

GEEK TALK 借助数据直达能力，我们成功解决了环境维护困难的问题，大幅地提升了联调阶段的效率，但其实我们在开发阶段的协作仍然存在着一些问题。在能力建设初期我们只支持了请求数据的替换，前端没办法在后端代码上线之前开始开发，这样串行的协作模式显然是有问题的，所以我们就想能不能基于数据直达能力扩展出一套常规的桩服务。 为了实现桩服务，我们在需要作为桩输出给前端的数据上添加了特殊标识，当后端识别到携带特殊标识的数据请求时就会跳过后续的处理逻辑，直接返回结果给下游模块。这种替换返回的模式能够让后端在开发前就将线下桩数据交付给前端使用，使前后端能够并行协作。

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

四、数据分级

GEEK TALK 为了改造前后端协作模式，我们在开发过程中使用的其实都是桩数据，这样可能会导致数据和最后真实逻辑所输出的结果存在差异，这些差异可能会暴露到线上影响业务功能，所以如果缺少有效的措施去约束数据使用的话，那么质量风险会变得难以控制。 为此，我们将数据的使用根据规则和应用场景划分成三种类型：手动生成、线下后端生成、线上后端生成。

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

五、优化平台体验

GEEK TALK 经过前面三个步骤的优化，我们在大部分的项目中已经能让前后端解耦协作，然而在一些复杂项目中这套流程反而会降低工作效率，这是因为复杂项目往往需要覆盖的功能点更多，数据组合也相应的更多，我们发现部分项目所需要的数据条数甚至超过两百条，这样后端就要花费大量的时间和精力去录入和编辑数据，在这种极端需求下数据准备时间就成为了效率瓶颈，使得研发体验急剧下降。 为了解决这个问题，我们围绕“片段”概念支持了对数据批量编辑的功能，可以让后端在编辑数据的过程中，将编辑的操作以“片段”的形式保存下来，每一个“片段”包含编辑的位置和值，这些“片段”可以继续应用到多个数据上，这样编辑工作就从多次变成一次，大大减少了重复工作量。

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

六、总结

GEEK TALK 前后端数据接口协作升级使我们的团队能够更稳定高效地完成产品迭代，团队的项目的平均交付时间减少了50%以上，目前已经有上千次的业务项目基于这套方案完成了开发测试和线上回归工作。我们也在持续不断地探索在如产品视觉验收、销售问题验证等其它方面落地的可能性，希望能在更多的场景下提升团队的协作效能。

END

审核编辑 ：李倩

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。