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

「爱情、让人受尽委屈。」 2023-07-10 14:14 7阅读 0赞

## 概述 ##

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

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

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

![format_png][]

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

## 1 需求评审 ##

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

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

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

评审前

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

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

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

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

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

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

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

评审中

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

一般评审至少有两次（初稿和终稿）。

评审后

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

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

排期模板如下：

![format_png 1][]

## 2 技术评审 ##

评审前

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

重要事情说三遍！

技术评审主要评审什么？

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

评审中

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

一般评审至少有两次（初稿和终稿）。

评审后

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

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

按部就班，按计划行事。

## 3 需求开发 ##

编码

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

代码审查

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

代码审查主要审查什么？

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

联调

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

自测

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

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

提测

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

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

## 4 跟进测试 ##

测试用例评审

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

Bug 修复

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

## 5 跟进上线 ##

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

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

## 6 线上问题复盘 ##

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

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

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

![format_png 2][]

## 小结 ##

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

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

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

就到这吧，以上供参考。

[Link 1]: https://mp.weixin.qq.com/s/kuKQjTLp1isftJC6WZ6Qaw
[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAyMC8zLzIvMTcwOWFiYWY2NGQwYzQ0MA?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAyMC8zLzIvMTcwOWFiYjJhM2M2ODE5ZQ?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAyMC8zLzIvMTcwOWFiYjdmMTYwMDY4Mw?x-oss-process=image/format,png