共计 2485 个字符，预计需要花费 7 分钟才能阅读完成。
作者 | YP
导读 ：在大部分场景中，前后端能够在开发前约定好数据接口，单方可能围绕约定并行地实现开发和自测。然而在大型零碎中一些后端模块有时并非直连前端，在它们之间可能蕴含一些其它模块的处理过程，为了保证数据真实有效，前端须要搭建整套环境来调试渲染成果，导致效率和研发体验一直劣化。本文次要介绍百度商业前端团队联合接口平台和数据中转能力优化前后端合作效率的尝试，无效的晋升了团队合作效力。
全文 2533 字，预计浏览工夫 7 分钟。
一、实际计划
咱们的实际次要分为两大阶段：
1. 合作提效；
2. 品质保障 & 体验优化。
其中合作提效包含根底能力建设和合作模式降级落地；品质保障 & 研发体验是在合作提效的根底上，对业务品质保障和极其场景所遇到的问题提出的一些解决方案。
二、数据中转能力
咱们团队所保护的后端模块是一个 BFF 层，负责适配上游和前端模块的数据，和前端业务联系十分严密。然而因为该层和前端之间还蕴含了一些策略和聚合的解决逻辑，大家在开发自测过程中没方法间接应用桩数据来预览成果，前端为了调试性能只能保护多套环境，除去环境搭建自身须要耗费大把工夫之外，模块连通性排查、资源协调，环境更新都会影响前端的工作效率。
为了缩小保护环境带来的精力耗费，咱们在实际初期尝试过屡次环境治理优化，成果都不是很现实，一方面无限的环境资源始终没方法很好地满足频繁迭代的须要，另一方面环境提供方也疲于应答各种各样的问题，所以咱们就想能不能不再保护线下环境，而是将开发测试的工作转移到线上环境下来进行，也就是让后端可能同时解决线上和线下数据申请，使前端在连接线上环境时看到线下数据的渲染后果。
基于这个思路，咱们在后端隔离出一套旁支逻辑定时地从 Redis 拉取线下物料数据和对应的设施信息，其中设施信息是某台手机或者某个浏览器惟一 id，当这些设施所对应的申请达到时，后端就把它当作一个非凡申请替换原有申请成线下数据，接着持续之后的处理过程，前端只须要将数据和设施信息写入到 Redis 就能接管到线下数据的处理结果，这样前端就像在应用一套始终保持最新版本的常驻环境，不会再被各种各样的环境保护问题耗费精力，单方都能在合作过程中更关注业务逻辑自身。
三、降级合作模式
借助数据中转能力，咱们胜利解决了环境保护艰难的问题，大幅地晋升了联调阶段的效率，但其实咱们在开发阶段的合作依然存在着一些问题。在能力建设初期咱们只反对了申请数据的替换，前端没方法在后端代码上线之前开始开发，这样串行的合作模式显然是有问题的，所以咱们就想能不能基于数据中转能力扩大出一套惯例的桩服务。
为了实现桩服务，咱们在须要作为桩输入给前端的数据上增加了非凡标识，当后端辨认到携带非凡标识的数据申请时就会跳过后续的解决逻辑，间接返回后果给上游模块。这种替换返回的模式可能让后端在开发前就将线下桩数据交付给前端应用，使前后端可能并行合作。
为了缩小学习和操作老本，咱们将以上所介绍的能力封装成平台提供给团队应用，后端能够依照我的项目为维度编辑和交付数据，前端能够拿这些数据去和设施做连贯，而后间接在 app 上刷新就能够看到成果。
四、数据分级
为了革新前后端合作模式，咱们在开发过程中应用的其实都是桩数据，这样可能会导致数据和最初实在逻辑所输入的后果存在差别，这些差别可能会裸露到线上影响业务性能，所以如果短少无效的措施去束缚数据应用的话，那么品质危险会变得难以管制。
为此，咱们将数据的应用依据规定和利用场景划分成三种类型：手动生成、线下后端生成、线上后端生成。
能够看到，数据的束缚规定随着我的项目的推动是逐渐收紧的。在开发后期后端能应用编辑生成出的桩数据疾速交付给前端，让前端实现单模块开发自测；在联调阶段，咱们的数据是由后端所开发实现的代码逻辑生成而来的，因为这部分数据须要保障肯定真实性，所以不再反对编辑，这样数据就可能匹配上后端行将上线的逻辑；而在后端上线实现之后，前端可能从线上检索系统采集到实在物料数据，通过扫码等形式进行成果预览，这样同时从数据和代码逻辑两方面保障了真实性。
通过上述对数据分级的布局，咱们保障了合作过程在高效并行运行的同时，始终遵循一套流程规范，可能无效地保障了业务的交付品质。
五、优化平台体验
通过后面三个步骤的优化，咱们在大部分的我的项目中曾经能让前后端解耦合作，然而在一些简单我的项目中这套流程反而会升高工作效率，这是因为简单我的项目往往须要笼罩的性能点更多，数据组合也相应的更多，咱们发现局部我的项目所须要的数据条数甚至超过两百条，这样后端就要破费大量的工夫和精力去录入和编辑数据，在这种极其需要下数据筹备工夫就成为了效率瓶颈，使得研发体验急剧下降。
为了解决这个问题，咱们围绕“片段”概念反对了对数据批量编辑的性能，能够让后端在编辑数据的过程中，将编辑的操作以“片段”的模式保留下来，每一个“片段”蕴含编辑的地位和值，这些“片段”能够持续利用到多个数据上，这样编辑工作就从屡次变成一次，大大减少了反复工作量。
同时，因为前端须要频繁对同一个性能进行例如版本兼容、题目长度兼容等细分状况的验证，为了更好的反对这种需要，咱们反对了“片段”的版本的性能，也就是在放弃“片段”操作地位不变的前提下，为“片段”赋予不同的值，前端能够通过切换“片段”的不同版本，疾速拿到同个性能下携带不同细节的数据去疾速地验证一些兼容成果。
六、总结
前后端数据接口合作降级使咱们的团队可能更稳固高效地实现产品迭代，团队的我的项目的均匀交付工夫缩小了 50% 以上，目前曾经有上千次的业务我的项目基于这套计划实现了开发测试和线上回归工作。咱们也在继续一直地摸索在如产品视觉验收、销售问题验证等其它方面落地的可能性，心愿能在更多的场景下晋升团队的合作效力。
——————END——————
举荐浏览：
前端的状态治理与工夫旅行：San 实际篇
百度 App 低端机优化 - 启动性能优化（概述篇）
面向大规模数据的云端治理，百度桑田存储产品解析
加强剖析在百度统计的实际
基于 TLS 1.3 的百度平安通信协议 bdtls 介绍
百度用户产品流批一体的实时数仓实际
如何治理资源节约？百度云原生老本优化最佳实际