联调 我不怕！
2019-05-07 来源：良无限-UED
（适用范围：涉及前后端共同产出的项目。文章有些长，但若认真阅读，应该会有所收获。）
大多数人认为，只有前端和后台套vm的过程才算联调，但是很多项目做下来的感受是：这个阶段其实不会花费多少成本，大概占到10%，但是真正的痛苦一直会持续到项目发布。
从交付到上线，需要"联调"的阶段大概有：
1. 套vm
2. 后台调试
3. 开发自测
4. 测试
可以说贯穿在demo交付之后的整个流程中。期间有来自各方面的修改、调整，这些带来了大部分联调的工作量。
比如，交互功能不明确或demo逻辑错误等问题，会在后台调试过程中一一暴露，带来修改的工作量。Demo的细节功能（如校验）做的不到位，会在开发自测甚至测试阶段才会暴露，引起修改。各页面之间的跳转逻辑问题，也会在开发自测的时候暴露出来。表单回显问题的不重视，甚至在后台调试阶段给前端带来结果逻辑上的重构成本。
目录：
1、联调成本到底出在哪里
2、从交互评审做起
3、前端方案要从多方面进行评估
4、Demo制作要留心
5、联调阶段把控需求变更
6、全文大纲
一、联调成本到底出在哪里？
将我们所碰到的问题整理一下，统计出一般项目的联调成本。
- 常规成本
- 指导开发套vm
- 有需要的情况下，根据真实字段修改demo和数据
- 意外成本
- From liD
- 需求修改
- 需求增加
- From 交互
- 页面交互漏洞，开发阶段发现其不能满足需求
- 交互人员变更导致交互方式变更
- 交互优化之前方案导致的变更
- Form 前端
- 前端bug
- Demo功能缺失
- 前端逻辑漏洞
- 前台数据解析问题
- From 开发
- 后台数据问题
- 前后台约定有变化
- 技术方案变动
- 必要性变更 最初的分析有问题 否则实现不了
- 之前的方案后台难度大，部分工作让前端分担
- 本身需求有变动
- 交互方案有问题 不足以满足需求
- From liD
所以，联调成本不能光靠"让前端书写vm"这样的简单方式处理，应该从项目的各个阶段入手，增强对需求和交互稿的理解与把关，从而降低后期联调的成本。
二、 从交互评审做起
前端必须重视交互评审，一个经验丰富的前端开发，会在这个环节上对交互稿详细审查和质疑，并提出改进意见。做好这些工作，可以弱化后期联调中修正工作，降低联调时间成本和风险。
那么从那些维度来做交互评审呢？以下这些不仅可以作为前端的参考，还可以让交互同学借鉴，把交互稿细化，做的更加专业。
1、对页面上每一个可以点击的元素，做交互记录
- 表单元素是否触发校验
- 普通校验：必填、长度、正则
- 联合
- 异步
- 页面链接的打开方式
- 内部刷新url
- 浏览器新开页面
- 页面间操作（以下操作可组合出现）
- 新打开tab
- 关闭当前页面
- 切换到原页面并刷新
- 打开对话框
- 对话框初始化前（页面初始化时）
- 对对话框里面的控件进行初始化：表格、日历、联动选择等组件
- 对话框初始化动作
- 对不能在之前初始化的控件进行初始化：kissyEditor
- 判断对话框是否已经存在，存在的话不必再次初始化
- 对话框打开时动作
- 删除错误提示
- 清空数据
- 回显数据
- 更新内容
- 确认后的动作
- 异步提交表单
- 提交前的校验
- 增加提交数据
- 提交后的回调
- 更新数据
- 异步提交表单
- 对话框关闭时动作
- 关闭对话框
打开对话框动作，往往是交互同学比较喜欢的分支操作方式，但是交互稿往往很简单，只确定了在什么情况下打开对话框，对话框里有什么东西这些基本的东西。但是前端同学在制作是会涉及很多细节问题，这些问题的不确认或缺失会对联调造成很大改造成本，比如数据回显、情况等问题会在开发调试甚至测试阶段才会被发现和返工修改。
- 对话框初始化前（页面初始化时）
- 信息提示框
- 简单提示框（只有确认按钮）
- 确认后的回调
- 确认提示框（有确定、取消按钮）
- 确认后的回调
确认后肯定会有回调，但是回调什么东西，是很容易忽略的事情，交互、前端、开发的看法若不能统一的话，很容易在开发调试阶段引起意外成本。
- 简单提示框（只有确认按钮）
- 异步操作（ajax请求）
- 收集提交数据
- 回调
- 刷新表格
- 刷新dom
- 信息提示
- 提交表单
- 提交前校验
- 提交方式
- 异步提交
- 收集提交数据
- 回调
- 刷新表格
- 刷新dom
- 信息提示
- 同步刷新至成功或失败页面
- 确认后的动作
- 关闭当前页
- 打开新页面
- 切换至源页面并刷新
- 异步提交
提交前的校验很容易被忽略，直到开发调试或自测是测会被发现，因为如果某些值不校验，提交到后台会报错，这个时候开发就回要你改动的，但是这些事宜往往在交互评审时就确认掉比较好。
同步提交到状态页面后的确认操作也容易被忽略，这个问题可能会隐藏到测试阶段，也是比较有风险的，但是这些问题在交互评审时都是很容易确认的。
- 其他逻辑处理
- 要写出详细的处理步骤
- 其他交互逻辑有必要详细列出交互步骤
校验问题的不确定，会导致demo功能的缺失，会影响并增加开发自测或测试阶段的联调成本，异步校验的缺失可能在开发调试阶段就会被发现，并找前端补充该功能。
链接虽然是个小问题，但是大多数交互和前端都是不会注意的，一般都要等到开发调试阶段甚至测试阶段才会发现，所以举手之劳，就回免去后面零零碎碎的联调成本。
这个问题几乎所有交互都会忽略，但是会在功能预演或测试时提出，有些较明显的也要开发调试阶段才会被发现，所以非常有必要在交互评审时就明确该事项，减少联调成本
收集要提交的数据，往往会在开发调试阶段带来很多零碎的意外成本，所以在交互评审或者制定前后端方案时最好确定下来，避免后期修改。
Ajax的回调都要做一些什么事情，也是交互同学最容易忽略的事情，往往解释的很简单，这里提供了一些维度，希望前端同学与交互同学确认。
版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。
上一篇:抛开产品人员，如何做好研发驱动
