今天我们来介绍一下 Android 项目流程的相关知识,在本篇文章里面我们将从需求的产生到交互的实现,再到视觉的输出到最后我们开发并完成上线,描述一下一个典型的产品开发流程是什么样子的,项目流程一般分为这几个阶段:
在整个流程里面,除了编码属于开发的基本工作以外,工程师还有需要参与流程的其他里面去。第一个就是产品需求产生的需求评审,让开发参与需求讨论了解需求,并提出一些意见、解决一些问题;同时也可以进行一定的脑报帮助完善需求;同时评估实现复杂难易程度和性价比。在这之后,有一个交互评审,开发对官方交互的设计了解是必不可少的。在这个阶段的评审可以提出自己的意见和官方的指导意见,同时呢,可以评估一下实现的难易复杂程度和性价比。视觉阶段,主要是对于技术是否能够实现的考虑,有些视觉设计可能过于理想化,需要及时更正。之后到我们开发的重点,交互和视觉评审,有一点是非常重要的,就是我们开发要从我们开发的角度去思考,从而及时发现交互和视觉没有发现的问题和细节,这样非常有利于我们后面的开发工作,减少反复的成本。开发完成之后我们要进行性能调优,这个我们会在后面具体讲到。
正常的开发流程都是并行的,开发不会等到的这个版本完全开发完成了,才开始开发下一个版本,下个版本的产品需求也不会在这个版本上线之后才开始设计。一般情况下,在上个版本还在测试发布前,下个版本的需求就已经开始输出了。在产品开发的后期开发往往有一些空闲时间,刚好可以用来做产品需求的评审和交互的评审。在这个图上面,我们可以看到在这个,测试的中后期,产品需求就已经开始输出,并完成评审,然后交互设计随之进行开展,交互设计完成时间点不是特别确定,一般要求尽快完成交互评审。这样在发布了三个版本之后开发就可以稍作休整,观察一下现场的反馈,就可以接着下个版本开发了。与此同时,视觉设计的整个过程也是和开发一样是并行的。在测试的中后期就会开始验收,验收非常重要,是验证每个环节是否达到了预期,不同小组的工作并行非常重要,这样才能极大的发挥团队的协作能力,提高工作效率。
在评估完交互和设计之后,我们会进行版本开发计划,并评估每个模块开发的具体需要时间,然后把具体开发工作分配到每一个开发人员身上。比如说我们有三个人并行开发,每个模块的开发时间和人员安排都被评估出来,视觉会根据我们的开发计划分批输出视觉。比如说在这个这个时间点会输出模块1、2、3,我在这个时间点会输出4、5、6,然后在这个时间点会输出7、8。这边特别要去注意的是,最后一批视觉输出,一定要把控好时间要保证留足够的时间给开发进行资源的替换,这样才能保证在体测时间可以完成开发工作。要保证留足够的时间给开发进行资源的替换,这样才能保证在体测时间可以完成开发工作。所以其实在某些阶段,开发工作是没有视觉资源的,所以要先完成逻辑和功能开发,这个过程应该是完整的,包括各种分辨率的适配,唯一留下来工作就是替换美术资源。
那同样开发和后台的配合也是非常重要的,它跟视觉的配合有点类似,因为后台的接口也是分批给出来,所以在一定阶段我们开发是没有结口的,这就需要我们根据实际来 Mock 些数据。同样,最后一批计划输出时间也一定要确定好,保证剩余足够的时间来跟后台进行接口的联调。
接下来我们重点来看看开发的基本流程:
我们拿到需求之后,首先要对需求进行分析,具体要做什么工作是为了解决什么问题?然后我们对功能进行划分,哪些部分是关联的,大概分成哪些模块。同时能对这些情况进行技术思考,可能用到什么技术方案去实现难点,大概技术点是什么样子的。需求分析之后我们就进入模块设计,首先我们要对技术方案进行对比,选择一个适合自己的方案,方案不是越复杂越好,要能解决需求的同时又有一定的扩展能力。那接下来就是结构框架设计,搭建好结构框架,包括定义好接口,通信模型流程结构等等,然后进行详细设计,比如详细的协议、涉及数据算法的选择。必要时,我们会输出设计文档以便后面的维护。接下来我们就进入编码阶段,我们把设计转换成代码,实现完整的逻辑流程功能,但实际上我们花在编码上时间并不多,可能会占了20%,大部分时间我们都在调试,通过不断调试来解决各种Bug,最后还要进行必要的优化和重构,来完善我们的代码。现在调优在开发过程后期占很大的比重,偶尔通过排查可以发现一些潜在的问题,比如内存泄露,CPU 占比过高,滚动掉帧等等。通过一些工作进行调优,不可缺少。最后是自测,自测是必须的,这是属于每个开发者的责任。自测很重要,只有通过自测代码才可以提交给后面专门的测试人员来测试,没有通过自测的代码,甚至都不允许提交到代码仓库,如果提交了这被认为是一种不负责任的表现,自测有很多种,常见的有冒烟测试、功能测试、边界测试、回归测试等。
一般情况,每个模块开发完成之后,开发就需要对这个模块进行测试,所以基本的流程是,开发一个模块测试一个模块。这部分自测时间是包括在我们的开发时间里面的,刚才提到没有通过自测的开发代码,是不能提交到代码仓库的,通过开发自测后,其实是可以直接作为上线标准的。开发不应该依赖于后面还有专门的测试人员来保障我们的产品质量。
<p>接下来我们介绍几个时间节点。第一个是需求截止时间,我们最讨厌的就是需求不断的变更或者新增,最正规的项目开发流程里面应该规定有需求截止时间,但因为计划赶不上变化,所以同时应该也有需求变更和新增的流程,为了保证项目质量,绝对不允许临近上线还在改变需求。</p>
只有开发跟交互一起去了解各种细节,后面的开发才能顺畅起来,否则后面遇到交互、视觉有问题就会影响我们的开发效率。同样,视觉得分配输出节点和后台的接口分配输出节点,在前面已经讲过了。
只有及时沟通好了,才能跟视觉和后台配合得好,我们才能在约定的提测时间点提测。当然重要的是知道我们一个版本的发布计划,上个流程晚了就会影响测试时间,从而影响发布时间。
<p>在发布里面有一种发布叫做灰度发布,就是只有少量用户可以更新到我们的最新版本,这样的话,那我们可以通过这种方式来暴露出一些问题,然后可以进行一轮修正之后再全量发布,可以减少受影响的用户。灰度发布有很多办法,比如说我们通过尾号推送版本更新等等,那根据一般的经验来讲在有一定规模用户基础上,一般20%用户升级到最新版本,大概需要3到5天就可以完成暴露出这个版本的问题。</p>