sandi-metz-rules

Sandi Metz 规则

概述

此技能帮助将 Sandi Metz 的四条规则应用于 Ruby 代码库，以编写易于维护的面向对象代码。这些规则是用于鼓励良好设计实践的启发式原则，能让代码更易于理解、测试和维护。

四条规则

1. 类的代码行数不得超过 100 行
2. 方法的代码行数不得超过 5 行
3. 传入方法的参数不得超过 4 个
4. 控制器只能实例化一个对象

何时使用此技能

在以下情况下应用此技能：

• 用户明确要求应用 Sandi Metz 的规则
• 审查 Ruby 代码的可维护性和代码质量
• 重构现有 Ruby 代码以改进设计
• 用户询问“代码异味”或如何改进面向对象设计
• 分析 Ruby 代码的复杂度或可维护性问题
• 用户提到“POODR”或引用 Sandi Metz 的作品

代码审查工作流

1. 分析代码

根据 Sandi Metz 的规则审查代码时：

阅读参考文档： 首先，加载详细的规则文档：

Read references/rules.md

准确测量：

• 对于类：统计实际代码行数（不包括空行、注释、类定义和 end 语句）
• 对于方法：统计实际代码行数（不包括空行、注释、方法定义和 end 语句）
• 对于参数：统计所有显式参数，包括关键字参数（但不包括 &block）
• 对于控制器：统计每个操作中的对象实例化次数（不包括查找现有对象）

识别违规： 扫描代码库，查找违反各项规则的情况。使用 grep 或文件搜索查找类和方法，然后系统地进行分析。

2. 确定问题优先级

违规情况的严重程度各不相同：

高优先级：

• 超过 200 行的类（严重违规）
• 超过 10 行的方法（严重违规）
• 参数不少于 6 个的方法
• 包含复杂业务逻辑的控制器

中优先级：

• 100 至 200 行的类
• 5 至 10 行的方法
• 有 5 个参数的方法

低优先级：

• 临界情况（例如，6 行的方法）
• 测试文件、配置文件或 DSL 中的违规

3. 提出具体的重构方案

针对每项违规，提供切实可行的重构策略：

过长的类：

• 将相关方法提取到新类中
• 使用单一职责原则识别不同的职责
• 使用组合或模块共享行为
• 应用这些模式：Strategy、Decorator、Command、Facade

过长的方法：

• 提取子方法，并为其使用描述性名称
• 用多态替换条件语句
• 使用卫语句减少嵌套
• 应用 Composed Method 模式（让方法保持在同一抽象层级）
• 将复杂表达式提取为命名清晰的方法

参数过多：

• 为相关参数引入 Parameter Object
• 对复杂的对象构造使用 Builder 模式
• 用方法调用替换参数（使用实例变量）
• 考虑该方法是否应该属于其他类

臃肿的控制器：

• 提取服务对象或使用用例
• 应用 Command 或 Interactor 模式
• 为复杂的流程编排创建 Facade 对象
• 将业务逻辑移至领域层

4. 提供代码示例

提出重构建议时：

• 展示重构前后的代码示例
• 说明重构后的版本为何更好
• 为所用模式命名
• 强调这些更改如何提升可测试性和清晰度

5. 考虑上下文

请记住，有充分理由时可以打破规则：

• 配置文件（例如，routes.rb）
• 测试文件（但仍应保持可读性）
• DSL 定义
• 生成的代码或数据库迁移
• 遵循规则反而会降低代码清晰度时

如果某项违规可能可以接受，请务必指出并说明原因。

使用模式

模式 1：完整代码库审查

审查整个代码库时：

1. 使用 glob 模式搜索 Ruby 文件
2. 优先识别最大的类和方法
3. 检查控制器中是否包含业务逻辑
4. 按严重程度排列违规项的优先级
5. 总结发现的问题，并提供具体的文件位置和行号
6. 针对最严重的问题提出重构建议

模式 2：特定文件或类审查

审查特定文件时：

1. 加载文件
2. 衡量每个类和方法
3. 识别所有违反规则的情况
4. 提供具体的重构建议和代码示例
5. 说明每项建议修改的益处

模式 3：重构协助

主动重构代码时：

1. 加载 references/rules.md，获取详细指导
2. 应用参考文档中的具体重构模式
3. 确保重构后的代码遵循全部四条规则
4. 验证测试仍能通过
5. 说明所做的设计改进

代码计数规则

请遵循以下精确的计数规则，以确保一致性：

类的行数：

class MyClass  # Don't count
  def method   # Count: 1
    body       # Count: 2
  end          # Don't count
end            # Don't count

方法的行数：

def my_method        # Don't count
  line_1             # Count: 1
  line_2             # Count: 2
                     # Don't count (blank line)
  # comment          # Don't count
  line_3             # Count: 3
end                  # Don't count

参数：

def method(a, b, c, d)              # 4 parameters - OK
def method(a, b, c, d, e)           # 5 parameters - Violation
def method(a:, b:, c:, d:)          # 4 parameters - OK
def method(a, b = nil, c = {})      # 3 parameters - OK (defaults still count)
def method(a, *rest)                # 2 parameters - OK
def method(a, &block)               # 1 parameter (blocks don't count)

自动化

建议使用静态分析工具来强制执行这些规则：

• RuboCop： 配置 Metrics/MethodLength、Metrics/ClassLength、Metrics/ParameterLists
• Reek： 检测 LongMethod、LargeClass、LongParameterList 等代码异味
• flog： 衡量方法复杂度
• flay： 检测代码重复

RuboCop 配置示例：

Metrics/ClassLength:
  Max: 100

Metrics/MethodLength:
  Max: 5

Metrics/ParameterLists:
  Max: 4
  MaxOptionalParameters: 3

资源

此技能包含一份全面的参考文档，其中包括：

• 对每条规则的详细说明
• 原理和益处
• 常见违规情况及其原因
• 附示例的具体重构策略
• 何时可以不遵循规则的指导
• 相关设计原则和模式

进行详细的代码分析或解释重构方法时，请加载此参考文档：

Read references/rules.md