liang14658fox前后端协作规范
前言
一文带你了解团队内部沉淀并践行已久的前后端协作规范，
读完本文，回去大胆拒绝你后端的不合理设计！
为什么需要协作规范？
随着前后端分离开发模式大行其道，前端和后端已经在两个方向上渐行渐远，各自深耕细作、术业专攻。前端更加关注交互视觉体验，而后端对高并发、高性能、高扩展上要求更高。这就导致大部分的前端和后端之间会存在所谓的"代沟"，我不知道你的数据如何存储，你不知道我的页面如何渲染。
因此，很有必要制定前后端开发上的规范来抹平代沟，有了协作规范，便有了前后端开发默契，也因此达到了提高开发效率、降低沟通成本的作用。
基于一套合理可行的协作规范，前后端从开发到上线的各个阶段都能够看到诸多成效：
- 降低沟通成本，减少不必要的扯皮，加快开发进度；
- 缩短联调时间，减少联调阶段的代码调整，保证了开发效率；
- 减少测试阶段的排查问题归属，加快测试进度，保证质量；
- 方便线上问题排查及修复。
常见的垃圾设计与解决方案
如果你发现前端在处理大量的逻辑，那么就是协作规范存在问题啦！前端更多的是关注交互、渲染上的逻辑，应尽量避免复杂的业务逻辑处理。
1. 后端一个接口拆分多个
- 存在现象：
一个状态显示需要多次反复调用多个后端接口进行条件逻辑判断，需要异步调用接口并同步等待返回值，根据返回值去调用其他接口进行判断
第一次需要前端传给后端
参数组，然后调用接口返回第二个参数组，再根据返回的第二个参数组调用第三个接口返回第三个参数组...，最后根据第N个参数组在前端进行条件判断。明明一个接口只传一次参数返回状态可以解决的事，为何要调用多次接口？前端要确保稳定性，具体的业务逻辑要放到后端去做。
- 解决方案：
只调用一次接口，传给后端需要的字段，中间产生的参数以及接口调用全部经过后端封装整理之后，返回判断好的状态。
2. 接口细节口口相传
- 存在现象：
后端接口设计完毕后，提供给前端的接口文档存在缺陷，或者存在新设计的接口。往往在微信或者口头告知接口的变化与细节，导致后续阅读代码&文档困难度增加，维护与开发成本增加
微信只是聊天工具，可以传递文档，不能作为证据
- 解决方案：
3. 二次加工数据过多
存在现象： 前端页面开发完毕，后端设计接口时不根据前端字段作为参考，导致前端接收和提交参数时给参数必须重新赋值新命名，导致前端需要重新二次开发，效率低下。
解决方案：
4. 同一业务领域同一含义的接口字段命名不统一
存在现象： 前端同一个中文字段，提交时使用不同的首字母拼写作为参数，导致混淆与不稳定性。
解决方案： 每个中文字字段对应的首字母拼写统一，若有不同业务需求，后端接收到之后再做更名处理。 前后端共同维护一份字段词典，保持同一业务领域下命名一致，避免不必要的字段转换。
5. 任务分工明确
- 存在现象： 数据处理、导出等操作要求在前端完成，由于导出需要前端引用库、数据处理需要消耗客户端系统资源，进而导致系统反应慢，造成卡顿现象。
前端作为页面展示使用，不需要过多了解业务逻辑，后端接口文档中应该说明调用接口的情况即可
- 解决方案： 消耗资源的行为放到后端去做，比如选中导出、数据处理。
6. 确保接口可以使用
存在现象： 后端接口未经测试就提供给前端使用，前端开发时，调用现测现改，导致流程走通效率低下，后期出错率高。
解决方案： 使用ApiFox，可以直接测试接口可行性。
7. 参数在传递时被自动转义
存在现象： 特殊字符传递时参数发生转义，比如post请求中，参数中包含的
@被转义为%40。解决方案： 后端使用转义工具。
协作（联调）流程规范
- 需求分析。确保大家对需求有一致的认知
- 设计接口文档。前端需要确认是否符合要求
- 并行开发。前端需要根据接口文档进行Mock, 模拟对接后端接口；联调之前，要求后端做好接口测试
- 真实环境联调。前端将接口请求代理到后端服务，进行真实环境联调。
如何制定接口规范？
接口文档要求： 1.