前后端联调总结

@Tomato

由于之前后端都有涉猎，
所以对于前后端在接口对接时产生的许许多多的摩擦有一些自己的看法
在此整理一些问题排查的思路

这里后端已WebApi举例 , 前端以VUE+ElementUI举例

1、为什么需要联调

联调就是

1. 后端不好好写单元测试与集成测试，让前端发请求调用以达到测试的目的；
2. 前端不好好写Mock和测试，让后端输出数据以达到测试的目的。

1. 联调是前后端一起见证靠谱的测试结果
2. 给需求方提供一个正确的需求验证环境
3. 尽早暴露前后端实现的问题

2、如何有效的联调

2.1、自测

eg:联调的时候小问题不断，大问题加班
问题：联调之前前端不知道后端返回过来的数据结构大概是什么样的，调用后端接口时小问题不断，数据不完整，流程走不下去，连一个能正常能走下去的测试数据都拿不出来

解决方案：自测自测自测，重要的事情说3遍，如果自测发现、解决问题耗时为1，那么联调发现、解决的问题绝对不是1+1那么简单。一定要有一个人知道数据的返回结构大概是什么样子，保证后端每个判断分支测试跑到位，哪些地方返回值没有是正确的，哪些地方没有返回值是不正常的

2.2、快速定位问题

eg:前端对于接口调用的反馈就是一句话，接口有问题！
问题： 遇到问题啥也不说来，404找不到接口路径？500内部服务器错误？还是提示传入参数格式不对？参数名称错误？完全不知道，问题难以定位，简单问题复杂化

解决方案：F12看一下，找不到接口，swagger页面找一下。返回错误提示截个图， swagger调用接口路径和参数发一下，后端自行排查

2.3、责任边界

eg:后端A想把判断放到前端B做，前端B想把数据格式放到后端A做
问题:A在忙，就想B来做。A反正也在改类似的，就想A把B的逻辑写在前端。A不愿意改，凭什么我改，就想B来改。A觉得B菜，拒绝沟通 --> 我不管反正我是好的

解决方案:判断尽量放到后端做，数据格式化都能做，这都是常规好分清的。难就难在两人职位一致，没有高地之分，老大只看结果不管谁去做。本身两人可能就是第一次配合不够默契，可能能力也差点互相嫌弃，性子又都比较急，工期紧张催的很急，没有人具体跟进，责任边界不明显谁也指挥不了谁。这个时候老大一定要出来划分责任边界，不仅仅是进度，还要到具体细节，甚至是具体到某一个参数，做前后端的润滑剂

2.4、及时反馈

eg:后端：接口都没问题，前端：页面都没问题 ，最终交付=加班
问题：后端：页面画的啥，数据怎么放？前端：数据给的啥？

解决方案：后端数据库里面一定要有测试数据，而不是已跑通不报错为目的。前端一定要根据当初约定好的数据格式要求后端，该要数组要数组，该要树结构要树结构。接口没有返回数据一定要反馈前端，不要以不报错为目的，数据感觉不对不要不管不问，甚至于去其他页面 “借” 一些莫无须有的值

3、真正的联调

1. 前端完成自测
2. 后端完成自测
3. 前、后端都明确知道需求方想要什么，一起验证需求的实现，有一定自己的看法

4、友情建议

4.1、远离关键路径，合理调配时间

按时完成任务，留足时间自测，别拖后腿

4.2、把握全局进度，提高整体效率

给了你项目的权利，就要肩负起项目的推动，别任由前后端扯皮浪费时间

4.3、积极沟通交流，主动推进联调

主动沟通，项目出了问题不是一个人的事情，是大家的事情，别甩锅，也许这次你的责任比较小，但是你的态度已经决定了很多人对你的态度