团队规范

个人习惯再好，多人协作也需要 共享契约：什么叫「做完」、架构决策怎么记录、谁对质量负责。本课介绍 ADR（Architecture Decision Record） 与 Definition of Done（DoD），把前几课的 Review、测试、文档、工具 写进团队流程。

学习目标

• 会写一条简洁的 ADR（背景、决策、后果）
• 制定可执行的 DoD checklist
• 将规范与 git-essentials、testing-essentials 工作流对齐

ADR 是什么

ADR 记录 重要架构选择 及 为何不用别的方案，避免六个月后「谁决定的、能改吗」无人答。

# ADR-003：Track API 使用 MySQL 而非 Mongo

## 状态
Accepted

## 背景
需要关系型查询与现有 Spring Data JPA 栈一致…

## 决策
继续 MySQL 8，JSON 列存 ext metadata

## 后果
+ 团队熟悉；- 水平扩展需读写分离（见 scaling track）

存于 docs/adr/ 或 wiki；PR 改架构应 新增或 supersede ADR。与 spring-boot-essentials 等技术选型呼应。

Definition of Done

DoD 回答：什么条件下 story/PR 算完成。示例：

• 代码 Review Approve（cq-reviews）
• 单元/必要集成测试绿（testing-essentials）
• 文档/API 注解更新（cq-docs）
• 无新增 Blocker 级静态分析问题（cq-tools）
• 已部署 staging 或 PM 验收

DoD 应 短、可勾选、CI 能证实的尽量自动化。Scrum 团队放在 sprint 计划墙；小团队可写在 README Contributing。

规范如何演进

1. retrospective 收反馈
2. 提案 PR 改 CONTRIBUTING.md 或 DoD
3. 试行一迭代再固化

引入 AI 辅助开发时，在 DoD 加「AI usage 披露、Test plan 人工确认」，见 ai-coding-essentials。

练习

• 为你团队（或假想项目）写 5 条 DoD