项目开发流程

ℹ️导读

互联网公司标准项目开发流程：7 个角色 → 4 级环境 → 5 个环节。 与 00-项目线全景 的十组动线配套使用。

一张图看懂

image-3a46c7b6

团队角色：7 类人

缩写 全称 中文 职责
PM Product Manager 产品经理 调研市场、分析需求、画原型草图；同时兼任项目经理（Project Manager）把控进度
UE User Experience 交互式设计师 把需求转化为交互原型图
UI User Interface 视觉设计师 根据原型图输出设计图
FE Front End 前端开发 实现客户端程序——web 界面、手机 app、微信小程序
RD Research & Development 后端开发 后端技术设计与实现，开工前与前端定好接口规范
QA Quality Assurance 测试人员 设计测试用例、执行专业测试、跟踪 bug
OP Operations 运维人员 设计整套系统的部署架构，负责上线
ℹ️两个易混点
  • PM 的双关：既是 Product Manager（产品经理，定需求）也是 Project Manager（项目经理，管进度），大厂里常由同一人担任。
  • 接口规范先行：FE 与 RD 对接的第一件事是定接口契约——URL、入参、返回格式先谈妥，然后才能各写各的。这也是 项目线 里接口文档规范重要的原因。

开发环境：4 级

环境 说明 谁在用
个人电脑 日常编码、本地自测 开发人员
测试环境 20 多台台式机组成的联调环境 开发 + QA
Staging 与线上环境一比一的预发环境，上线前最后验证 全团队
线上环境 互联网用户使用的环境 真实用户

发布节奏：

  • 小版本：一两周上线一个（小功能或修复）
  • 大版本：一个月到一个半月上线一个——失败则回滚（把线上切回上一版本）
ℹ️为什么需要 Staging

测试环境和线上总有差异（数据量、配置、真实第三方服务），"一比一"的 Staging 是最后一道保险：上线方案先在 Staging 演练，确认无误才动线上。回滚的底气来自版本管理——每个版本都打 tag（见 01-Git与版本控制）。

开发流程：4 个阶段

flowchart LR
    A[需求分析] --> B[项目设计]
    B --> C[项目开发]
    C --> D[项目测试]
    D --> E[项目上线]

1️⃣ 需求分析

PM 主导：

  1. 调研市场、分析需求、画原型草图
  2. 召集所有相关技术人员开需求分析会——会开 n 次直到需求明确

需求分析会是全员对齐的锚点：FE/RD/QA/OP 都要参加，从各自角度确认可行性。

2️⃣ 项目设计（项目开发阶段的第一步）

需求明确后，六个角色并行出设计：

角色 设计产出
UE + PM 交互原型图
UI 根据原型图出设计图
FE 前端设计
RD 后端技术设计
QA 测试用例设计
OP 运维架构设计

注意：QA 的测试用例在这个阶段就开始写（不是等开发完才写）；OP 的架构设计也在前期定型。

3️⃣ 项目开发

  • 前后端分头开发（接口规范已在设计阶段定好，互不阻塞）
  • 开发完成后合并

4️⃣ 项目测试

按顺序三道关：

  1. code review——开发人员过一遍代码，审查逻辑与隐患
  2. 自测改 bug——开发人员自测并修复
  3. QA 专业测试——按设计阶段写好的测试用例测，提 bug 改 bug

5️⃣ 项目上线

  1. 运维人员编写上线方案
  2. 测试验证
  3. 按环境逐级发布：测试 → Staging → 线上

术语速查

术语 含义
需求分析会 PM 召集全员对齐需求，开到需求明确为止（n 次）
接口规范 前后端契约：URL、入参、返回格式、错误码
code review 代码审查：上线前过一遍代码
回滚 上线失败时把线上切回上一版本
小版本 / 大版本 一两周一个 / 一个月到一个半月一个

与项目线的衔接

  • 01-Git与版本控制：流程中"分头开发 → 合并"靠 Git 分支与 PR 落地，tag 是回滚的依据
  • 02-Linux：测试/Staging/线上环境都跑在 Linux 服务器上，租服务器及配置环境是 OP 工作的入门
  • 03-Python与爬虫：自研爬虫线是"个人全角色"的缩影——需求、设计、开发、测试、部署一人全包
  • 04-SpringBoot框架课：RD 后端技术设计的主流实现
  • 05-最佳实践：开发阶段沉淀的工程规范（分层/异常/接口文档/缓存跨域/鉴权/权限校验）

项目分区导航：00-项目线全景 ⬅️ | 01-项目开发流程 ➡️ 02-项目学习建议