Android应用开发流程思考

负责的项目发布了一段时间,在这期间,发现了不少逻辑流程上欠考虑的地方。这个项目当初开发的时间比较紧,相对来说也不是部门核心业务,因此流程相对来说不是很正规。基本就是产品经理将交互图丢过来,几个重要的点文字标下,然后口头沟通下需求,就开始开发了。在发布后,陆陆续续发现了一些当初考虑不严谨的地方,因此希望能在新版本进行改正。在我看来,成熟有序的开发流程,某种程度上也代表着更加具有逻辑性的思考方式。最近查了些资料,也和前辈们沟通了下,现在来浅谈下心得。

明确需求


一个功能,如果能明确其输入是什么、输出是什么、在什么情况下期望发生的行为是什么,那么开发起来会清晰许多。产品经理给出的需求,并不一定就细致到足以支持开发。比如我在开发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,写出即可靠又优雅的代码了(详见之前博文)。

相反,如果只是根据需求搜索技术,获得的可能是过时而片面的代码。因此感觉如果有时间,相关技术的一手资料要好好了解下。

其他重要步骤


今天先详细讲两方面比较有体会的部分的心得。以下是一些目前认为比较重要的,但还没实际操作的步骤。等之后涉及到了再细讲。

  • 流程图
  • 设计模式
  • 提高效率的技术与库
  • 单测
  • 线上测试用例补充
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,098评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,213评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,960评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,519评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,512评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,533评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,914评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,574评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,804评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,563评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,644评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,350评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,933评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,908评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,146评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,847评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,361评论 2 342

推荐阅读更多精彩内容