代码梳理自查

解决什么结构问题

在日常开发中，我们常会遇到一种奇怪的代码状态：功能没坏，测试也过，但读起来总觉得「臃肿却说不出哪里不对」。常见的病因包括：只有一行转发的冗余中间层、散落在调用方实例上的游离状态、以及一个函数里硬塞了三层业务逻辑的「上帝函数」。主流的 lint 工具或代码审查通常关注语法或命名，对这类深层的架构腐化无能为力。code-groom 正是为了填补这一空白而设计的结构化自查框架。

核心工作流与原则

该技能将代码重构拆解为一套可执行的排查清单，分为影响范围扫描、原则判断与实操规则三个阶段。

• 扫描影响范围：动手前，先在改动触及的文件及其直接调用方/被调方内排查依赖关系，包括「谁持有谁调用」「谁监听谁发射」，并清理未使用的 import 或 require 以及仅内部使用的导出符号。
• 过五条判断原则：逐行审视当前改动的文件，判断是否违反了单一数据源（值被重复声明）、单层抽象（函数包含多层级步骤）、封装（内部状态暴露或散落）、消冗余（无效透传或单行转发）以及状态找主人（生命周期未收口到正确的单元）。
• 过七条操作规则：在确定需要修改后，执行具体的重构手法，如删除死代码（R2）、内联纯转发层（R3）、将仅内部使用的出口收进消费端（R4），以及合并职责重叠的小文件（R6）等。

适用边界与注意点

需要注意的是，code-groom 并非全局扫描工具。它仅在明确触发时运行（如用户要求梳理代码、groom 或进行交付前自查），默认不扫描全库，只关注本次改动的波及范围。

此外，在执行「消冗余」和「出口收进消费端」等规则时，必须严格区分内部实现与对外导出的公共 API。对于属于公共契约的接口或符号，即使引用数仅为 1，也必须予以保留，以免破坏外部依赖。