负责的项目发布了一段时间,在这期间,发现了不少逻辑流程上欠考虑的地方。这个项目当初开发的时间比较紧,相对来说也不是部门核心业务,因此流程相对来说不是很正规。基本就是产品经理将交互图丢过来,几个重要的点文字标下,然后口头沟通下需求,就开始开发了。在发布后,陆陆续续发现了一些当初考虑不严谨的地方,因此希望能在新版本进行改正。在我看来,成熟有序的开发流程,某种程度上也代表着更加具有逻辑性的思考方式。最近查了些资料,也和前辈们沟通了下,现在来浅谈下心得。
明确需求
一个功能,如果能明确其输入是什么、输出是什么、在什么情况下期望发生的行为是什么,那么开发起来会清晰许多。产品经理给出的需求,并不一定就细致到足以支持开发。比如我在开发wifi相关的功能,产品经理可能只会说要一个wifi列表,点击列表中的wifi会开始连接,然后顶部展示wifi连接状态。那么如果wifi开关关闭了的表现应该是什么?wifi连接失败的表现是什么?可能这些细节都没有明确。如果在没有明确的情况下去进行开发,可能就是想到哪里写到哪里,想到哪个细节就处理哪个细节,对整体架构没有掌控,导致代码凌乱难以维护。更糟糕的是干脆遗漏细节,缺少对部分情况的处理,直接影响用户体验。我不太清楚是否这些是产品经理负责,但不管怎样,如果线上出了问题,作为开发肯定脱不了干系,所以还是自己要把握好。如果发现不明确的问题,可以再和产品讨论,把问题抛出来让他们去想解决方案,但不可以不考虑这些细节问题。
那么怎么细化需求呢?据说开发是要需求文档的,但我这个项目仅有简单的交互图。去查需求文档写法,发现也没有统一的标准,只要明确功能的形态即可。而咨询一些开发前辈,他们提议简单使用excel表格,将功能细分剥离,写明每个功能的行为,并且多想一些使用场景的case,明确在这些场景下功能的行为。因此我使用这个思路来细化我这个项目的需求。
细分功能
模块
划分功能的第一步是划分模块,而不是直接划分成最小的原子feature。这个一是分类清晰,二是为了之后考虑场景用例方便。事实上实践发现,很多用例是可以以模块为单位来考量的,可以在不遗漏case的情况下,尽量减少需要说明的内容。还是拿wifi列表的功能举例,页面上部是展示wifi状态的状态栏,下部是wifi列表,状态栏还有断开wifi等按钮,就是那种最普通的wifi连接界面。那么很明显的,上部状态栏和下部wifi列表可以分成两个模块,因为做的是完全不同的事。如果需要还可以继续划分子模块。依据就是场景、行为有一定的一致性的一些功能。feature
模块划分到最后,一些无法或无需再划分的功能,作为一个个feature存在。到了feature这步,就需要明确此功能非常具体的一些行为了。比如wifi连接栏中会展示当前wifi的ssid,这个功能可以明确为“展示当前处理的wifi的ssid,不可为空,不带有双引号,不可有<unknown ssid>、0x等非法ssid”。这样细化后,就很明确每个功能点究竟要做些什么了。举例
对于上述wifi列表的页面,细化后可能的样子如下:
使用场景
在每个功能定义清楚后,还需要考虑使用场景才能使得功能及逻辑严谨。这里的使用场景,其实类似于测试用例,但不需要那么详细。也就是考虑用户可能有哪些操作,进行这些操作后,期望我们的feature对其的响应是什么。只有全面考虑了使用场景,才不会致使在开发过程中遗漏某些情况,导致成为用户眼中的bug。举例如下:
这里,我直接在上述细分功能的表格后,直接写case,这样feature和case联系较紧密,比较直观。同时这样可以灵活地区分针对整个模块的case和需要区分feature的case。这边的使用场景的罗列基本就靠干想,当然也可以参考黑盒测试的一些方法,不过不用像写测试用例那样一步一步写的那么细,基本场景表达清楚即可。
了解相关技术
这一步和上一步,私以为其实很难分先后。如果没有明确的需求,怎么知道要去了解什么技术?但如果有些技术点不清楚,功能行为也很难定义。比如之前举例的,定义ssid的展示,包括“不带有双引号、不可有<unknown ssid>、0x”,如果不是在开发中发现系统提供的广播信息中会包含这些内容,行为定义也不可能说的这么明确。另一个例子,测试反馈表明,在部分机型上,必须要开启GPS才能获得wifi列表。对于这个情况,在大规模机型测试前也是不知道的,自然也没法明确对这种情况的处理。所以现实中,可能难免还要摸着石头过河。
但从理论上说,还是需要充分了解相关技术。所谓充分了解,并不是需求里说要有“连接wifi”功能,就去google下,然后复制搜出的代码,虽然对于新人以及在时间紧的情况下,可能很多人都是这么做的。这么做永远只是在使用二手货,搜出来的代码可能已经过时,或者并非最优。如果有时间,还是需要去看一手资料。像android开发,最主要的可能就是api文档。比如要确定网络是否真正可连,如果直接google搜索,那么搜出来的基本是使用ping的方法,但如果仔细阅读文档,会发现在6.0以后,是直接有api支持这个判断的。如果项目仅支持6.0以上,那么就可以直接调用api,写出即可靠又优雅的代码了(详见之前博文)。
相反,如果只是根据需求搜索技术,获得的可能是过时而片面的代码。因此感觉如果有时间,相关技术的一手资料要好好了解下。
其他重要步骤
今天先详细讲两方面比较有体会的部分的心得。以下是一些目前认为比较重要的,但还没实际操作的步骤。等之后涉及到了再细讲。
- 流程图
- 设计模式
- 提高效率的技术与库
- 单测
- 线上测试用例补充