软件项目开发全流程 · 第 11 课 · 技术选型与 ADR：把决策写下来
1、技术选型翻车的三种典型
第一种：被"新技术光环"带走。
看到一个博主说某框架"又快又酷"，团队一拍脑袋就上了。三个月后发现：文档稀烂、生态缺失、招不到人、出了 bug 只能自己啃源码。
第二种：用最熟的工具硬套所有问题。
"我就只会 MySQL"，于是把时序数据、全文检索、图关系全塞进 MySQL。能跑，但代价是性能和可维护性。
第三种：决策只存在某个人脑子里。
半年后他离职了，新来的问"为什么用了两个消息队列？"——没人答得上来。
本课解决：怎么系统地做选型决策，并把它变成团队可追溯的记录（ADR）。
2、选型维度清单
给候选方案打分，至少覆盖这 8 个维度：
| 维度 | 要问的问题 |
|---|---|
| 匹配度 | 它解决的问题和我们的问题是不是同一类？ |
| 成熟度 | 版本号到 1.0 了吗？有生产案例吗？ |
| 社区与生态 | GitHub 活跃度？文档质量？第三方集成多吗？ |
| 团队熟悉度 | 团队会用吗？学习成本多大？招得到人吗？ |
| 性能与规模 | 压力测试数据如何？能扛我们 3 年后的量吗？ |
| 运维成本 | 要不要专职运维？备份/监控/升级麻烦吗？ |
| 许可与合规 | 开源协议（MIT/Apache/GPL）能否商用？有法律风险吗？ |
| 退出成本 | 将来想换掉它，代价多大？（这条最常被忽略） |
"退出成本"要单独考虑：一个容易替换的技术，即使不是最优也能接受；一个深度绑定、无法抽身的技术，即使现在很香也要慎重。
打分法：每个维度 1~5 分，加权求和，但最终决策不能只看总分——某一维度"必须满足"（gate）时，一票否决。
3、技术雷达
技术雷达（Technology Radar） 用来管理团队对技术的态度，通常分四环：
┌──────── 采纳（Adopt）：已验证，默认选择
│ ┌──── 试验（Trial）：小范围项目可用，值得投入
│ │ ┌── 评估（Assess）：值得研究，可做 PoC
│ │ │ ┌ 暂缓（Hold）：不要在新项目用
● ● ● ●规则：
- 新项目默认从"采纳"里选，除非有新需求。
- "试验"里的技术最多同时用 1~2 个，用一个真实但非核心的项目去养。
- 引入新技术的唯一正当理由是"现有技术解决不了/成本过高"，不是"新技术更酷"。
雷达要定期更新（如每季度），并记录每个技术的环位变化与原因。
4、ADR：把决策写下来
ADR（Architecture Decision Record，架构决策记录） 是轻量、可版本化的决策文档。一个决策一个文件，永久留存。
标准模板：
# ADR-0007：使用 PostgreSQL 作为主数据库
- 状态：已采纳（2026-09-28）
- 决策者：架构组 + 后端负责人
- 关联：ADR-0003（模块化单体）、需求 R-012（并发 500）
## 背景（Context）
任务清单需要事务支持、复杂关联查询，同时要支持任务标签的模糊检索。
预计 3 年内数据量 5000 万行，写入 QPS 峰值 200。
## 决策（Decision）
采用 PostgreSQL 16 作为唯一主数据库，标签检索先用 LIKE（数据量小时），
预留 pgvector / 全文索引作为演进路径。
## 备选方案（Alternatives）
- MySQL 8：团队更熟，但全文检索、JSONB、扩展能力较弱 → 否
- MongoDB：灵活但多表关联与强事务不符合本项目 → 否
- 同时引入 Elasticsearch：当前检索量级不需要，运维成本高 → 暂缓
## 后果（Consequences）
+ 事务与关联查询能力强，一套技术栈覆盖主业务
+ 团队熟悉，运维简单
− 写入扩展依赖分库分表，需在 ADR-0011 中规划
− 检索性能需监控，超过阈值时启动全文索引方案
## 复查条件（Review Trigger）
数据量 > 2000 万行，或检索 P95 > 1s 时重新评估。ADR 的四条纪律：
- 一个决策一个文件，编号连续，放进版本库。
- 状态要更新：提议 → 已采纳 → 已废弃 / 被替代（不要删旧 ADR，它记录了当时的判断）。
- 写清"备选方案与反选理由"——这是 ADR 最有价值的部分。
- 写复查条件：什么情况下这个决策该重新审视。
5、验证：Spike 与 PoC
选中一个方案后，不要直接全面开建。先用小成本验证风险最高的假设：
| 方式 | 目的 | 时间盒 |
|---|---|---|
| Spike（技术探针） | 验证"能不能做到"（可行性） | 1~3 天 |
| PoC（概念验证） | 验证"做出来效果如何"（性能/体验） | 1~2 周 |
| 原型（Prototype） | 验证"用户会不会用"（第 8 课） | 数小时~数天 |
Spike 的纪律：
- 时间盒（Timebox）：规定时间内没结论就停，写清"卡在哪"。
- 产物明确：一段可运行的代码 + 一份结论（可行/不可行/有条件可行）。
- Spike 代码可以扔：它的目的是获取知识，不是交付功能——别把探针代码直接当生产代码用。
一次真实的选型验证应该回答：
- 在目标数据量下，关键查询的实际耗时是多少？
- 我们的团队能在几天内跑通最小用例？
- 出问题时，社区/文档/商业支持能帮上忙吗？
6、什么时候该用"最无聊的技术"
"最无聊的技术"（Boring Technology） 指那些成熟、稳定、大家都知道怎么用的技术。它几乎总是新项目的正确默认值。
原因有三：
- 你的创新预算有限（很多人说不清上限，但一定有）。把创新花在业务差异化上，别花在基础设施上。
- 成熟技术的坑已经被踩过了，文档、Stack Overflow、运维经验都齐。
- 出故障时能快速恢复，因为有人懂。
判断口诀：
能带来竞争优势的地方，大胆用新的；只是支撑性的地方，用最无聊的。
7、动手实验 🎯
任务：为一个真实选型问题走完完整流程。
- 选一个你项目里真实的技术决策（如"缓存用 Redis 还是本地内存"、"前端用 Vue 还是 React"、"消息队列选型"）。
- 用 8 维清单给 2~3 个候选方案打分，标出哪些维度是一票否决项。
- 为你的项目写一份 技术雷达（四环各放 2~3 个技术），说明环位理由。
- 写一份完整 ADR（用上面模板），重点写清"备选方案 + 反选理由 + 复查条件"。
- 设计一个 1~3 天的 Spike：写清要验证的假设、成功标准、时间盒、预期产物。
- 回顾你项目里已经存在的技术，挑一个反问自己："如果今天重选，还会选它吗？为什么？"
做完这步，你不仅做了一次决策，还留下了能被团队复用、能被未来复查的决策资产。
8、今天你带走的三句话
- 选型比 8 个维度，但"退出成本"最容易被忘——难以替换的技术要格外慎重。
- ADR 的价值不在结论，而在"备选方案 + 反选理由 + 复查条件"，它是团队的决策记忆。
- 用最无聊的技术做支撑，把创新预算留给业务差异化；动手前先用 Spike 验证最大风险。
第二阶段（需求与设计）到这里结束。我们已经把"想要"变成了有验收标准的需求、有界面的设计、有边界的架构、有依据的数据与选型。
下一阶段进入开发与团队协作——从第 12 课开始的 Git 与版本控制，把一个想法真正变成可协作的代码。