联调 我不怕!

2019-06-11    来源:良无限-UED

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

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

大多数人认为,只有前端和后台套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. 表单元素是否触发校验
    • 普通校验:必填、长度、正则
    • 联合
    • 异步
  2. 校验问题的不确定,会导致demo功能的缺失,会影响并增加开发自测或测试阶段的联调成本,异步校验的缺失可能在开发调试阶段就会被发现,并找前端补充该功能。

  3. 页面链接的打开方式
    • 内部刷新url
    • 浏览器新开页面
  4. 链接虽然是个小问题,但是大多数交互和前端都是不会注意的,一般都要等到开发调试阶段甚至测试阶段才会发现,所以举手之劳,就回免去后面零零碎碎的联调成本。

  5. 页面间操作(以下操作可组合出现)
    • 新打开tab
    • 关闭当前页面
    • 切换到原页面并刷新
  6. 这个问题几乎所有交互都会忽略,但是会在功能预演或测试时提出,有些较明显的也要开发调试阶段才会被发现,所以非常有必要在交互评审时就明确该事项,减少联调成本

  7. 打开对话框
    • 对话框初始化前(页面初始化时)
      • 对对话框里面的控件进行初始化:表格、日历、联动选择等组件
    • 对话框初始化动作
      • 对不能在之前初始化的控件进行初始化:kissyEditor
      • 判断对话框是否已经存在,存在的话不必再次初始化
    • 对话框打开时动作
      • 删除错误提示
      • 清空数据
      • 回显数据
      • 更新内容
    • 确认后的动作
      • 异步提交表单
        • 提交前的校验
        • 增加提交数据
        • 提交后的回调
      • 更新数据
    • 对话框关闭时动作
      • 关闭对话框
    • 打开对话框动作,往往是交互同学比较喜欢的分支操作方式,但是交互稿往往很简单,只确定了在什么情况下打开对话框,对话框里有什么东西这些基本的东西。但是前端同学在制作是会涉及很多细节问题,这些问题的不确认或缺失会对联调造成很大改造成本,比如数据回显、情况等问题会在开发调试甚至测试阶段才会被发现和返工修改。

  8. 信息提示框
    • 简单提示框(只有确认按钮)
      • 确认后的回调
    • 确认提示框(有确定、取消按钮)
      • 确认后的回调
    • 确认后肯定会有回调,但是回调什么东西,是很容易忽略的事情,交互、前端、开发的看法若不能统一的话,很容易在开发调试阶段引起意外成本。

  9. 异步操作(ajax请求)
    • 收集提交数据
    • 回调
      • 刷新表格
      • 刷新dom
      • 信息提示
  10. 收集要提交的数据,往往会在开发调试阶段带来很多零碎的意外成本,所以在交互评审或者制定前后端方案时最好确定下来,避免后期修改。

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

  11. 提交表单
    • 提交前校验
    • 提交方式
      • 异步提交
        • 收集提交数据
        • 回调
          • 刷新表格
          • 刷新dom
          • 信息提示
      • 同步刷新至成功或失败页面
      • 确认后的动作
        • 关闭当前页
        • 打开新页面
        • 切换至源页面并刷新
    • 提交前的校验很容易被忽略,直到开发调试或自测是测会被发现,因为如果某些值不校验,提交到后台会报错,这个时候开发就回要你改动的,但是这些事宜往往在交互评审时就确认掉比较好。

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

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

 

标签: 前端 

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:抛开产品人员,如何做好研发驱动

下一篇:用户在做“倾向性选择”时考虑的一些东西