你的浏览器还没开启 Javascript 功能!

产品研发流程概要

前期

市场调研

原型输出

产品经理制作完原型后,产品内部进行整理输出后通知各个开发以及设计人员,阅读原型后一天内需要把各自的疑问和重要的想法写道任务中,此阶段主要是让相关人员熟悉需求。

需求评审

产品经理作为会议主持人,负责讲解原型迭代详情,期间相关人员提出自己的疑问和想法,商榷之后记录在文档中。后续改完需求后,若有会议讨论外的改动需要再次通知所有相关人员。

中期

任务拆分

24小时内开发和设计人员把自己的任务拆分,一个任务不能超过4小时预估,否则就是理解上有问题,需要找负责人再次确认。相关人员任务拆分后,还需要与其它同事相关确认。

前端
  • 静态页面
  • 交互逻辑实现
  • 数据接入
  • 联调测试
后端
  • 数据库设计
  • 模块拆分
  • 接口设计和测试
设计
  • UIKit设计
  • 交互逻辑设计
  • 层级规范化
测试
  • 冒烟测试用例
  • 全量测试用例
  • 自动化测试
  • 接口测试

接口评审

前后端一起制定API接口,保证接口的一致性、合理性、效率,输出接口文档,前端通过文档来建立MOCK数据,后端通过文档来实现接口。前后端一致基于接口文档编程,是非常重要的一个步骤。

注意:后续开发中任何API接口的改动,务必通知到相关开发人员,避免后续联调

前端UI设计

前端和UI设计沟通,交互、动画、页面细节等,制定UIKit,统一设计方案,组件化能够让效率和规范化得到提升。其中有对原型疑问和最终设计结果需要跟产品确认。

后期

UI验收

前端实现静态页面和交互效果后(数据可以模拟),和UI设计人员、产品人员一起配合将页面做验收。如果是模拟的数据,那真实数据提供后必须再过一次。

联调测试

自行冒烟测试

前端联调测试之前,一般前端是有MOCK数据的,所以切换起来只需要修改Config配置文件即可,前提也是UI交互和业务逻辑功能完善。

在后端给到前端API之前,开发人员必须自己先行通过接口冒烟测试,保证最基本的参数校验和接口稳定性,(现实开发中,有蛮多人会有侥幸和自我心理,觉得接口写完了没怎么自己测试就丢给前端了,这样出现问题会影响效率)。

此阶段前后端人员沟通频繁。

业务关联性接口

业务关联性接口如何联调测试,比如 B 接口的发送请求参数依赖的是 A 接口返回的数据,这时候呢,后端有义务去在测试数据库中写入测试数据方便前端人员做业务接口测试。

灰度发布

当遇到一个新的迭代出现较大功能变更时,这时候盲目全量发布是有危险的,包含用户满意度,隐形BUG等都会影响到产品满意度,这个时候需要根据实际情况来做灰度发布。

制定更新规则

一般客户端是通过访问后台接口来拿到更新信息的,所以可以通过在后端制定一个更新规则来计算该请求中携带的用户或者其他因素得到是否拿到更新信息。

小程序端可以在服务商(微信,支付宝)后台开放平台来设置灰度发布,这是平台自带的功能,但是不支持按用户数据来分类更新。

蓝绿部署

前面也说过服务端制定一个更新规则,比如(xxx时间前的用户,xxx地区的用户,最近登录xxx个用户)来维护这个白名单,如果只是单纯的按百分比,那么后台和运维同学可以用蓝绿部署去做请求分流和切换支持。

收尾

埋点统计

事件列表

由产品提供需要埋点的事件列表以及数据要求,根据实际情况使用第三方统计(集成快,功能全,可能收费),和自研统计方案(时间长,功能是按迭代增加,保密性强,适合有重要私密性数据分析)。

无论哪种,前端人员都需要再封装一层抽象,支持多个第三方统计和自研系统切换。

同时还要注意,事件请求不能影响到业务请求的效率,一般事件请求是做在下一个事件循环当中,如setTimeout,promise等,按实际情况处理。

错误日志

前端错误日志一般也是采用第三方,但也是需要注意的是不能影响业务请求。
还有一点的是前端代码一般是压缩混淆过的,所以需要注意提供map文件来定位具体错误代码。

后端错误日志采用打印log,和记录文件等方式,遇到紧急情况要实时观测log的打印排查错误,相关人员定时周期去检查错误日志文件。

迭代总结

经过一系列的阶段,功能发布上线后,整个迭代小组人员需要记录期间出现过的问题,自己的想法,如何解决,最终如何解决等。带着自己的问题和方案聚集在一个会议当中总结,让每次迭代得到经验。