---
url: /doc/ProjectGuide/vy932l5m/index.md
---
## 整体研发流程

::: steps

1. 团队共同确认目标和规划,开会讨论，产出目标和规划文档

2. 产品调研和需求分析，产出调研报告和需求分析文档或需求规格说明书

3. 产品调研和需求分析，产出调研报告和需求分析文档或规格说明

4. 需求评审，开需求评审会，明确要做的需求和工作，评估工作量并明确工作时间节点。

需求确认检查，部分可能遇到的问题：

（1）需求说明清晰吗？有没有可能造成误解？

（2）需求的来源（如人员、规则、文档）弄清了吗？需求的最终说明是否已经根据或对照最初来源检查过？

（3）需求是否用定量的术语界定？（越关键性的需求越要采用定量的方式陈述）

（4）其他哪些需求和此需求相关？是否已经使用交叉索引矩阵或其他机制清楚地加以说明？

（5）需求是否违背某个系统领域的约束？

（6）需求是否可测试？如果可以，能否说明检验需求的测试（有时称为确认准则)？

（7）对已经创建的任何系统模型，需求是否可追溯？

（8）对整体系统/产品目标，需求是否可追溯？

（9）规格说明\[^1] 的构造方式是否有助于理解、轻松引用和翻译成更技术性的工作产品？

（10）对已创建的规格说明是否建立了索引？

（11）和系统性能、行为及运行特征相关的需求说明是否清楚？哪些需求是隐含出现的？

5. 方案设计产出方案设计文档，比如数据库表设计、页面设计、接口设计等
6. 开发阶段，包括各自开发、单元测试、前后端联调等
7. 测试和验收，包括研发自测、产品验收、组内验收等
8. 代码提交，提交可上线的代码，需要由负责人审查，通过后可合并
9. 部署上线，将代码发布到服务器上，组内进行上线通知并更新上线文档，上线后需要自行验证
10. 产品迭代，持续收集用户对新功能的反馈、并进行数据分析，从而验证改动效果，便于下一轮的更新迭代。

:::

::: details 沟通

> \[!NOTE]
>
> **沟通**
>
> 在技术活动开始前，和客户（或其他利益相关者）进行沟通和协作。目的是理解利益相关者的项目目标，并收集需求以定义软件特性和功能。

:::

::: details 策划

> \[!NOTE]
>
> **策划**
>
> 策划活动就好比地图，称为软件项目计划，用以指导团队的项目旅程，它定义和描述了软件工程工作，包括需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。

:::

::: details 建模

> \[!NOTE]
>
> **建模**
>
> 一个描述项目构想的草图，用以理解整个项目的体系结构、不同构件如何结合以及其他特性。如果有需要，可以将草图不断细化，以更好理解问题并找到解决方案。

:::

::: details 构建

> \[!NOTE]
>
> **构建**
>
> 对所做设计进行构建，包含编码和测试。

:::

::: details 部署

> \[!NOTE]
>
> **部署**
>
> 软件（ 全部或者部分增量 ）交付给用户，用户对其评测并给出反馈意见。

:::

> \[!TIP]
>
> 对于许多项目来说，随着项目的开展，框架活动可以迭代运用，以上五个活动会不断重复。每次项目迭代都会产生一个 **软件增量（ software increment ）**，每个软件增量实现了部分软件特性和功能。随着每次软件增量的产生，软件逐渐完善。
>
> 以上**产品迭代**就相当于于部分增量，在用户使用过程中收集反馈，进行增量迭代。
>
> 详细参考[软件过程](https://chgoh7.site/JavaEE/glv0cp3d/#软件过程)的软件工程过程框架

## 开发规范

### 开发前注意事项

> \[!CAUTION]
> 确保自己充分理解了业务和需求，需要先进行整体的方案设计；尤其是对于重要需求和核心业务，必须先跟组内成员核对方案并通过后，才能下手开发，避免重复工作。

* 先熟悉项目再开发，建议阅读项目文档、项目代码、接口文档、前端组件文档等。

> \[!WARNING]
>
> 慎重引入新的依赖或类库、或者升级版本，重大依赖变更需要和组内其他成员确认。

* 熟悉团队已实现的功能和代码，尽量复用，避免重复开发。
* 熟悉团队内部的研发规范，并在 IDE 中进行相应的配置，比如前端配置 ESLint、Prettier 等代码规范插件。

### 开发中注意事项

1. 开发新功能时，确保从项目仓库拉取 **最新主分支** 的代码。

> \[!CAUTION]
> 每个功能都要新建自己的分支进行开发，**千万不要直接修改主分支的代码**！注意分支名称要使用英文、足够语义化，不要和其他人的混淆。

3. 开发时，尽量复用现有的功能、模块、类、方法、对象代码。有现成的代码，就不要再重复编写。如无法复用，可以适当通过注释说明。

4. 开发时，遵循团队内部的研发规范，尽量参考现有项目代码的写法，尤其是不要使用和原项目不一致的格式、命名、写法，避免特立独行。

5. 开发过程中，有任何不明确的地方，不要凭空猜测，及时去联系项目的其他成员或负责人确认。

6. 开发过程中，每隔一段时间（比如 1 - 3 天）可以使用 `git pull` 同步一下最新的主分支代码，防止合并代码冲突。

7. 开发过程中，注意整体时间进度的把控，先完成再完美，有风险时及时反馈。

8. 开发时，需要格外注意对异常情况的捕获和处理。

9. 每个分支尽量保证纯净，尽量减少每次开发和提交时改动的代码量。建议每次开分支只改一个功能、Bug 或模块，不要把多个不相关的功能写在一起，并且非必要不修改。

> \[!CAUTION]
>
> 完成部分功能开发后，一定要自测！自测时，可以 Mock 假数据。**注意一定不要在线上测试、一定不要影响线上数据！**

## 代码提交规范

* 只有通过测试和产品验收的代码，才能够发起合并到主分支的 PR 请求。在这之前可以提交到自己的分支。

  > \[!CAUTION]
  >
  > 发起合并到主分支的 PR 前，**一定要完整阅读 3 遍自己的代码**，避免不规范的写法和无意义的改动。

* 每次合并尽量只专注于一个功能或改动，避免多个功能耦合在一起合并，提高审查效率并降低改动风险。

* 每次提交时，需要在 commit 信息中提供代码改动说明，还可以通过关联需求文档、测试用例、方案文档、效果截图等方式进行补充说明。
  > \[!TIP]
  >
  > commit 信息可参考[《约定式提交》文档](https://www.conventionalcommits.org/zh-hans)，但不做强制要求。

> \[!CAUTION]
>
> 除非特殊情况，否则所有的代码必须经过至少一位项目负责人 Code Review 审核通过后，才能合并；并且只有合并到主分支的代码才允许发布上线。

​

## 上线规范

### 上线前注意事项

* 上线前，除了严格验证功能特性能否正常运行、并符合需求外，还要格外关注程序的：

  * 健壮性。比如给用户友好的错误提示、输入校验。

  * 安全性。防止越权操作、输入校验。

  * 稳定性。尽量保证调用 100% 成功，如果有几率失败，要考虑重试或容错策略。

* 除非特殊情况，只有经过产品验证的功能、通过代码审核的主分支代码才允许发布上线。

* 除非特殊情况，尽量在工作日上线（建议周二 ~ 周四），保证上线后出了问题时能够及时修复。

### 上线后注意事项

> \[!CAUTION]
> 上线后，一定要再次进行完整流程的测试，尤其要重点关注权限相关的功能测试。

> \[!CAUTION]
> 上线后，一定要在群内及时同步上线信息，周知相关的成员，如果遇到问题第一时间反馈。

3. 首次上线后，需要即时配置监控告警。
4. 上线验证通过、并经过内部群成员确认后，可以在外部用户群发布版本更新公告。
5. 上线后，即时更新项目的更新记录文档。
6. 注意，上线不是终点。上线后的一段时间（至少一周内），一定要持续观察自己负责的功能是否正常运行、持续接受用户反馈、通过数据分析来观察新功能的效果，期间有任何问题都需要即时修复处理，并且准备好下一期的改进迭代。

## 附录 A：术语表

\[^1]: `规格说明` 每个项目有不同的规格说明特性。在某些情况下，规格说明是指收集到的用户场景或其他一些事物。在另一些情况下，规格说明可以包括用户场景、模型和说明性文档。

## 参考文献

* *Software engineering a practitioner's approach*（软件工程：实践者的研究方法）