其他
编写或维护 Ruby 3.x 应用时，用惯用风格…
适用于 Ruby 3.x 项目开发与代码审查，需要遵循惯用风格、RSpec 测试和现代最佳实践时。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 35/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 38/100 ×0.15
适用场景
编写或维护 Ruby 3.x 应用时，用特定
解决思路
- 编写简洁、符合 Ruby 习惯（idiomatic）的代码，并提供准确示例。
- 遵循 Ruby 社区约定和风格指南。
- 文件、方法和变量使用 snake_case。
- 类和模块使用 CamelCase。
- 优先使用描述性名称，例如 `user_signed_in?` 和 `calculate_total`。
- 利用 Ruby 3.x 能力：使用 `case/in` 进行模式匹配。
- 利用 Ruby 3.x 能力：对简单单行逻辑使用 endless methods（无限方法定义）。
- 利用 Ruby 3.x 能力：为清晰性使用 keyword arguments（关键字参数）。
- 利用 Ruby 3.x 能力：使用安全导航操作符（`&.`）。
- 有效使用 blocks、procs 和 lambdas。
- 审慎使用元编程。
- 遵循 Ruby Style Guide。
- 采用有表现力的语法特性。
- 除需要字符串插值外，优先使用单引号。
- 使用方法名和变量名要表达清晰含义。
- 保持方法短小且聚焦（单一职责原则）。
- 仅在真正的边界情况使用异常。
- 实现恰当的日志记录，并使用对用户友好的消息。
- 为领域特定错误使用自定义异常类。
- 用合适的 `rescue` 块优雅处理错误。
- 遵循 SOLID 原则。
- 优先使用组合而非继承。
- 使用模块实现共享行为（mixins）。
- 保持类聚焦且内聚。
- 为典型情况、边界情况和错误条件编写全面覆盖的测试。
- 为测试块使用清晰、描述性的命名约定。
- 用 `describe` 组织类/方法，用 `context` 组织场景，保持逻辑组织清晰。
- 使用 `let` 和 factories（FactoryBot）而不是 fixtures。
- 确保测试独立，尽量减少共享状态。
- 策略性地 mock 外部服务，同时在可行时测试真实行为。
- 按如下结构组织 RSpec 测试：`describe ClassName do` 下用 `describe '#method_name' do`，再按场景使用 `context 'when condition exists' do`，其中用 `it 'does expected behavior' do` 和 `expect(result).to eq(expected)` 表达期望。
- 在优化前先剖析（profile）代码。
- 使用合适的数据结构。
- 对大型集合使用惰性枚举器（lazy enumerators）。
- 缓存昂贵的计算。
- 对用户输入进行清洗（sanitize）。
- 使用参数化查询。
- 保持依赖更新。
- 遵循处理敏感数据的安全最佳实践。
适用边界 · 注意事项
- 不是 Ruby 项目，或使用 Ruby 2.x 及更早版本时，本技能中的 Ruby 3.x 特性（如 `case/in`、endless methods）不适用。
- 项目使用 Minitest 或其他测试框架而非 RSpec/FactoryBot 时，测试部分不能直接照搬，应转换为对应框架写法。
- 团队已有强制风格指南且与 Ruby Style Guide 冲突时，以团队规范为准。