究竟什么样的开发流程是规范的?

2,046 阅读7分钟

概述

有读者反馈,读了文章 一线技术管理者究竟在管什么事? 收获满满,但还有点不过瘾,还想了解更细的东西...

这篇文章分享开发流程规范,目的是提高产品质量,优化开发流程,供大家参考。

规范是死的,人是活的,希望自己定的规范,不要被打脸。

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

1 需求评审

作为技术人员肯定都参加过需求评审会,不知道有没有遇到这样的情况?

  • 产品经理按照 PRD 文档读一遍,参会人员无动于衷。
  • 产品经理刚讲了一个需求点,参会人员就产生了激烈的讨论,都在证明自己是对的。
  • 参会人员对需求的目标不明确,对需求点进行发散思维讨论,最终偏离方向。

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

评审前

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

  1. 解决了什么问题?
  2. 提升了什么指标?
  3. 有什么商业价值?

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

产品经理发出 原型PRD 初稿后,开发人员要有 1-2 天时间(具体时间根据项目大小而定),熟悉文档,有任何疑问可以反馈给开发经理,由开发经理统一收集再反馈给产品经理,产品经理逐一进行答疑。

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

  • 技术选型(前端/后端框架、日志中间件、消息中间件、数据库...)
  • 技术架构(组件与组件之间如何协同工作,如何部署)
  • 技术难点预知(明确存在的技术难点,并确定解决方案)
  • 性能瓶颈预知(明确可能存在性能瓶颈的地方,并确定应对措施)
  • 上下游系统交互(明确在流程中的哪个位置,约定接口文档提供时间、接口联调时间)
  • 功能模块划分(任务拆分和分配)

技术方案确定后,需要输出技术设计文档,包括:总体设计概要设计详细设计接口设计 等。

评审中

开发人员必须参加,有需求不明确的地方当场提出,同时开发人员也需要思考产品需求是否合理,可适当提出自己的产品意见。

一般评审至少有两次(初稿和终稿)。

评审后

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

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

排期模板如下:

2 技术评审

评审前

开发人员一定要重视技术设计!

开发人员一定要重视技术设计!

开发人员一定要重视技术设计!

重要事情说三遍!

技术评审主要评审什么?

  • 系统关系图模块关系图流程图的设计,画图工具根据自己爱好即可。
  • 接口设计,需要考虑接口的 兼容性、扩展性、参数命名遵守 参数命名规范 等。
  • 数据库设计,需要遵守 数据库设计规范,并记录 数据表变更文档
  • 详细设计,需要考虑公共类、公共方法、方法定义 遵守 项目框架目录规范

评审中

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

一般评审至少有两次(初稿和终稿)。

评审后

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

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

按部就班,按计划行事。

3 需求开发

编码

开发人员编码过程中,需要遵守团队的 编码规范,同时严格按照设计文档中的技术方案执行,除了保证代码逻辑的正确性外,还需要考虑代码封装性可维护性可扩展性,当编码阶段发现技术方案需要调整时,需要及时通知开发经理,经过同意后才能实施,涉及到引入新框架和新技术,也需要提前通知开发经理。

代码审查

开发人员需要控制代码提交的频次和粒度,每次代码提交之后 24 小时内,需要主动联系代码审查人完成检查,开发经理负责检查是否执行到位。

代码审查主要审查什么?

  • 规范性检查(是否符合代码规范、提交备注规范等)
  • 健壮性检查(是否陷入死循环、资源未释放等)
  • 安全性检查(是否存在SQL注入、XSS、SSRF、CSRF、越权、文件上传等)
  • 性能检查(是否存在未加缓存频繁连接DB,是否需要连接池)

联调

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

自测

联调完毕后,开发人员需要同时完成自测,并将标准化的 自测报告 发给测试团队。

对于有性能要求的项目,需要开发人员进行性能测试,并出具标准化的 性能测试报告

提测

自测完毕后,通过邮件方式进行提测申请,使用标准化的 申请提测邮件模板

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

4 跟进测试

测试用例评审

开发人员必须参加,避免出现测试与开发对需求理解不一致的情况。

Bug 修复

开发人员及时关注 Bug 列表,快速修复迭代发布,如果测试进度存在延期风险,需要及时通知开发经理。

5 跟进上线

开发人员首先确认 Bug 全部关闭,同时产品人员在测试环境验收通过,然后需要主动推动相关团队理清上线依赖和上线顺序,同时确定回滚预案,最后根据公司运维提供的发布方式,进行部署到线上环境。

线上环境部署完成后,通过邮件方式进行通知产品人员和测试人员,使用标准化的 上线完毕邮件模板,同时积极推动测试人员和产品人员完成线上验证,线上出现问题后第一时间通知开发经理。

6 线上问题复盘

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

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

建议使用如下模板进行复盘。

小结

大家可以数一数上面使用到了多少规范,这时有朋友会说了,这规范也太多了吧,这和工厂工人有什么区别,我们程序员是有创造性的,我们喜欢前沿性、挑战性的工作,我们放荡不羁爱自由...

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

团队管理和团队之间合作,必须要有规范,并严格执行。

就到这吧,以上供参考。

推荐阅读