设计原则评审清单是什么
把抽象原则翻译成评审时可以逐条回答的问题：依赖方向指向哪里？新增一个同类能力要改几处？有没有为假想需求预留的机制？模块内是否只讲同一层次的事？清单的目的不是给出统一答案，而是让权衡过程显式化——原则之间经常冲突（例如 DRY 与 KISS），把取舍写下来比争论谁对更有效。
基本信息
| 用途 | 评审与设计讨论中的提问工具 |
|---|---|
| 产出 | 写进 PR 描述或 ADR 的取舍说明 |
| 原则 | 不求答案一致，要求判断显式 |
| 配套 | 与 SOLID 自检清单、重构评审要点一起用 |
评审十问（摘）
- 依赖方向：核心模块是否 import 了框架或存储细节？
- 扩展性：新增一个同类实现要碰哪些文件？
- YAGNI：哪个机制目前无人使用？
- 组合与继承：继承是否只为复用代码？
- 封装：外部能绕过校验改内部状态吗？
- 兼容：这个变更对调用方是破坏性的吗？
- 抽象层次：同一函数里是否混着高层编排与底层细节？
评审提问模板
评审提问模板
1. 依赖方向：核心是否 import 了框架/存储细节？
2. 扩展性：新增一个同类实现要碰哪些文件？
3. YAGNI：哪个机制目前无人使用？
4. 组合/继承：继承是否只为复用？
5. 封装：外部能绕过校验改内部状态吗？
6. 兼容：这个变更对调用方是破坏性的吗？
# 结论句式：本 PR 选择 A 而不是 B，因为……
#（把取舍写进描述，下次同类讨论可直接引用）原则与对应提问
| 原则 | 提问 | 典型处理 |
|---|---|---|
| 依赖倒置 | 业务层是否直接依赖框架类型？ | 内层定义接口，外层实现 |
| 开闭原则 | 新增实现要改多少既有代码？ | 引入显式注册点 |
| YAGNI | 这个抽象当前有第二个使用者吗？ | 先内联，等变化出现再抽 |
| 抽象层次一致 | 同一函数是否混着不同层次？ | 提炼低层细节为命名函数 |
清单的目标是让权衡过程可讨论：原则冲突时（如 DRY 与 KISS），把取舍写在 PR 描述里，比在评审里反复争论更省时间。
问题要问在具体处：问「这里是否有设计问题」没人能回答；问「新增一个 CSV 导出要改几处」立刻有唯一答案，讨论也就能推进。