---

name: uncle-bob-craft description: "在进行代码审查、编写或重构代码或讨论架构时使用；补充 clean-code 且不替代项目的 linter/formatter。" category: code-quality risk: safe source: community date_added: "2026-03-06" author: antigravity-contributors tags: [clean-code, clean-architecture, solid, code-review, craftsmanship, uncle-bob] tools: [claude, cursor, gemini]

Uncle Bob 工匠精神

应用 Robert C. Martin（Uncle Bob）的代码审查和生产标准：《代码整洁之道》、《架构整洁之道》、《程序员的职业素养》、《敏捷整洁之道》和设计模式纪律。此技能补充现有的 @clean-code 技能（专注于《代码整洁之道》一书）和你项目的 linter/formatter——不替代它们。

概述

此技能汇集了 Uncle Bob 著作中用于审查和编写代码的原则：命名和函数（通过 @clean-code）、架构和边界（架构整洁之道）、专业精神和估算（程序员的职业素养）、敏捷价值观和实践（敏捷整洁之道），以及设计模式的使用与误用。用它来评估结构、依赖关系、上下文中的 SOLID、代码异味和专业实践。它仅提供工艺和设计标准——不提供语法或风格强制，这些仍由你的 linter 和 formatter 负责。

何时使用此技能

• 代码审查：应用依赖规则、边界、SOLID 和异味启发式；建议具体重构。
• 重构：决定提取什么、在哪里划定边界，以及设计模式是否合理。
• 架构讨论：检查层边界、依赖方向和关注点分离。
• 设计模式：在引入模式之前评估正确使用 vs 货物崇拜或过度使用。
• 估算和专业精神：应用《程序员的职业素养》理念（说不、可持续节奏、三点估算）。
• 敏捷实践：讨论流程时引用《敏捷整洁之道》（铁十字、TDD、重构、结对编程）。
• 不要使用来替代或覆盖项目的 linter、formatter 或自动化测试。

按来源汇总

| 来源 | 重点 | 去哪里 | |--------|--------|-------------| | 代码整洁之道 | 命名、函数、注释、格式、测试、类、异味 | 使用 @clean-code 获取详情；此技能引用它用于审查/生产。 | | 架构整洁之道 | 依赖规则、层、边界、架构中的 SOLID | 参见 reference.md 和 references/clean-architecture.md。 | | 程序员的职业素养 | 专业精神、估算、说不、可持续节奏 | 参见 reference.md 和 references/clean-coder.md。 | | 敏捷整洁之道 | 价值观、铁十字、TDD、重构、结对编程 | 参见 reference.md 和 references/clean-agile.md。 | | 设计模式 | 何时使用、误用、货物崇拜 | 参见 reference.md 和 references/design-patterns.md。 |

设计模式：使用 vs 误用

• 使用模式当它们解决真实的设计问题（如行为变化、生命周期或横切关注点），而非为了看起来"企业级"。
• 避免货物崇拜：不要仅因为代码库"应该"有 Factory/Strategy/Repository 就添加它们；当重复或僵化证明抽象合理时才添加。
• 误用迹象：每个类名中都有模式名称、仅委托而无逻辑的层、使简单代码更难理解的模式。
• 经验法则：当你感到第三次重复或第二个变更原因时引入模式；在代码或文档中命名模式以明确意图。

异味和启发式（摘要）

| 异味/启发式 | 含义 | |-------------------|--------| | 僵化性 | 小变更迫使许多编辑。 | | 脆弱性 | 变更破坏不相关的区域。 | | 不可移动性 | 无法在其他地方重用模块。 | | 粘滞性 | 做正确的事比做错误的事更难。 | | 不必要的复杂性 | 为未来需求过度设计。 | | 不必要的重复 | 违反 DRY。 | | 不透明性 | 代码难以理解。 |

SOLID 原则快速参考

| 原则 | 含义 | 违反信号 | |--------|--------|-------------| | S - 单一职责 | 一个类只有一个变更原因 | 类做太多事情 | | O - 开闭原则 | 对扩展开放，对修改关闭 | 每次新需求都修改现有代码 | | L - 里氏替换 | 子类型必须可替换基类型 | 子类覆盖后行为不一致 | | I - 接口隔离 | 客户端不应依赖不使用的方法 | 胖接口迫使空实现 | | D - 依赖倒置 | 高层不依赖低层，都依赖抽象 | 业务逻辑直接导入数据库驱动 |

依赖规则

依赖只能向内指向。外层（框架、UI、数据库）依赖内层（用例、实体），反之不可。

限制

• 仅在任务明确匹配上述范围时使用此技能。
• 不要将输出视为环境特定验证、测试或专家审查的替代品。
• 如果缺少所需的输入、权限、安全边界或成功标准，请停下来寻求澄清。