代码坏味道

Martin Fowler 把 代码坏味道（Code Smell） 定义为：不一定会 bug，但暗示设计有问题、改动成本偏高。识别 smell 不是为批评作者，而是为 选对重构时机与手法。

学习目标

• 识别长方法、重复代码、过大类等常见坏味道
• 能将 smell 映射到具体重构策略
• 结合 cq-refactoring 小步改善

长方法（Long Method）

信号：一个方法超过一屏、多层缩进、注释写「第一步…第二步…」。

风险：难以单测、难以理解、改一处牵动全局。

对策：Extract Method；保留方法名表达业务步骤。Controller 里若塞满校验与组装，应对照 spring-boot-essentials 下沉到 Service。

重复代码（Duplicated Code）

信号：复制粘贴、仅变量名不同的三份校验。

风险：修 bug 漏改一处；行为逐渐分叉。

对策：提取函数/基类/工具类；重复的是 业务规则 时优先抽 Domain 方法而非 StringUtils。Review 时用 cq-reviews 清单里的「重复」项。

过大类（Large Class）

信号：一个类几百行、字段十几個、改任何需求都要动它。

风险：违反单一职责；测试需 mock 半个系统。

对策：按职责拆类（如 ReadService / WriteService）；配合 testing-essentials 为拆分后的小类写单元测试。

其他常见 smell（速览）

Smell	简要对策
过长参数列	引入参数对象
发散式变化	拆类，各管一种变化原因
依恋情结	搬移方法到更合适的类
注释过多	先改善命名，注释只留非 obvious 业务

AI 生成代码易 重复模板 与 巨型方法，用 ai-coding-essentials 审查时专门扫 smell。

练习

• 在 platform 或 backend 标出 1 处长方法，写出可提取的 2 个子方法名
• 用 grep 或 IDE 找同一字符串出现 ≥3 次的校验逻辑
• 选一个过大类，列出它承担的 3 种以上「变化原因」

小结

坏味道是重构的导航标，不是羞耻标签。 下一课谈文档：如何让 README 与 API 说明减轻「读代码才能懂」的负担。