关于chrome:合理的游戏开发流程应该是这样

39次阅读

共计 2280 个字符,预计需要花费 6 分钟才能阅读完成。

这篇文章分享开发流程标准,目标是进步产品质量,优化开发流程,供大家参考。

标准是死的,人是活的,心愿本人定的标准,不要被打脸。

接下来从以上六个阶段进行逐个拆解。

1 需要评审
作为技术人员必定都加入过需要评审会,不晓得有没有遇到这样的状况?

产品经理依照 PRD 文档读一遍,参会人员金石为开。

产品经理刚讲了一个需要点,参会人员就产生了强烈的探讨,都在证实本人是对的。

参会人员对需要的指标不明确,对需要点进行发散思维探讨,最终偏离方向。

遇到以上问题,必定是在加入需要评审之前未做充分准备,那么问题来了,须要提前准备什么?

评审前

不要听产品同学说,该需要是大老板跟进的、十分重要、十分紧急之类的,就问产品三个问题:

解决了什么问题?

晋升了什么指标?

有什么商业价值?

这三个问题搞清楚了,再进行评审。

产品经理收回 原型 和 PRD 初稿后,开发人员要有 1-2 天工夫(具体工夫依据我的项目大小而定),相熟文档,有任何疑难能够反馈给开发经理,由开发经理对立收集再反馈给产品经理,产品经理逐个进行答疑。

相熟完文档后,开发人员和开发经理须要一起确定:

技术选型(前端 / 后端框架、日志中间件、消息中间件、数据库 …)

技术架构(组件与组件之间如何协同工作,如何部署)

技术难点预知(明确存在的技术难点,并确定解决方案)

性能瓶颈预知(明确可能存在性能瓶颈的中央,并确定应答措施)

上下游零碎交互(明确在流程中的哪个地位,约定接口文档提供工夫、接口联调工夫)

功能模块划分(工作拆分和调配)

技术计划确定后,须要输入技术设计文档,包含:总体设计、概要设计、具体设计、接口设计 等。

评审中

开发人员必须加入,有需要不明确的中央当场提出,同时开发人员也须要思考产品需要是否正当,可适当提出本人的产品意见。

个别评审至多有两次(初稿和终稿)。

评审后

评审后,如有需更新技术文档的请及时进行更新。

开发经理首先须要思考团队现有的资源及我的项目的优先级,而后依据技术设计文档进行评估排期。

排期模板如下:

2 技术评审
评审前

开发人员肯定要器重技术设计!

开发人员肯定要器重技术设计!

开发人员肯定要器重技术设计!

重要事件说三遍!

技术评审次要评审什么?

零碎关系图、模块关系图、流程图的设计,画图工具依据本人喜好即可。

接口设计,须要思考接口的 兼容性、扩展性、参数命名恪守 参数命名标准 等。

数据库设计,须要恪守 数据库设计规范,并记录 数据表变更文档。

具体设计,须要思考公共类、公共办法、办法定义 恪守 我的项目框架目录标准。

评审中

开发人员和开发经理必须加入,波及到总体设计和概要设计时,须要邀请 架构师 参加,波及到数据库调整时,须要邀请 DBA 参加。

个别评审至多有两次(初稿和终稿)。

评审后

评审后,如有需更新排期文档的请及时进行游戏更新。

排期确定后,通过邮件形式进行回复排期,应用标准化的 回复排期邮件模板。

循序渐进,按计划行事。

3 需要开发
编码

开发人员编码过程中,须要恪守团队的 编码标准,同时严格依照设计文档中的技术计划执行,除了保障代码逻辑的正确性外,还须要思考代码封装性、可维护性、可扩展性,当编码阶段发现技术计划须要调整时,须要及时告诉开发经理,通过批准后能力施行,波及到引入新框架和新技术,也须要提前告诉开发经理。

代码审查

开发人员须要控制代码提交的频次和粒度,每次代码提交之后 24 小时内,须要被动分割代码审查人实现查看,开发经理负责查看是否执行到位。

代码审查次要审查什么?

规范性查看(是否合乎代码标准、提交备注标准等)

健壮性查看(是否陷入死循环、资源未开释等)

安全性查看(是否存在 SQL 注入、XSS、*F、CSRF、越权、文件上传等)

性能查看(是否存在未加缓存频繁连贯 DB,是否须要连接池)

联调

开发人员积极主动地推动联调工作,如果遇到妨碍及时告诉技术经理进行协调。

自测

联调结束后,开发人员须要同时实现自测,并将标准化的 自测报告 发给测试团队。

例如:wwwsangpi.com 对于有性能要求的我的项目,须要开发人员进行性能测试,并出具标准化的 性能测试报告。

提测

自测结束后,通过邮件形式进行提测申请,应用标准化的 申请提测邮件模板。

开发人员依据公司运维提供的公布形式,进行部署到测试环境。

4 跟进测试
测试用例评审

开发人员必须加入,避免出现测试与开发对需要了解不统一的状况。

Bug 修复

开发人员及时关注 Bug 列表,疾速修复迭代公布,如果测试进度存在延期危险,须要及时告诉开发经理。

5 跟进上线
开发人员首先确认 Bug 全副敞开,同时产品人员在测试环境验收通过,而后须要被动推动相干团队理清上线依赖和上线程序,同时确定回滚预案,最初依据公司运维提供的公布形式,进行部署到线上环境。

线上环境部署实现后,通过邮件形式进行告诉产品人员和测试人员,应用标准化的 上线结束邮件模板,同时踊跃推动测试人员和产品人员实现线上验证,线上呈现问题后第一工夫告诉开发经理。

6 线上问题复盘
需要在测试环境和正式环境,均未测试出 Bug,上线一段时候后呈现 Bug,这种问题用什么制度束缚?

呈现问题后开发人员及时修复,修复完了就完事了。仅仅做到这些还远远不够。

倡议应用如下模板进行复盘。

小结
大家能够数一数下面应用到了多少标准,这时有敌人会说了,这标准也太多了吧,这和工厂工人有什么区别,咱们程序员是有创造性的,咱们喜爱前沿性、挑战性的工作,咱们落拓不羁爱自在 …

针对这个问题,首先我不否定开发人员是有创造性的,但并不是所有的程序员都有创造性,在事实工作场景中大部分程序员不是做创造性工作的,也没必要做创造性工作,所以必须依照标准流程执行。

团队治理和团队之间单干,必须要有标准,并严格执行。

就到这吧,以上供参考。

正文完
 0