Back to Details

code-refactoring-small

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Refactoring: Keep Code Small

代码重构：保持代码精简

Refactor overly large code you just added or extended into smaller, more focused components.
将你刚添加或扩展的过于庞大的代码重构为更小、更专注的组件。

When to Use This Skill

何时使用该技能

Use this skill when:
  • Functions or methods are too long (typically >50 lines)
  • Classes have too many responsibilities
  • Files have grown too large or handle multiple concerns
  • Code has deeply nested blocks
  • After implementing a feature and noticing bloat
在以下场景使用此技能：
  • 函数或方法过长（通常超过50行）
  • 类承担了过多职责
  • 文件变得过于庞大或处理多个关注点
  • 代码存在深度嵌套的代码块
  • 实现功能后发现代码冗余膨胀

Critical Rule: Refactor As You Go

关键规则：边写边重构

When adding new logic to an existing function, ALWAYS check whether the function is already long. If it is, extract a new method/function for the new logic rather than inlining it. Do NOT bloat existing functions further — refactoring is not a separate step to do later; it must happen at the time of writing.
This applies even when the new code is "just" 20-30 lines. Adding 30 lines to a 100-line function makes it a 130-line function that now needs refactoring. The correct approach is to never let it get that far.
当向现有函数添加新逻辑时，务必检查该函数是否已经过长。 如果已经过长，应为新逻辑提取一个新的方法/函数，而不是直接内联到原有函数中。切勿让现有函数进一步膨胀——重构不是后续单独进行的步骤，必须在编写代码时同步进行。
即使新增代码“仅”20-30行也应遵循此规则。向100行的函数中添加30行代码会使其变成130行的函数，后续仍需重构。正确的做法是从一开始就避免这种情况发生。

Instructions

操作步骤

Step 1: Identify the Bloat

步骤1：识别冗余膨胀

Review your recent changes (committed or uncommitted) to find:
  • Functions or methods that are too long
  • Classes that have too many responsibilities
  • Files that have grown too large
  • Deeply nested code blocks
  • New logic inlined into already-long functions (this is the most common mistake — catch it early)
查看你最近的修改（已提交或未提交的），找出：
  • 过长的函数或方法
  • 承担过多职责的类
  • 过于庞大的文件
  • 深度嵌套的代码块
  • 直接内联到已过长函数中的新逻辑（这是最常见的错误——尽早发现）

Step 2: Clarify Scope (If Needed)

步骤2：明确范围（如有需要）

If the bloat is not obvious, ask the user to clarify which specific code units they want refactored before proceeding.
如果冗余膨胀的情况不明确，请先让用户明确他们希望重构哪些具体的代码单元，再继续操作。

Step 3: Refactor

步骤3：执行重构

Once the bloat is identified:
  • Extract logical sub-operations into separate functions/methods
  • Split large classes following Single Responsibility Principle
  • Move related functionality into separate modules/files
  • Reduce nesting levels by extracting guard clauses or helper functions
  • Ensure each unit does one thing well (UNIX Philosophy)
  • Deduplicate repeated structures (e.g. lookup tables defined in multiple places should become shared constants)
一旦确定了冗余膨胀的部分：
  • 将逻辑子操作提取为单独的函数/方法
  • 遵循单一职责原则拆分大型类
  • 将相关功能移至单独的模块/文件中
  • 通过提取保护子句或辅助函数来减少嵌套层级
  • 确保每个单元只做好一件事（UNIX哲学）
  • 去重重复结构（例如，在多个地方定义的查找表应改为共享常量）

Step 4: Verify

步骤4：验证

After refactoring:
  • Run linters and tests if available
  • Verify the code still works as expected
  • Check that the solution is clearer and more maintainable
  • Ensure the refactoring improved readability
重构完成后：
  • 如果有可用的代码检查工具和测试，运行它们
  • 验证代码仍能按预期工作
  • 确认解决方案更清晰、更易于维护
  • 确保重构提升了代码的可读性

Goal

目标

Break down large, complex code units into smaller, focused components that are:
  • Easier to understand
  • Easier to test
  • Easier to maintain
Each function, class, or file should have a clear, single purpose.
将庞大、复杂的代码单元拆分为更小、专注的组件，使其：
  • 更易于理解
  • 更易于测试
  • 更易于维护
每个函数、类或文件都应具有明确的单一用途。