面试官:你了解规范的开发流程吗?
共 2338字,需浏览 5分钟
·
2020-03-05 23:23
作者 | 訢亮
来源 | 新亮笔记
概述
这篇文章分享开发流程规范,目的是提高产品质量,优化开发流程,供大家参考。
规范是死的,人是活的,希望自己定的规范,不要被打脸。
接下来从以上六个阶段进行逐一拆解。
1 需求评审
作为技术人员肯定都参加过需求评审会,不知道有没有遇到这样的情况?
- 产品经理按照 PRD 文档读一遍,参会人员无动于衷。
- 产品经理刚讲了一个需求点,参会人员就产生了激烈的讨论,都在证明自己是对的。
- 参会人员对需求的目标不明确,对需求点进行发散思维讨论,最终偏离方向。
遇到以上问题,肯定是在参加需求评审之前未做充分准备,那么问题来了,需要提前准备什么?
评审前
不要听产品同学说,该需求是大老板跟进的、非常重要、非常紧急之类的,就问产品三个问题:
- 解决了什么问题?
- 提升了什么指标?
- 有什么商业价值?
这三个问题搞清楚了,再进行评审。
产品经理发出 原型
和 PRD
初稿后,开发人员要有 1-2
天时间(具体时间根据项目大小而定),熟悉文档,有任何疑问可以反馈给开发经理,由开发经理统一收集再反馈给产品经理,产品经理逐一进行答疑。
熟悉完文档后,开发人员和开发经理需要一起确定:
- 技术选型(前端/后端框架、日志中间件、消息中间件、数据库...)
- 技术架构(组件与组件之间如何协同工作,如何部署)
- 技术难点预知(明确存在的技术难点,并确定解决方案)
- 性能瓶颈预知(明确可能存在性能瓶颈的地方,并确定应对措施)
- 上下游系统交互(明确在流程中的哪个位置,约定接口文档提供时间、接口联调时间)
- 功能模块划分(任务拆分和分配)
技术方案确定后,需要输出技术设计文档,包括:总体设计
、概要设计
、详细设计
、接口设计
等。
评审中
开发人员必须参加,有需求不明确的地方当场提出,同时开发人员也需要思考产品需求是否合理,可适当提出自己的产品意见。
一般评审至少有两次(初稿和终稿)。
评审后
评审后,如有需更新技术文档的请及时进行更新。
开发经理首先需要考虑团队现有的资源及项目的优先级,然后根据技术设计文档进行评估排期。
排期模板如下:
2 技术评审
评审前
开发人员一定要重视技术设计!
开发人员一定要重视技术设计!
开发人员一定要重视技术设计!
重要事情说三遍!
技术评审主要评审什么?
系统关系图
、模块关系图
、流程图的设计
,画图工具根据自己爱好即可。接口设计
,需要考虑接口的 兼容性、扩展性、参数命名遵守 参数命名规范 等。数据库设计
,需要遵守 数据库设计规范,并记录 数据表变更文档。详细设计
,需要考虑公共类、公共方法、方法定义 遵守 项目框架目录规范。
评审中
开发人员和开发经理必须参加,涉及到总体设计和概要设计时,需要邀请 架构师 参与,涉及到数据库调整时,需要邀请 DBA 参与。
一般评审至少有两次(初稿和终稿)。
评审后
评审后,如有需更新排期文档的请及时进行更新。
排期确定后,通过邮件方式进行回复排期,使用标准化的 回复排期邮件模板。
按部就班,按计划行事。
3 需求开发
编码
开发人员编码过程中,需要遵守团队的 编码规范,同时严格按照设计文档中的技术方案执行,除了保证代码逻辑的正确性外,还需要考虑代码封装性
、可维护性
、可扩展性
,当编码阶段发现技术方案需要调整时,需要及时通知开发经理,经过同意后才能实施,涉及到引入新框架和新技术,也需要提前通知开发经理。
代码审查
开发人员需要控制代码提交的频次和粒度,每次代码提交之后 24 小时内,需要主动联系代码审查人完成检查,开发经理负责检查是否执行到位。
代码审查主要审查什么?
- 规范性检查(是否符合代码规范、提交备注规范等)
- 健壮性检查(是否陷入死循环、资源未释放等)
- 安全性检查(是否存在SQL注入、XSS、SSRF、CSRF、越权、文件上传等)
- 性能检查(是否存在未加缓存频繁连接DB,是否需要连接池)
联调
开发人员积极主动地推动联调工作,如果遇到阻碍及时通知技术经理进行协调。
自测
联调完毕后,开发人员需要同时完成自测,并将标准化的 自测报告 发给测试团队。
对于有性能要求的项目,需要开发人员进行性能测试,并出具标准化的 性能测试报告。
提测
自测完毕后,通过邮件方式进行提测申请,使用标准化的 申请提测邮件模板。
开发人员根据公司运维提供的发布方式,进行部署到测试环境。
4 跟进测试
测试用例评审
开发人员必须参加,避免出现测试与开发对需求理解不一致的情况。
Bug 修复
开发人员及时关注 Bug 列表,快速修复迭代发布,如果测试进度存在延期风险,需要及时通知开发经理。
5 跟进上线
开发人员首先确认 Bug 全部关闭,同时产品人员在测试环境验收通过,然后需要主动推动相关团队理清上线依赖和上线顺序,同时确定回滚预案,最后根据公司运维提供的发布方式,进行部署到线上环境。
线上环境部署完成后,通过邮件方式进行通知产品人员和测试人员,使用标准化的 上线完毕邮件模板,同时积极推动测试人员和产品人员完成线上验证,线上出现问题后第一时间通知开发经理。
6 线上问题复盘
需求在测试环境和正式环境,均未测试出 Bug,上线一段时候后出现 Bug,这种问题用什么制度约束?
出现问题后开发人员及时修复,修复完了就完事了。仅仅做到这些还远远不够。
建议使用如下模板进行复盘。
小结
大家可以数一数上面使用到了多少规范,这时有朋友会说了,这规范也太多了吧,这和工厂工人有什么区别,我们程序员是有创造性的,我们喜欢前沿性、挑战性的工作,我们放荡不羁爱自由...
针对这个问题,首先我不否认开发人员是有创造性的,但并不是所有的程序员都有创造性,在现实工作场景中大部分程序员不是做创造性工作的,也没必要做创造性工作,所以必须按照规范流程执行。
团队管理和团队之间合作,必须要有规范,并严格执行。
就到这吧,以上供参考。