技术方案评审和 ADR 模板
📝 好的技术决策需要被记录。ADR 让团队成员理解历史决策的背景，避免重复谈论或在不知情况下推翻敬畅的方案。
ADR（架构决定记录）
ADR 模板
# ADR-001: 选择 PostgreSQL 作为主数据库
**状态**：已接受
**日期**：2024-01-15
**作者**：@alice
## 背景
项目需要一个关系型数据库存储用户和订单数据。
需要支持复杂查询、事务和 ACID 保证。
## 评估方案
| 方案 | 优点 | 缺点 |
| --- | --- | --- |
| PostgreSQL | 成熟、ACID、JSON 支持好 | 水平扩展相对难 |
| MySQL | 成熟、生态好 | JSON 支持较弱 |
| MongoDB | 水平扩展容易 | 事务支持弱 |
## 决定
选择 PostgreSQL。
我们的数据强一致性要求高于水平扩展需求。
团队有 PostgreSQL 使用经验。
## 后果
- PostgreSQL 14+ 为标准数据库
- ORM 选用 Prisma
- 分页异常大表考虑分区
## 回顾（可选）
2024-06-01：数据量达到 5亿行时考虑分表
技术方案评审
方案结构模板
## 背景与问题
要解决什么问题？现状是什么？为什么现有方案不第？
## 方案设计
高层级架构图，涉及的组件和数据流
## 方案对比
| | 方案 A | 方案 B |
| --- | --- | --- |
| 开发成本 | | |
| 运维复杂度 | | |
| 性能 | | |
| 风险 | | |
## 风险与应对
列出已识别的技术风险和对应策略
## 技术负債
这个方案引入了哪些技术负債？如何予防管控？
## 上线计划
里程碑、预期排期和回滚方案
## 待讨论事项
- [ ] 问题 1
- [ ] 问题 2
评审中常考察的问题
🤔 技术评审 Checklist
- [ ] **正确性**：方案是否解决了原始问题？
- [ ] **可扩展性**：流量增长 10x 后能应对吗？
- [ ] **可维护性**：新团队成员能看懂并修改吗？
- [ ] **安全性**：是否考虑了认证、授权、数据加密？
- [ ] **容错性**：单点失败会怎样？是否有备用方案？
- [ ] **可观测性**：新系统是否有充分的日志、指标和告警？
- [ ] **回滚方案**：上线失败时如何回滚？
常见误区
- ADR 只记录最终选择，没有记录被否决的方案和原因
- 方案评审大量时间肩对肩对齐关注点，应先异步阅读 + 评论
- 技术方案没有评估风险，高估了新方案的停楽度