name: uncle-bob-craftdescription: “Use when performing code review, writing or refactoring code, or discussing architecture; complements clean-code and does not replace project linter/formatter.”category: code-qualityrisk: safesource: communitydate_added: “2026-03-06”author: antigravity-contributorstags: [clean-code, clean-architecture, solid, code-review, craftsmanship, uncle-bob]tools: [claude, cursor, gemini]Uncle Bob 技艺将 Robert C. MartinUncle Bob的标准应用于代码审查和生产《代码整洁之道》Clean Code、《整洁架构》Clean Architecture、《代码整洁之道程序员的职业素养》The Clean Coder、《敏捷整洁之道》Clean Agile以及设计模式纪律。此技能是对现有clean-code技能聚焦《代码整洁之道》一书和项目 lint/格式化工具的补充——它不替代它们。概述此技能汇集 Uncle Bob 著作中用于审查和编写代码的原则命名与函数通过clean-code、架构与边界整洁架构、职业素养与估算程序员的职业素养、敏捷价值观与实践敏捷整洁之道以及设计模式的正确使用与滥用。用它来评估结构、依赖、SOLID 的上下文应用、代码坏味道和专业实践。它只提供技艺和设计标准——不负责语法或风格强制这些仍由你的 lint 和格式化工具负责。何时使用此技能代码审查应用依赖规则、边界、SOLID 和坏味道启发式提出具体的重构建议。重构决定提取什么、在哪里划定边界以及设计模式是否合理。架构讨论检查层边界、依赖方向和关注点分离。设计模式在引入模式前评估正确使用 vs 跟风或过度使用。估算与职业素养应用《程序员的职业素养》的理念说不、可持续节奏、三点估算。敏捷实践讨论流程时参考《敏捷整洁之道》Iron Cross、TDD、重构、结对编程。不要用它来替代或覆盖项目的 lint、格式化工具或自动化测试。按来源分类的汇总来源重点去哪里代码整洁之道命名、函数、注释、格式、测试、类、坏味道细节使用clean-code此技能在审查/生产中引用它。整洁架构依赖规则、层次、边界、架构中的 SOLID参见 reference.md 和 references/clean-architecture.md。程序员的职业素养职业素养、估算、说不、可持续节奏参见 reference.md 和 references/clean-coder.md。敏捷整洁之道价值观、Iron Cross、TDD、重构、结对编程参见 reference.md 和 references/clean-agile.md。设计模式何时使用、滥用、跟风参见 reference.md 和 references/design-patterns.md。设计模式正确使用 vs 滥用使用模式解决真实的设计问题如行为变化、生命周期或横切关注点时而非为了显得企业级。避免跟风不要因为代码库应该有 Factory/Strategy/Repository 就添加它们当重复或僵化证明抽象合理时才添加。滥用迹象每个类名都带模式名、只做委托而无逻辑的层、让简单代码更难理解的模式。经验法则当你感受到第三次重复或第二个变更原因时引入模式在代码或文档中命名该模式使意图清晰。坏味道与启发式摘要坏味道 / 启发式含义僵化性Rigidity小改动被迫连带大量修改。脆弱性Fragility修改破坏无关区域。顽固性Immobility难以在另一个上下文中复用。粘滞性Viscosity容易做坏事、难做正确的事。不必要的复杂性推测性或不用的抽象。不必要的重复违反 DRY同一想法出现在多处。晦涩性Opacity代码难以理解。完整列表包括 C1–T9 风格的启发式在 reference.md 中。在审查中使用这些来指出问题并建议重构提取、移动依赖、引入边界。审查 vs 生产上下文应用代码审查依赖规则和边界上下文中的 SOLID列出坏味道建议一两个具体重构如提取函数、反转依赖检查测试和职业素养测试存在、无明显压力破解。编写新代码优先小函数和单一职责向内依赖整洁架构做 TDD 时先写测试在重复或变化证明合理之前避免使用模式。重构一次识别一个坏味道以测试保持绿色的小步骤重构在添加行为之前改进命名和结构。工作原理审查代码时边界和依赖规则检查依赖是否向内指向例如用例不依赖 UI 或数据库细节。参见 references/clean-architecture.md。上下文中的 SOLID检查单一职责、开闭、里氏替换、接口隔离、依赖倒置在改动代码上的适用情况。坏味道扫描僵化性、脆弱性、顽固性、粘滞性、不必要的复杂性/重复、晦涩性附文件和区域列出。具体建议提出一两个重构例如“把这提取为名为 X 的函数”、“引入接口使这一层不依赖具体的数据库客户端”。测试和技艺注意测试是否存在以及改动是否尊重可持续节奏没有明显违反职业素养的我们以后再修注释。编写或重构代码时优先小而单一用途的函数和类命名和结构使用clean-code。保持依赖向内指向业务规则在中心适配器在边缘。仅在重复或变化证明合理时引入设计模式。以小步骤重构保持测试绿色。示例示例 1代码审查提示可复制粘贴用这个来请求面向 Uncle Bob 标准的审查请使用 Uncle Bob 技艺标准审查此改动uncle-bob-craft 1. 依赖规则和边界——依赖是否向内指向 2. 上下文中的 SOLID——被改动的代码有无违规 3. 坏味道——列出僵化性、脆弱性、顽固性、粘滞性、不必要的复杂性/重复或晦涩性。 4. 建议一两个具体重构如提取函数、反转依赖。 不要重复 lint/格式检查专注于结构和设计。示例 2重构前后提取并命名重构前晦涩做了不止一件事defprocess(d):ifd.get(t)1:d[x]d[a]*1.1elifd.get(t)2:d[x]d[a]*1.2returnd重构后意图清晰单一抽象层级defapply_discount(amount:float,discount_type:int)-float:ifdiscount_type1:returnamount*1.1ifdiscount_type2:returnamount*1.2returnamountdefprocess(order:dict)-dict:order[x]apply_discount(order[a],order.get(t,0))returnorder最佳实践✅ 命名、函数、注释和格式使用clean-code架构、边界、SOLID、坏味道和流程使用此技能。✅ 审查中说出坏味道或原则的名称例如“依赖规则违规用例从 Web 框架导入”。✅ 每次审查至少建议一个具体重构提取、重命名、反转依赖。✅ 单独运行项目 lint 和格式化工具此技能不替代它们。❌ 不要用此技能强制语法或风格那是 lint 的工作。❌ 没有明确的重复或变化理由就不要添加设计模式。常见陷阱**问题**把每个类都当成需要 Factory 或 Strategy。**解决方案**只有在你确实有设计需求第三次重复、第二个变更轴时才引入模式。**问题**审查只列违反 SOLID而不说明在哪里、如何违反。**解决方案**指出文件和函数以及哪条原则例如“SRP此函数既解析又持久化拆分为 parse 和 persist”。**问题**因为我们应用了 Uncle Bob就跳过项目 lint。**解决方案**此技能关乎技艺和设计始终运行项目的 lint 和格式检查。相关技能clean-code— 详细的《代码整洁之道》书籍材料命名、函数、注释、格式、测试、类、坏味道。日常代码质量用它架构和跨书标准用 uncle-bob-craft。architecture— 通用架构决策和权衡。选择高层结构时使用依赖规则和边界用 uncle-bob-craft。code-review-excellence— 代码审查实践。与 uncle-bob-craft 结合进行基于原则的审查。refactor-clean-code— 面向整洁代码的重构。为边界和 SOLID 重构时与 uncle-bob-craft 一起使用。test-driven-development— TDD 工作流。与《敏捷整洁之道》和《程序员的职业素养》一致测试即需求、可持续节奏。限制不替代项目的 lint 或格式化工具。单独运行 lint 和格式检查此技能只提供设计和技艺标准。不替代自动化测试。它可以提醒你写测试《程序员的职业素养》《敏捷整洁之道》但不运行或生成测试。对工具链是补充。与现有的 CI、lint 和测试套件一起使用。不强制语法或风格。它聚焦结构、依赖、坏味道和专业实践而非花括号风格或行长。是摘要不是原书。完整的代码整洁之道启发式、组件原则REP/CCP/CRP、ADP/SDP/SAP和详细故事都在书中我们引用最常用的部分。参见 reference.md 的范围和出处。