1.前言你是否正在为如何制定前后端协同规范而发愁？干货来了，本文将带你了解我们团队长期积累和实践的前后端协作规范。看完这篇文章，回过头来大胆拒绝你不合理的后端设计！2.为什么需要协作规范？如果要在团队内部推行一套规范，那么首先要知道为什么要制定协作规范？有规范有什么好处？随着前后端分离开发模式的流行，前后端逐渐向两个方向渐行渐远，各自在技术上深耕细作。前端更注重交互的视觉体验，而后端对高并发、高性能、高扩展性的要求更高。这导致了大多数前端和后端之间所谓的“代沟”。我不知道你的数据是如何存储的，你也不知道我的页面是如何呈现的。因此，非常有必要制定前后端开发规范，弥合代沟。有了协作规范，前后端开发之间会有默契，可以提高开发效率，降低沟通成本。3.协作流程规范首先是协作流程规范。相信每个团队在前后端协同上都有自己的开发模式和开发流程，保证效率和质量。我们团队前后端协同的大致流程如下图所示：RequirementsImport，交互式可视化导入分析：关于产品导出的需求，会议各方，包括产品，前端、后端、测试、UED，必须在需求的认知上达成共识，这是开发的第一步。接口设计，前后端对接接口：后端提供接口，前后端必须就接口字段设计达成一致。技术方案评审：开发前对技术方案进行评审，确保各方对需求有统一的认识，双方重新确认接口字段的可行性。并行开发，前后端自测：前后端并行开发，此时前端可以mock数据进行页面渲染。开发环境联调：前后端自测完成后，在开发环境上完成接口联调。4、如何制定接口规范？前端协议：在后端接口定义URL和访问参数之前，前后端必须达成协议。文档规范：接口注解需要写清楚：模块、枚举、强制/非强制、输出参数是否可以为null。接口需要向后兼容。如果不兼容，需要评估，需要通知相应的业务方接口文档有变化。前后端及时同步需要保证文档上定义的参数可以正常请求，功能正常稳定比特协议：时间：统一使用13位时间戳数量：统一分成点数，接口URL&请求方式Post接口可根据业务情况选择不允许使用Get传参方式。Post接口必须使用application/json模式。接口命名应尽可能语义化。接口命名不要过于雷同，不易区分，容易混淆输入参数。保证同一个应用字段中相同含义的字段命名一致business序号/ID必须是字符串类型。JS对同一页面上不同标签的最大数量有限制。尽量保证接口一致。了解错误信息，非在线环境可以返回错误堆栈，方便排查前端数据列表相关接口。如果return为空，会返回一个空数组[]或者空集合{}，有利于在数据层面更加协作高效，减少前端很多琐碎的空值判断，专门分析接口输出参数在专门cases根据页面要求返回有效字段，避免吐出太多无用的字段枚举值，尽量返回中英文描述5.协作中的BadCases总结如下我们团队内部协作中遇到的典型BadCases和解决方案，我相信大家在开发过程中都遇到过类似的痛点：类型一：前端条件逻辑判断过多【现象】按钮、组件是否显示，前端需要通过大量的条件逻辑判断字段；同一页面不同场景前端调用的接口不同：//按钮文案，显示逻辑{((record.state==='RESULT_CONFIRM'&&isCurrentUserCreate)||(record.state==='RESULT_CHECK'&&isCurrentUserCreate&¤tUserCanCheck))&&}{['DREFT','AUDIT_FAILD','REVOKE'].includes(record.state)&&isCcurrentUserCreate&&}//A场景调用接口1，B场景调用接口2，C场景调用接口3and4if(id){this.operation='modify';constres=等待这个。获取信息（id）；...}elseif(source){constres=awaitthis.fetchSourceInfo(id:source);...}else{constres=awaitthis.fetchBasicInfo();...}【解决方案】控制前端显示逻辑判断全部放在后端处理，前端尽量减少字段判断。注意：如果功能简单，前端也可以做判断。如何鉴别是否简单？从代码层面来说，比如如果If判断条件超过2个，按钮显示超过2个条件，可以看成是复杂的逻辑，将逻辑移到后端处理。建议一开始就处理的比较复杂，这样后面就不需要调整了。//按钮显示前后端约定。按钮的显示返回一个数组，数组返回的具体逻辑写在后端。[{name:'Confirm',type:'resultConfirm'},{name:'Modify',type:'edit'},]【好处】逻辑收敛到后端，只有一方需要检查是一个问题或逻辑被更改或修改。也就是一端能完成的，千万不要让两端干涸，两者可能会有不一致的地方。类型二：前端二次数据处理过多【现象】页面同表展示的数据被两个界面拼接。接口数据返回格式不符合前端渲染逻辑，需要二次处理【解决方案】1、后端做好数据整合，避免前端数据重组。2、Tree数据展示场景，如果数据不大，后端全量返回，如果数据量太大，则异步返回，但异步返回对后续回显和搜索显示有问题。3、同一个业务功能可以用一个接口做，不分接口，后端业务考虑多路复用可以封装新的接口或者在原有接口上加参数兼容。【好处】降低前后端数据处理成本，提升性能和用户体验第三种：枚举值和下拉框数据由前端维护【现象】列表页文档状态由维护前端枚举值，如果需要新的枚举前后端变更可能导致最终显示状态不一致//状态值映射constgetStatusName=(status)=>{switch(status){case0:返回'草稿';情况一：返回'待部门批准'；case2:返回'Pendingfinancialreview';case3:返回'Pendingunitreview';case4:返回'Underreview';...默认值：中断；这种情况下，前端不需要维护状态值，以后端提供的接口为准。如果状态是固定的，比如：如果选项是[Yes,No]，后台就不需要返回。//下拉框选项由后端接口返回{result:[{code:stringname:string}]}【好处】当枚举值发生变化时，只需要更新后端，解决与迭代过程中也避免了前后端情况类型4：PC端的数据结构不适用于App端【现象】App端的布局样式比PC端稍微复杂一些。如果App端一味的使用PC端的接口数据，需要在前端进行特殊处理。比如收据的app端同时放在同一张卡片中，卡片内部的标题、内容、按钮显示也有所区别。【解决】判断前端处理工作量，后端需要增加接口来实现app的不同功能。【好处】减少前端处理逻辑开销，提升App用户体验类型五：同一业务领域中相同含义的接口字段命名不统一【现象】关于返回结果：response.data,response.result关于时间：createAt,queryEffectStartingBeginTime,penaltyBeginTime关于名称：punishedInstitutionName,responderName,penaltyObjectName关于Id：punishedOrganizationId,penaltyObjectId【解决】前后端共同维护一个字段字典，在同一个业务字段保持相同的命名，并避免不必要的字段转换。类型6：金额计算结果由前端提交给后端，存入数据库【现象】在前端页面，输入支付金额除以总金额，计算支付金额比例，最后点击保存按钮将数据提交到后台界面；【解决方法】】对于金额的计算：根据是否入库，非入库的纯展示可以由前端计算，入库的统一计算由后端计算。类型7：前端维护业务配置类型代码【现象】多个表单项（下拉框、输入框、单选框等）的值作为判断某个表单项的条件（附件、单选框、输入框等）是否需要、显示或隐藏。因此，前端需要编写大量的动态验证逻辑，而且每个部门涉及的动态验证逻辑都不一样，有些验证条件还是硬编码的。【解决】配置验证规则的页面可以根据分部配置生成一个识别码，然后后端可以提供一个通用的验证接口，前端会传值给后端，然后返回是否验证结果通过。//输入参数：{code:'99900',//部门代码identity:'11111',//标识码datas:[//数据{key:'catalog',value:'A07',},{key:'assetApproval',value:0,}]}//返回值:{result:true}类型8：前端直接调用其他业务线的后端接口【现象】在业务线A的列表页，点击新建按钮，弹出框调用业务B线侧的接口。由于A和B是不同业务线的后端，接口对接和后期沟通维护的成本会比较高。比如接口发生变化，需要跨业务线通知相应的前端（后端不一定知道是哪个前端）；并且接口返回的大量字段没有被前端使用。【解决方案】在后台业务耦合的情况下，需要在自身业务线后端进行数据整合；如果只是展示非自身业务的数据，后端不处理类型9：后端分页接口的数据返回格式不统一【现象】当前分页接口的数据返回格式为不统一，有如下几种形式：//形式一：{result:{data:[],total:0,}}//形式二：{result:{data:[],pagination:{total:0,pageSize:10,pageNo:1},}}//Form3:{result:{data:[],total:0,pageSize:10,pageNo:1}}【解决】建议后端接口统一格式为如Form3类型10：一个后端接口拆分多个【现象】一个表单页面在提交前调用了三个不同的验证接口。三个验证接口的输入参数也不一样，前端需要组装各种类型的数据。【解决】多个验证界面和提交界面合并为一个提交界面。验证失败时，接口的返回值分为阻塞型和提醒型。拦截型：弹窗告警，用户只能关闭弹窗提醒型式：弹窗查询，用户点击“继续提交”后，继续调用提交接口，此时添加入口标识并跳过此验证步骤。六。效果基于一套合理可行的协作规范。前后端从开发到上线的各个阶段都可以看到很多成果：减少沟通成本，减少不必要的扯皮，加快开发进度；缩短联调时间，减少联调阶段的代码调整，保证开发效率；减少测试阶段排查问题的归因，加快测试进度，保证质量；方便在线问题排查和修复。7.总结一句话：如果你发现前端在处理大量的逻辑，那就是协同规范有问题！前端更侧重于交互和渲染的逻辑，应该尽量避免复杂的业务逻辑处理。万事开头难！推出一套规范需要时间来解决。无论是前端还是后端的同学都要多一点耐心和理解。
