ADR 反模式
ADR 常见的错误方式及评审中如何识别。
为什么
大多数采用 ADR 的团队一年内就放弃，因为记录退化为几种失败模式：散文体（无结构）、事后合理化（代码写完才补 ADR 来辩护）、停车场（永远 Proposed）。命名这些反模式让评审人在 PR 里抓住它们，而非半年后文档已无人信任时才发现腐烂。
何时使用
ADR 评审时参考。无需搭建——只是一个待应用的清单。
如何做
1. 评审时检查这些反模式：
a. "散文体"——没有 Status/Date/Context 头，只有散文 → 拒，要求用模板
b. "事后"——Context 描述已存在的代码，而非驱动决策的作用力
→ 拒，要求写决策前的上下文
c. "停车场"——Status=Proposed 超 2 周无评审推进
→ 提醒作者或关闭
d. "备忘录"——决策靠命令下达，无备选 → 拒，要求至少一个被否决的备选
e. "水晶球"——Consequences 只列正面 → 拒，要求列负面
2. 把这些检查加到 adr lint 配置，让 CI 自动抓
3. 在新人入职时分享反模式清单，让他们学会正确的形状示例
被拒 ADR（反模式："备忘录"）： # 0014. 用 gRPC - Status: Accepted - Decision: 我们将用 gRPC 做所有内部通信。 （无 Context、无备选、无 Consequences——纯命令） 评审人："这是'备忘录'反模式。什么作用力让 gRPC 优于 REST/GraphQL？采用后会坏什么？请加 Context， 至少一个被否决的备选，以及 Consequences 字段。"
常见问题
- ⚠把反模式清单当门禁而非辅导——只拒不教改法会滋生怨气；永远展示修正后的形状。
最佳实践
- ✓反模式清单保持 5 条——太多评审人就不再全查。
- ✓抓到反模式时，给作者链接一条好的 ADR 范例，让他们模式匹配而非读规则。
- ✓追踪哪种反模式最多；若'事后'占主导，说明流程逼 ADR 写得太晚——把它移到设计流程更早。