设计文档

  少于1分钟  

在提交将显著改变任何 Drycc 组件行为的拉取请求之前，例如新功能或主要重构，贡献者应该首先打开一个代表设计文档的问题。

目标

设计文档帮助确保项目贡献者：

• 在功能开发中尽早涉及利益相关者
• 确保代码更改实现原始动机和设计目标
• 为功能或更改建立明确的验收标准
• 强制执行测试驱动的设计方法和自动化测试覆盖

内容

设计文档问题应该命名为 Design Doc: <change description> 并包含以下部分：

目标

本节应简要描述提议的更改及其背后的动机。将编写测试以确保此设计目标由更改实现。

本节还应引用一个单独的 GitHub 问题，该问题跟踪功能或更改，通常分配给发布里程碑。

代码更改

本节应详细说明实现更改所需的代码更改，以及提议的实现。这应该尽可能详细，以帮助审阅者理解更改。

测试

所有更改都应由自动化测试覆盖，无论是单元测试还是集成测试（理想情况下两者都有）。本节应详细说明如何编写测试来验证更改是否实现设计目标并且不会引入任何回归。

如果更改无法通过自动化测试充分覆盖，则应重新考虑设计。如果受影响的代码部分根本没有测试覆盖，则应提交单独的问题以将自动化测试与该代码库部分集成。

此处描述的测试还形成了更改的验收标准，以便在完成后，维护者可以在确认测试通过 CI 后合并拉取请求。

批准

设计文档遵循与最终拉取请求相同的合并批准审查过程，维护者将特别注意确保任何更改的利益相关者都包含在设计文档的讨论和审查中。

一旦设计被接受，作者可以完成更改并提交拉取请求进行审查。拉取请求应关闭更改的设计文档以及跟踪问题或因更改而关闭的任何问题。

有关拉取请求和提交消息格式的更多信息，请参见提交拉取请求。