Desmos项目贡献指南与技术规范深度解析

前言

Desmos作为一个基于区块链技术的社交网络协议，其开发过程遵循严谨的技术规范和协作流程。本文将深入剖析Desmos项目的技术贡献体系，帮助开发者理解其架构决策、代码提交流程、测试规范等核心要素。

架构决策记录(ADR)机制

Desmos采用架构决策记录(Architecture Decision Records)来管理重大技术决策。这一机制确保所有架构变更都经过充分讨论和文档化。

ADR流程要点

1. 建议阶段：任何架构变更都应先在社区发起讨论，通过issue或discussion形式征集意见
2. 共识形成：当高层设计方向达成初步一致后，方可启动ADR编写流程
3. 文档规范：ADR需按照标准模板编写，包含背景、决策、状态等核心章节

该流程有效避免了过早编码导致的资源浪费，确保各方对技术路线达成共识后再投入开发。

代码提交规范

Pull Request管理

Desmos对代码合并请求有严格规范：

1. 分类前缀：PR标题必须包含类型前缀，如fix:、feat:、refactor:等，遵循Conventional Commits规范
2. 单一职责：每个PR应只解决一个特定问题，保持变更集的原子性
3. 模板选择：根据变更类型选择对应PR模板（默认、文档或其他）

代码审查流程

1. 双重审查：生产代码变更需至少两位核心开发者批准
2. 审查等级：
   • LGTM表示表面审查通过
   • Approval表示已完成部分或全部审查清单项
3. 责任划分：审查者需对代码质量、安全性、命名一致性等负责

开发环境配置

依赖管理

项目采用Go 1.14 Modules管理依赖：

• 主分支应始终保持go get可用状态
• 依赖冲突时可使用go mod tidy -v解决

Protobuf工具链

Desmos使用容器化Protobuf工具链确保环境一致性：

• make proto-format：格式化.proto文件
• make proto-lint：静态检查
• make proto-check-breaking：检查破坏性变更
• make proto-gen：生成桩代码

开发者需配置IDE的protobuf路径以支持自动补全。

测试规范

测试执行

• 顶层目录执行make test运行全部测试
• 避免使用t.Skip或t.Fail，优先使用require/assert

表驱动测试

对于多输入场景，推荐使用表驱动测试模式。错误信息应遵循特定格式：

<描述>, tc #<测试用例索引>, i #<迭代索引>

示例：

require.Equal(t, expected, actual, 
    "交易哈希不匹配, tc #%d, i #%d", tcIndex, i)

分支模型与发布流程

主干开发模型

Desmos采用trunk-based开发模型：

• master分支代表最新开发状态
• 禁止强制推送master（回滚除外）
• 开发前需基于master创建特性分支

发布流程详解

1. 候选版本：

   • 从master创建rc/v*分支
   • 更新CHANGELOG.md并验证链接
   • 进行大规模模拟测试（如400种子/2000区块）

2. 正式发布：

   • 通过测试后创建release/vX.X.X分支
   • 打标签并创建GitHub Release
   • 删除RC分支

3. 补丁发布：

   • 维护release/vX.X.N分支接收补丁
   • 需明确标注影响范围和回归风险

代码所有权机制

项目通过CODEOWNERS文件管理代码权限：

• 定期（双月）评估新成员资格
• 新增代码所有者需现有成员一致同意
• 权限变更通过PR流程公开记录

最佳实践建议

1. 开发准备：

   • 配置pre-commit钩子自动格式化代码
   • 运行make lint-fix确保代码规范

2. 文档更新：

   • 代码变更需同步更新相关文档
   • 遵循文档写作规范

3. 协作建议：

   • 早期提交Draft PR获取反馈
   • 复杂功能先讨论再实现
   • 保持提交历史的清晰性

通过遵循这些规范，开发者可以高效地参与Desmos项目贡献，同时确保代码库的质量和可维护性。