【代码坏味道】无用物Dispensables

💬 Comments（注释过多）

🧾 症状

• 方法中充满了解释性注释。

🧠 问题原因

• 作者意识到代码不易懂，靠注释来“掩盖”结构不清的问题。

🛠️ 应对方法

• 用好名字代替注释：好名字胜过好注释
• 用 提取变量 拆解复杂表达式。
• 用 提取方法 将代码块抽出来，方法名直接体现注释内容。
• 如果方法名仍不够清晰，使用 重命名方法。
• 需要说明状态约束时，使用 引入断言。

✅ 收益

• 代码更加直观清晰，无需依赖注释也能懂。

---

🔁 Duplicate Code（重复代码）

🧾 症状

• 两段代码看起来几乎一样。

🧠 问题原因

• 程序员之间没沟通好，重复造轮子；
• 或者赶工时复制粘贴了代码。

🛠️ 应对方法

场景	处理方法
同一个类中多个方法重复	提取方法
同层级两个子类中重复	提取方法 + 上移字段
构造函数中重复	上移构造函数体
类似但不完全相同	模板方法
不同算法做同一事	替换为最佳算法
不同类中重复	提取超类或提取类
条件判断中重复执行	合并条件表达式或提取方法
条件分支中都有相同代码	合并重复的条件片段

✅ 收益

• 代码更短小精悍；
• 更易维护和复用。

---

💤 Lazy Class（懒类）

🧾 症状

• 类几乎没什么作用，但还存在。

🧠 问题原因

• 可能是之前重构后变得空了；
• 也可能是为“将来可能的功能”留的坑，结果没填。

🛠️ 应对方法

• 用 内联类 删除它；
• 或者 合并继承结构 把它合并掉。

✅ 收益

• 减少冗余类，代码更简洁，维护负担更小。

---

📦 Data Class（数据类）

🧾 症状

• 只有字段、getter/setter，没有任何逻辑。

🧠 问题原因

• 只当数据容器用，没有行为逻辑；
• 忽略了“对象应该操作自己的数据”这一点。

🛠️ 应对方法

• 封装字段，防止外部随意访问；
• 封装集合，避免直接操作集合；
• 客户端有逻辑的，迁移过来用 提取方法 / 移动方法；
• 去掉多余访问方法，使用 移除设置方法 或 隐藏方法。

✅ 收益

• 数据与操作结合，更面向对象；
• 客户端代码更清爽。

---

🪦 Dead Code（无用代码）

🧾 症状

• 某些变量、方法、类再也没用到。

🧠 问题原因

• 改需求时没人清理旧代码；
• 有些分支永远执行不到。

🛠️ 应对方法

• 用 IDE 找无用代码；
• 删除参数、内联类、折叠继承结构都可用。

✅ 收益

• 精简代码，维护成本下降。

---

🧠 Speculative Generality（推测性泛化）

🧾 症状

• 出现了一些“可能将来会用”的类、方法、字段，但现在根本用不到。

🧠 问题原因

• 提前设计了很多“保底方案”，但未来功能没做成。

🛠️ 应对方法

类型	处理方法
未用抽象类	折叠继承结构
多余委托类	内联类
未用方法	内联方法
未用参数	移除参数
未用字段	直接删除

✅ 收益

• 代码精简，避免“写给未来的幽灵功能”。

⚠️ 可忽略情况

• 开发框架时，保留给“用户未来扩展”的 API 是合理的；
• 删除前确认不是测试代码依赖。

---