摘要：本文介绍一种适用于小型团队的轻量级复用治理机制：通过"声明式竞争"提出通用方案，借助代码评审拦截重复造轮子，在无重流程前提下促进高质量共享代码自然演化。
轻量级复用治理实践：基于竞争与代码评审的工程标准演化机制
适用团队规模 ：5--15 人敏捷开发团队
目标 ：在不引入繁重流程的前提下，有效减少重复造轮子，促进高质量通用能力沉淀
核心理念：让优秀实践在协作中自然胜出，而非靠行政命令强制推行
1. 背景与问题
在小型工程团队中，我们常面临以下矛盾：
- 需要复用：避免重复实现相同逻辑（如重试、幂等、加密、HTTP 客户端封装等），提升开发效率与系统一致性；
- 抗拒重流程：设立架构委员会、编写 RFC、维护标准库等传统做法成本过高，与敏捷节奏冲突；
- 标准滞后：业务快速变化，预设的标准往往脱离实际，反而成为负担。
为此，我们提出一种轻量、自下而上、以代码评审为守门人的复用治理机制。
2. 核心机制
2.1 "声明式竞争"原则
任何成员在开发过程中，若发现某段逻辑可能被多个业务场景复用，可主动将其抽象为通用组件，并"声明"其作为推荐方案：
- 将代码放入
shared/（或common/）目录； - 提供清晰命名、使用示例和单元测试；
- 在 PR 描述中说明："此为通用能力，建议后续类似场景复用"。
✅ 关键：不强制要求审批，但需通过代码质量与实用性赢得团队信任。
2.2 代码评审（CR）作为守门人
在 Code Review 阶段，所有成员有责任检查：
"当前 PR 是否重复实现了
shared/中已存在的功能？"
若发现重复造轮子：
- Reviewer 应明确指出已有方案；
- 要求作者改用现有实现，或提供充分理由说明为何不能复用（如性能、语义差异等）；
- 若理由成立，可允许新实现，但鼓励后续合并或标记差异。
🚫 禁止行为：仅因"不知道有这个"而重复实现------团队应养成"先查 shared/"的习惯。
3. 实施规范
3.1 目录结构约定
bash
src/
├── feature-a/ # 业务模块 A
├── feature-b/ # 业务模块 B
└── shared/ # 通用能力仓库（限界上下文之外的横切关注点）
├── retry/ # 重试策略
├── idempotent/ # 幂等客户端
├── http/ # 封装的 HTTP 客户端
├── crypto/ # 加解密工具
└── README.md # 列出所有组件及使用指南3.2 共享组件准入要求
一个组件要被视为"推荐标准"，需满足：
| 要求 | 说明 |
|---|---|
| ✅ 有明确用途 | 解决具体、高频的问题 |
| ✅ 接口简洁 | 易于理解和使用 |
| ✅ 有单元测试 | 覆盖核心场景 |
| ✅ 有使用示例 | example_test.go 或 demo.py |
| ✅ 被 ≥2 个业务模块采用 | 证明真实复用价值 |
⚠️ 不满足以上条件的代码，即使放在
shared/，也不视为"标准"，仅作参考。
3.3 允许挑战与演进
- 任何成员可提出更优实现，通过 PR 替换旧组件；
- 替换需包含：性能对比、兼容性说明、迁移指引；
- 旧组件可标记为
@deprecated，给予 1--2 个迭代周期过渡。
标准不是永恒的，而是持续演化的共识。
4. 衡量机制效果
| 指标 | 采集方式 | 健康信号 |
|---|---|---|
| CR 拦截率 | 统计含"请复用""已有实现"等评论的 PR 数 | 初期高 → 长期下降（习惯形成） |
| 共享组件使用率 | `grep -r "shared.xxx" src/ | wc -l` |
| 新组件采纳速度 | 从合并到首次被其他模块使用的时间 | ≤2 周 |
| 团队反馈 | 季度匿名问卷 | "是否容易找到/信任共享方案？"得分 ≥4/5 |
5. 适用边界与禁忌
✅ 适合场景
- 工具类、基础设施类能力（HTTP、Retry、Logger、Serializer 等）；
- 跨业务模块的非领域逻辑；
- 团队技术栈统一、沟通成本低的小型团队。
❌ 禁忌
- 不要复用业务领域模型 （如
Order,User）------每个限界上下文应拥有自己的模型； - 不要为了复用而强行抽象 ------遵循 Rule of Three（出现三次再抽象）；
- 不要惩罚"造轮子"行为------应视为学习机会，重点在于引导而非指责。
6. 附录：团队约定模板
在团队 Wiki 或 CONTRIBUTING.md 中加入：
关于代码复用的约定
- 开发前，请先检查
shared/目录是否有可用方案；- 若你实现了一个可能通用的能力，欢迎提交到
shared/并在 PR 中说明；- Code Review 时，若发现重复实现，请友善指出并提供链接；
- 所有共享组件均可被挑战和改进------更好的方案永远受欢迎。
结语
本机制不追求"完美标准化"，而是通过最小干预、最大信任、即时反馈 的方式，在小团队中培育一种自发的复用文化。它尊重一线开发者的判断力，让工程标准在实践中生长，而非在会议室中诞生。
好的工程纪律，是让正确的事变得最容易做。