你想知道的前后端协作规范都在这了

,你是否在为如何制定前后端协作规范而发愁？干货来啦，一文带你了解我们团队内部沉淀并践行已久的前后端协作规范，读完本文，回去大胆拒绝你后端的不合理设计！
,假如你要在团队内部推一套规范，那么首先你得知道为什么需要制定协作规范呢？有规范会带来什么好处呢？
,随着前后端分离开发模式大行其道，前端和后端已经在两个方向上渐行渐远，各自深耕细作、术业专攻。前端更加关注交互视觉体验，而后端对高并发、高性能、高扩展上要求更高。这就导致大部分的前端和后端之间会存在所谓的”代沟“，我不知道你的数据如何存储，你不知道我的页面如何渲染。
,因此，很有必要制定前后端开发上的规范来抹平代沟，有了协作规范，便有了前后端开发默契，也因此达到了提高开发效率、降低沟通成本的作用。
,首先是协作的流程规范，相信每个团队在前后端协作中都有各自的开发模式和开发流程来保障效率和质量，我们团队的前后端协作大致流程如下图所示：
,,以下总结了我们团队内部在协作中遇到的比较典型的 Bad Case 以及解决方案，我相信大家在开发过程中也遇到过类似的痛点经历：
,【现象】
,,【解决】
,注：如果功能简单，前端也可以做判断，如何鉴定是否简单？从代码层面比如 If 判断中超过 2 个条件，按钮显示超过 2 个条件，可视作复杂逻辑，逻辑移到后端处理。建议一开始就视作复杂去处理，这样后期就不用再调整。,【好处】
,【现象】
,,【解决】
,1、后端做好数据的整合，避免数据在前端的重组。
,2、Tree 数据展示的场景，如果数据不大后端全量返回，如果数据量过大异步返回，但异步返回存在后续的回显和搜索展示方面问题。
,3、同一个业务功能，一个接口搞定，不要分接口进行，后端业务考虑复用可包装新接口或原接口加参数兼容。
,【好处】
,   减少前后端数据处理的成本，提高性能和用户体验
,【现象】
,【解决】
,   如果是状态定死的情况下譬如：选项为【是、否】可无需后端返回。,【好处】
,【现象】
,【解决】
,【好处】
,【现象】
,【解决】
,【现象】
,【解决】
,【现象】
,【解决】
,【现象】
,    由于 A 和 B 是不同业务线后端，接口对接以及后期的沟通维护成本会比较高。例如该接口发生改动，需要跨业务线通知到对应的前端（该后端还不一定知道前端是哪位）；并且接口返回的大量字段前端都用不到。
,【解决】
,【现象】
,【解决】
,类型 10：后端一个接口拆分多个
,【现象】
,【解决】
,基于一套合理可行的协作规范，前后端从开发到上线的各个阶段都能够看到诸多成效：
,一言以蔽之：如果你发现前端在处理大量的逻辑，那么就是协作规范存在问题啦！前端更多的是关注交互、渲染上的逻辑，应尽量避免复杂的业务逻辑处理。万事开头难！推一套规范是需要时间去沉淀的，前端和后端同学都应多些耐心，多些理解。