项目实战中的开发、集成、测试、交互总结

Posted by liveipool on August 4, 2017

项目实战中的开发、集成、测试、交互总结

最近项目发布了preview版本,我也是参与了一个半完整的sprint(sprint3+release sprint),最近处于RRI阶段,即老师专门给出一定的时间来让我们总结前面学到的内容、踩过的坑,我们也确实应该好好利用。 在这个阶段,我负责了产品中组件的开发、页面的集成、测试等等,也觉得有一些可以记录的点,记录如下:

开发

在前面一边写组件的过程中,一边也在博客上总结一些东西,重复的内容不再在这篇博客中记录,附上上一篇的链接:组件化编程及API设计

考虑同一页面上多次使用某组件时是否会冲突

在做组件的时候,直到发布也忽略了这个问题,导致后来重新修改部分代码,在以后开发组件的过程中要注意一下。
其实按理来说,组件开发是不用考虑这个问题的,因为组件都是有自己的作用域的(css加了scoped时),但在这个项目中我们用到了jquery,它的一些选择器在同一页面上使用多个组件时就会相互干扰到。因此在写组件时,要使用一些能够唯一标识该组件的变量、名称等,特别是在这种会全局干扰的选择器等。

函数提取,减小耦合性

这个是需要在编码学习中不断积累的,每次都要提醒自己注意这个,通过函数或重复代码的提取来精简代码和减小耦合性。并且其实,有些时候进行函数的提取不一定能够减少代码量,比如在这次组件的开发中,有些函数可能只有一到两排,但是提取成函数能够让逻辑更加清晰,因为我们可以通过注释和函数名来让使我们对这个函数的作用理解地更加清晰,再以后写代码时会减少很多思考时间,这也是非常重要的,并且降低了耦合性,使以后代码扩展时能够更加容易。

默认值设置

在开始开发组件时,有一个问题漏掉了,即对某个属性进行默认值的设置的时候,如果这个属性是一个对象,那么要注意其中的默认值是什么时候赋上去的,因此这里会有两种情况,一是对象为undefined时的情况,二是对象不为undefined,而其中的属性为undefine的情况,需要区分开来写:

      a: {
        type: Object,
        // 以下默认函数仅当a对象为undefined时会执行
        default: function () {
          return {
            num: 3,
          }
        },
        required: false
      },
    computed: {
      // 用于保存父组件传进来的a对象并对其属性赋上默认值
      // 下面的默认值是当a对象不为undefined但属性为undefined的时候执行的
      b () {
        return Object.assign({}, this.a, {
          num: this.getDefaultValue(3, this.a.num),
        })
      },
    },

集成

在这个阶段中,我主要的任务是将各个页面从各个分支集成到集成分支,并整体把控,控制整个集成项目的功能和代码上都是合理的,主要的问题是解决各个分支合并时的冲突,下面也记录了一下关于package.json文件的冲突及解决:关于package.json中的依赖的版本问题(商汤内网才能访问) ,另外主要就是一些因为合并而导致的各个页面相互影响的情况,这一方面问题主要是要多方面讨论确认,尽量不要自行进行更改,因为各个页面由不同的程序员开发,只有他们自己写的代码才能够确认是不是正确的、是不是最新的进度,在这一方面一定要注意,多沟通交流,确认后再进行冲突的解决。

测试

因为负责了集成工作,所以也负责了主要的组内测试的工作,虽然不如专业测试那么严密,主要也是在做黑盒测试,但感觉还是有一些地方可以记录一下:

首先当作用户盲测

比如有一个地方,是右键点击之后出现弹框,如果我在进入这个页面前看了需求文档,我很可能就会有倾向性地去右键点击测试功能,但我当时是完全没看需求开始使用页面,用左键对菜单栏点了半天,过了很久经过别人提醒才知道右键点击也有功能。毕竟在web应用中,左键 》双击 》 右键,因此如果有右键点击的功能,一定要加个title属性之类的提示。

尝试各种排列组合

这里的排列组合不是说表格那种排列,而是说当页面上有几个不同的操作时,单独看某个操作应该都没问题,但将它们的功能合起来使用之后可能会出现意想不到的问题,因此各个可能性都要包括到,最好是列出有哪些操作或不同的点,每种排列组合的情况都试一下,这样才能做到全面的功能测试。

自己更改一些可能会导致问题的数据来验证

image.png
比如这样一列表格,放开了看当然没有问题,但放到实际的环境当中,就可能有多种情况了:1.某个字段太长时,会不会影响布局。2.某个字段为空时,怎样显示。3.所有数据都为空时,怎样显示。4.当数据达到临界点或者超过临界点时,是否能够正确工作等等问题,这些问题可以通过自己更改一些测试用例来发现。

在前端要对数据进行处理显示时,一定要注意特殊情况

在以前的公司做项目开发页面时,我做的其中一个页面上有很多的数据,我要根据原型将不同的数据做出不同的处理,并呈现到页面上。而数据虽然在api文档中看着都很乐观,但在实际的环境中,问题一大堆:1.该字段为undefined。2.该字段和api文档上的格式不同。3.该字段为一个对象或数组,而它们为空对象或空数组。4.某对象里面的某个属性又为undefined….各种各样的问题都要考虑到。
image.png
比如这里有个检索时间,前端是根据后端传回的时间字段进行处理后显示到页面上,在正常情况下,确实没什么问题,但如果代码没写好,后端数据格式不完全正确的时候,可能就会显示一些undefined或invalid date字段在页面上,这就非常不友好。
虽然这可能确实不是前端的锅,是后端数据出了问题,但我觉得,在整个web应用的实现结构上,前端是最靠近用户的一环了,所以就算是后端数据出了问题,前端也应该进行合理地控制,保证呈现给用户的信息始终是合理的。

交互

在做项目以及和更成熟的产品经理或架构师讨论的过程中,会慢慢积累一些交互、设计上的经验,这是一个漫长的过程,需要不断总结记录。

“一定要想清楚,是什么人,在什么场景下,用我们的产品干什么”

炫酷vs实用

在开始展示产品时,有一个地方使用了很华丽的动画,我一看就开始觉得这个动画好看,开始想怎么实现,但产品经理突然指出,这个动画在展示时虽然看起来很厉害,但用户在使用这里的时候,操作次数多了难免会被动画干扰到,产生审美疲劳,这个确实说得很对,在华丽和实用中间,一定要找到一个平衡点,打破了平衡,容易使用户感到不适。

在用户的真实环境思考问题

这个题目其实可以概括很多问题,举一个很简单的例子,因为我一直是在mac上开发的,习惯了“确定”按钮在右,“取消”按钮在左,在做产品的时候我会觉得我的习惯更合理,想要把设计图上和我习惯相反的按钮问问设计师改一下,而实际上,我们产品的用户绝大多数都是使用的windows系统,一般是“确定”在左,“取消”在右。因此,还是要站在用户的真实环境思考问题,不要以自己的习惯为原则。

三色原则

某一部分内容尽量不要超过三种颜色,这个原则感觉在各个地方都比较适用,超过三色会显得杂乱。

每个字段都要思考一下它存在的意义

有些字段粗看起来并没有什么问题,但实际上深入去想之后就会意识到有问题,比如在新建用户弹框中有一个设置密码字段,一眼看过就会觉得新建用户嘛,肯定需要密码嘛,进行设置也没错。但是,要想清楚是谁在使用这种弹框,一般来说可以新建用户的是管理员,而管理员其实并不需要为用户设置密码,只需要给定一个初始密码就好,所以这个字段其实并没有存在在这里的意义。

增大交互区域,使用户操作更容易

某些按钮图标,本身较小,可以设置更大的交互区域,来提升用户体验。

若还有漏掉的忘记记录的内容,想到后继续补充…

赞赏码.jpeg