Uncle Bob 技艺 —— 代码审查检查清单
使用 uncle-bob-craft 技能进行基于原则的代码审查时，复制粘贴此检查清单。单独运行你的项目 lint/格式化工具；此检查清单聚焦结构和设计。
1. 依赖规则和边界
- 依赖指向向内（用例/领域不依赖 UI、DB 或框架细节）。
- 外层依赖由内层定义的接口（如仓库、网关）。
- 被审查的核心/用例代码中没有直接导入框架或驱动。
2. 上下文中的 SOLID
- SRP—— 每个类/模块只有一个变更理由（一个参与者）。
- OCP—— 通过新实现扩展，而非编辑现有核心逻辑。
- LSP—— 子类型可替换；无对具体类型的隐藏假设。
- ISP—— 接口聚焦；调用者不依赖它们不用的方法。
- DIP—— 高层代码依赖抽象；具体实现在边缘注入。
3. 坏味道
- 僵化性—— 小改动不强制修改多处。
- 脆弱性—— 变更不破坏无关区域。
- 顽固性—— 在合理处可以复用。
- 粘滞性—— 做正确的事不比走捷径更难。
- 不必要的复杂性—— 无推测性或未使用的抽象。
- 不必要的重复—— DRY；无明显的重复。
- 晦涩性—— 命名和结构使意图清晰。
4. 设计模式
- 使用的任何模式都有清晰的理由（重复、变化或边界）。
- 无跟风模式（例如单一实现且无变化计划的 Factory）。
- 模式提高可读性或可测试性，而非相反。
5. 测试与职业素养
- 被改动的代码有或在适当处被测试覆盖。
- 无明显违反可持续节奏或质量的"我们以后再修"或"TODO：重构"。
- 提交/PR 连贯，不让代码库变得更糟。
建议的审查输出格式
- 边界：一两句关于依赖方向及任何违规。
- SOLID：列出任何违规并附文件/函数和原则（例如，“SRP：
OrderService既解析又持久化——拆分。”）。 - 坏味道：列出发现的坏味道并附位置（例如，“僵化性：修改折扣规则触及 4 个文件。”）。
- 具体重构：一两个具体建议（例如，“从
process中提取applyDiscount”；“引入OrderRepository接口并在用例中注入。”）。 - 测试 / 职业素养：简要说明测试覆盖情况和任何担忧。
与技能一起使用：@uncle-bob-craft。命名、函数和格式细节，也使用 @clean-code。始终单独运行项目的 lint 和格式化工具。
