Clean Code 审查清单

要解决的问题

• 代码评审常停在“能跑”，但命名含糊、函数过长、嵌套过深、魔法数字、注释解释 what、多文件改动破坏依赖等问题持续积累。
• 该技能把 Clean Code 原则转成可检查清单，避免只靠经验判断，让审查和自测有统一标准。

技能如何工作

• 原则层：围绕 SRP、DRY、KISS、YAGNI 和 Boy Scout Rule，判断每个函数或类是否只做一件事，是否重复，是否过度设计。
• 命名层：检查变量、函数、布尔值、常量、类和枚举是否表达意图，替代 tmp、data、flag 这类弱命名。
• 函数层：关注长度、参数数量、抽象层级和副作用，优先用 guard clauses、early returns 和 options object 降低嵌套与调用复杂度。
• 结构层：识别 God functions、utils.ts 垃圾抽屉、premature abstraction、copy-paste、stringly-typed、callback hell 等反模式，并用提取函数、组合、discriminated unions 等修正。
• 改前安全层：修改文件前检查谁导入它、它导入谁、哪些测试覆盖、是否共享组件，尽量在同一任务中同步更新依赖、测试和类型。
• 完成前自测：核对目标是否达成、文件是否完整、编译是否通过、lint 或 type checks 是否干净、是否遗漏边界情况。

适用边界与注意点

• 适合代码审查、重构、多文件变更和 AI 辅助编程时的质量约束。
• 它是规则清单，不替代架构设计、领域建模或性能 profiling。
• 对“20 行以内”“最多 3 参数”等硬规则要结合团队规范理解；若业务逻辑必须复杂，应优先考虑拆分与命名，而不是一味机械拆分。
• 资料中的 references 提到 Anti-Patterns、Code Smells、Refactoring Catalog，可作为后续深入方向。