《重构》代码的坏味道

《重构》代码的坏味道

@(重构)[代码的坏味道|Markdown]

本周的主题仍然不是具体的重构手段，而专注于“代码的坏味道”。“代码的坏味道”提示我们什么样的代码有一股”难闻的味道“，以此来提示我们这段代码是需要改进，需要重构的。那么，什么样的代码有这种坏味道呢？总结如下：

---

---

坏味道 No.1：重复代码

看的到重复代码

• 在实际的项目中，重复的代码意味着以后的改动很可能要同时修改多处地方，当重复的代码逐渐积累，那么这种改动往往需要付出极大的人力和时间来重构。
• 出现重复代码时需要及时排查和统一，否则到了之后，你再想去重构，就会发现重复代码变的零零散散，很难将他们一网打尽。如果你将他们合二为一，程序结构会变得更好，你所站的角度会更高，你会看到更多的设计背后的东西。

重复代码的重构之道

• 在同一个类中的两个函数含有相同的表达式，那么将重复部分的代码提炼到一个单独的函数中然后让这两个函数去调用它，会是一个不错的方法；
• 如果两个互为兄弟的子类含有相同的表达式，意味着你可以把他们的公共代码段进行Extract Method然后写到他们的超类；
• 如果两个毫不相干的类出现了重复代码，你可以考虑使用Extract Class将从重复代码提炼到一个独立类中去，然后在另外一个类中使用这个类就可以了。

---

坏味道 No.2：过长函数

看得到的过长函数

• 过长的函数可读性很差，甚至于让人在第一眼就产生难以接受的感觉，因为他们复杂，难以重用，稳定度很低。
• 作为面向对象的程序，短函数的普适度明显可以给我们带来更多的便利性；

过长函数的重构之道

• 重构长函数无非就是把他们分成一个个短函数，但重构过程中需注意短函数的命名，以及作为参数传递的临时变量的处理。

---

坏味道 No.3：过大的类

看得到的过大类

查看一个类是否“过大”，有两点可供借鉴：
- 这个类实例变量太多，必然会有Duplicated Code；
- 类内如果有太多代码，也会产生Duplicated Code，让整个类看起来混乱并最终走向死亡；

过大类的重构之道

• 分离子类；
• 代入合适的设计模式以分离行为和数据；

---

坏味道 No.4：过长参数列

看得到的过长参数列

• 过长的参数列难以理解，会造成前后不一致，而且一旦你需要更多数据，就不得不修改它。

过长参数列的重构之道

• 使用方法取缔非必要参数；
• 将对象或结构体传递给函数，比如 Lua 中就可以使用 table 作为参数来传递。

---

坏味道 No.5：过多的注释

看得到的过多注释

• 好的注释只说重点，或者用来记录你将来打算做什么，或者标注你没有把握的地方，或者写下为什么做这件事情的原因，来提醒将来的修改者让他们更好的理解你的代码。而绝不是解释代码的具体行为。

过多注释的重构之道

• 当你感觉需要撰写注释，请先尝试重构，试着让所有注释都变得多余。

---

总结

PS：实际上，《重构》一书还提到了许多“代码的坏味道”，但大多都是以Java编程中存在的问题来说明；因此有些比较冷门的坏味道暂时不考虑记录在此，等以后有机会遇到的时候再来重温。