联调 我不怕！(一)



（适用范围：涉及前后端共同产出的项目。文章有些长，但若认真阅读，应该会有所收获。）

大多数人认为，只有前端和后台套vm的过程才算联调，但是很多项目做下来的感受是：这个阶段其实不会花费多少成本，大概占到10%，但是真正的痛苦一直会持续到项目发布。

从交付到上线，需要"联调"的阶段大概有：

1. 套vm

2. 后台调试

3. 开发自测

4. 测试

可以说贯穿在demo交付之后的整个流程中。期间有来自各方面的修改、调整，这些带来了大部分联调的工作量。

比如，交互功能不明确或demo逻辑错误等问题，会在后台调试过程中一一暴露，带来修改的工作量。Demo的细节功能（如校验）做的不到位，会在开发自测甚至测试阶段才会暴露，引起修改。各页面之间的跳转逻辑问题，也会在开发自测的时候暴露出来。表单回显问题的不重视，甚至在后台调试阶段给前端带来结果逻辑上的重构成本。

目录：

1、联调成本到底出在哪里

2、从交互评审做起

3、前端方案要从多方面进行评估

4、Demo制作要留心

5、联调阶段把控需求变更

6、全文大纲

一、联调成本到底出在哪里？

将我们所碰到的问题整理一下，统计出一般项目的联调成本。

1. 常规成本
   1. 指导开发套vm
   2. 有需要的情况下，根据真实字段修改demo和数据
2. 意外成本
   1. From liD
      1. 需求修改
      2. 需求增加
   2. From 交互
      1. 页面交互漏洞，开发阶段发现其不能满足需求
      2. 交互人员变更导致交互方式变更
      3. 交互优化之前方案导致的变更
   3. Form 前端
      1. 前端bug
      2. Demo功能缺失
      3. 前端逻辑漏洞
      4. 前台数据解析问题
   4. From 开发
      1. 后台数据问题
      2. 前后台约定有变化
      3. 技术方案变动
         1. 必要性变更 最初的分析有问题 否则实现不了
         2. 之前的方案后台难度大，部分工作让前端分担
         3. 本身需求有变动
         4. 交互方案有问题 不足以满足需求

所以，联调成本不能光靠"让前端书写vm"这样的简单方式处理，应该从项目的各个阶段入手，增强对需求和交互稿的理解与把关，从而降低后期联调的成本。

二、 从交互评审做起

前端必须重视交互评审，一个经验丰富的前端开发，会在这个环节上对交互稿详细审查和质疑，并提出改进意见。做好这些工作，可以弱化后期联调中修正工作，降低联调时间成本和风险。

那么从那些维度来做交互评审呢？以下这些不仅可以作为前端的参考，还可以让交互同学借鉴，把交互稿细化，做的更加专业。

1、对页面上每一个可以点击的元素，做交互记录

1. 表单元素是否触发校验
   • 普通校验：必填、长度、正则
   • 联合
   • 异步

   校验问题的不确定，会导致demo功能的缺失，会影响并增加开发自测或测试阶段的联调成本，异步校验的缺失可能在开发调试阶段就会被发现，并找前端补充该功能。

2. 页面链接的打开方式
   • 内部刷新url
   • 浏览器新开页面

   链接虽然是个小问题，但是大多数交互和前端都是不会注意的，一般都要等到开发调试阶段甚至测试阶段才会发现，所以举手之劳，就回免去后面零零碎碎的联调成本。

3. 页面间操作（以下操作可组合出现）
   • 新打开tab
   • 关闭当前页面
   • 切换到原页面并刷新

   这个问题几乎所有交互都会忽略，但是会在功能预演或测试时提出，有些较明显的也要开发调试阶段才会被发现，所以非常有必要在交互评审时就明确该事项，减少联调成本

4. 打开对话框
   • 对话框初始化前（页面初始化时）
     • 对对话框里面的控件进行初始化：表格、日历、联动选择等组件
   • 对话框初始化动作
     • 对不能在之前初始化的控件进行初始化：kissyEditor
     • 判断对话框是否已经存在，存在的话不必再次初始化
   • 对话框打开时动作
     • 删除错误提示
     • 清空数据
     • 回显数据
     • 更新内容
   • 确认后的动作
     • 异步提交表单
       • 提交前的校验
       • 增加提交数据
       • 提交后的回调
     • 更新数据
   • 对话框关闭时动作
     • 关闭对话框

     打开对话框动作，往往是交互同学比较喜欢的分支操作方式，但是交互稿往往很简单，只确定了在什么情况下打开对话框，对话框里有什么东西这些基本的东西。但是前端同学在制作是会涉及很多细节问题，这些问题的不确认或缺失会对联调造成很大改造成本，比如数据回显、情况等问题会在开发调试甚至测试阶段才会被发现和返工修改。

5. 信息提示框
   • 简单提示框（只有确认按钮）
     • 确认后的回调
   • 确认提示框（有确定、取消按钮）
     • 确认后的回调

     确认后肯定会有回调，但是回调什么东西，是很容易忽略的事情，交互、前端、开发的看法若不能统一的话，很容易在开发调试阶段引起意外成本。

6. 异步操作（ajax请求）
   • 收集提交数据
   • 回调
     • 刷新表格
     • 刷新dom
     • 信息提示

   收集要提交的数据，往往会在开发调试阶段带来很多零碎的意外成本，所以在交互评审或者制定前后端方案时最好确定下来，避免后期修改。

   Ajax的回调都要做一些什么事情，也是交互同学最容易忽略的事情，往往解释的很简单，这里提供了一些维度，希望前端同学与交互同学确认。

7. 提交表单
   • 提交前校验
   • 提交方式
     • 异步提交
       • 收集提交数据
       • 回调
         • 刷新表格
         • 刷新dom
         • 信息提示
     • 同步刷新至成功或失败页面
     • 确认后的动作
       • 关闭当前页
       • 打开新页面
       • 切换至源页面并刷新

     提交前的校验很容易被忽略，直到开发调试或自测是测会被发现，因为如果某些值不校验，提交到后台会报错，这个时候开发就回要你改动的，但是这些事宜往往在交互评审时就确认掉比较好。

     同步提交到状态页面后的确认操作也容易被忽略，这个问题可能会隐藏到测试阶段，也是比较有风险的，但是这些问题在交互评审时都是很容易确认的。

8. 其他逻辑处理
   • 要写出详细的处理步骤
   • 其他交互逻辑有必要详细列出交互步骤
   • 
     

2、对系统页面之间的跳转逻辑做详细记录

• 1. 访问来源
  2. 主页面间
  3. 主页面与状态页面间

  这个问题很容易被忽略，交互只在乎主页面的交互，但是不重视页面间的跳转逻辑，当逻辑比较复杂时，问题就会比较突出，甚至在测试阶段才会发现主要问题。以下的例子比较典型，页面间的逻辑由于入口不同而稍有不同

  一个例子，聚划算项目：

  3、交互逻辑评估

  1. 流程是否可以走通
  2. 异常流程是否都可以覆盖
  3. 处理方式是否通用
  4. 方案细节是否清晰
     • 流程中每次点击的去向
     • 流程中每次点击触发的逻辑

  我们发现，交互同学由于时间较紧或需求变动频繁，有时候参加评审的交互稿所体现的流程会不准确，流程走不通或已成流程不能覆盖，这种情况下若直接开发前端逻辑的话，势必会出现漏洞，导致联调的时候需要修正，增加必然出现的意外成本。

  其中一个例子是：商品项目的商品信息填写页面的sku配置功能

  这个功能较复杂，修改表单内容会联动修改下面表格里面的数据。做之前，交互同学也只是这样简单的描述功能的。然而进入联调阶段后，发现直接联动修改会把用户手动在表格里填写的东西重置掉，而且有些有保护的数据是不能修改的，这样就导致在开发自测阶段的前端逻辑修改。但是回头想一想，这个问题如果交互同学多思考一下，可能就会发现并提前解决。

  还有一个例子：选品项目选品查询页面

  这个页面的初选通过和终选通过都需要确定一下买手是谁，但是在批量通过的操作上考虑的不全面，选择的买手可能会覆盖正确的数据，若不做数据覆盖，只是将没有买手的设置买手，就会产生选择的结果与实际产生的结果不一致的疑惑，所以到底应不应该支持批量操作，需要仔细考量，并制定出详细的交互方案。

  4、交互成本评估

  1. 交互方案是否利于技术方案的重复使用
  2. 交互流程是否可以复用
  3. 能否优先用现有组件实现
  4. 交互实现成本与交互效果的比例是否合理
  5. 交互是否可以简化
     • 尽量减少ajax
     • 尽量减少用弹出框处理主要业务流程

  交互方案的成本问题，前端需要重视，现在交互同学对成本往往评估不足，所以需要我们把关。主要的交互流程一定要保证新开页面，这样利于流程的重用。

  一个例子是：商品重构项目的商品查询页面。

  由于重构后的商品信息可以不用填的很全，这样导致一些基于商品的操作需要做 商品信息是否全面性的校验（比如申请认证等一系列商品操作）。这个需求从交互的角度，为了提高用户体验，交互主张把这个校验做在入口页面上（比如查询页 面），即点击后检测商品信息全面性，若信息不全则弹出对话框提示。但是这个交互方案非常不利于技术方案的重用，因为这个检测对于商品操作来说是必须的，属 于主流程，所以最佳的方案是把这个检测放在具体的商品操作页面上（比如申请认证的页面），只有商品信息符合要求，才会进行操作，否则跳转到错误页面。这样 任何页面只要有这个操作，不用复制检测商品信息的代码，可以重用检测逻辑。

  总结：交互评审是降低联调成本的第一关，相信从以上维度出发，把握好这20%问题，能够降低80%的联调成本。