《重构 改善既有代码的设计》第3章 代码的坏味道——学习笔记
文章目录
- 1. 神秘命名
- 2. 重复代码
- 3. 过长函数
- 4. 过长的参数列表
- 5. 全局数据
- 6. 可变数据
- 7. 发散式变化
- 8. 散弹式修改
- 9. 依恋情结
- 10. 数据泥团
- 11. 基本类型偏执
- 12. 重复的switch
- 13. 循环语句
- 14. 冗赘的元素
- 15. 夸夸其谈通用性
- 16. 临时字段
- 17. 过长的消息链
- 18. 中间人
- 19. 内幕交易
- 20. 过大的类
- 21. 异曲同工的类
- 22. 纯数据类
- 23. 被拒绝的遗赠
- 24. 注释
如果尿布臭了，就换掉它。
1. 神秘命名
整洁代码最重要的一环就是好的名字，所以我们会深思熟虑如何给函数、模块、变量和类命名，使他们能清晰表面自己的功能和用法。
2. 重复代码
如果你在一个以上的地点看到相同的代码结构，那么可以肯定：设法将它们合而为一，程序会变得更好。
3. 过长函数
据我们的经验，活得最长、最好的程序，其中的函数都比较短。
短的函数具有更好的阐释力、更易于分享、更多的选择。
函数越长，就越难理解。
每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。
条件表达式和循环常常也是提炼的信号。
4. 过长的参数列表
过长的参数列表本身也经常令人迷惑。
如果可以向某个参数发起查询而获得另一个参数的值，那么就可以使用以查询取代参数去掉第二个参数。
使用类可以有效地缩短参数列表。
5. 全局数据
全局数据是最刺鼻的坏味道之一。
一次又一次，全局数据造成了哪些诡异的bug，而问题的根源却在遥远的别处，想要找到出错的代码难于登天。
良药与毒药的却别在于剂量。有少量的全局数据或许无妨，但数量越多，处理的难度就会指数上升。
6. 可变数据
对数据的修改经常导致出乎意料的结果和难以发现的bug。
如果可变数据的值能在其他地方计算出来，这就是一个特别刺鼻的坏味道。
7. 发散式变化
一旦需要修改，我们希望能够跳到系统的某一点进行修改，只在此处进行修改。如果不能做到这一点，你就能嗅出两种紧密相关的刺鼻味道中的一种了。
8. 散弹式修改
如果遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是散弹式修改。
9. 依恋情结
所谓模块化，就是力求将代码分出区域，最大化区域内部的交互、最小化跨区域的交互。
如果一个函数跟另一个模块的函数或者数据交流格外频繁，远胜于在自己所处模块内的交流，这就是依恋情结的典型情况。
10. 数据泥团
你常常可以在很多地方看到相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数。
11. 基本类型偏执
大多数编程环境都大量使用基本类型，即整数、浮点数和字符串等。
一个有趣的现象：很多程序员不愿意创建对自己的问题域有用的基本类型。
字符串是这种坏味道的最佳培养皿，比如，电话号码不只是一串字符。
12. 重复的switch
我们现在更关注重复的switch：在不同的地方反复使用同样的switch逻辑（可能是以switch/case语句的形式，也可能是以连续的if/else语句的形式）。应该以多态取代条件表达式消除掉。
13. 循环语句
函数作为一等公民以及得到广泛的支持，因此我们可以使用以管道取代循环来让这些老古董退休。
管道操作（如 filter和map）可以帮助我们更快地看清被处理的元素以及他们的动作.
14. 冗赘的元素
程序元素（如类和函数）能给代码增加结构，从而支持变化、促进复用或者哪怕只提供更好的名字也好，但有时我们真的不需要这层额外的结构。
可能有这样一个函数，他的名字就跟实现代码看起来一模一样。
可能有这样一个类，根本就是一个简单的函数。
15. 夸夸其谈通用性
如果函数或类的唯一用户是测试用例，这就飘出了这个坏味道。
如果发现这样的函数或类，可以先删掉测试用例，然后移除死代码。
16. 临时字段
某个字段仅为某种特定情况而设。这样的代码让人不易理解，因为你通常认为对象在所有时候都需要它的所有字段。在字段未使用的情况下猜测当初设置它的目的，会让你发疯。
17. 过长的消息链
如果你看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象——这就是消息链。
在实际代码中你看到的可能是一长串取值函数或者一长串临时变量。
18. 中间人
对象的基本特征之一就是封装——对外部世界隐藏其内部细节。
封装往往伴随着委托。
但是人们可能过度运用委托。你也许会看到某个类的接口有一半的函数都委托给其他类，这样就是过度运用。
19. 内幕交易
如果两个模块总是窃窃私语，就应该用搬移函数和搬移字段减少它们的私下交流，把这种交易都放到明面上来。
如果两个模块有共同的兴趣，可以尝试再新建一个模块，把这些公用的数据放在一个管理良好的地方。
20. 过大的类
如果想利用单个类做太多事情，其内往往就会出现太多字段。一旦如此，重复代码也就接踵而至了。
21. 异曲同工的类
使用类的好处之一在于可以替换：今天用这个类，未来可以换成另一个类。
22. 纯数据类
所谓纯数据类是指：他们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无长物。
如果发生这种情况，你应该在别人注意到之前，立刻运用封装记录将他们封装起来。
23. 被拒绝的遗赠
子类应该继承超类的函数和数据。但如果他们不想或不需要继承，又该怎么办呢？他们得到所有礼物，却只从中挑选几样来玩！
这种情况就不要虚情假意地糊弄继承体系，应该运用委托取代子类或者委托取代超类彻底划清界限。
24. 注释
别担心，不是说你不该写注释。
有写注释存在是因为代码很糟糕，这种情况的发生次数之多，实在令人吃惊。
注释可以带我们找到本章先前提到的各种坏味道。
- 当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余。
如果你需要注释来解释一块代码做了什么，试试提炼函数。如果函数已经提炼出来，试试用改变函数声明为它改名，再或者引入断言。如果你实在不知道该做什么，这才是注释的良好运用时机。
除了用来记述将来的打算之外，注释还可以用来标记你并无十足把握的区域，比如你可以在注释里写下自己“为什么做某某事”。这类信息可以帮助将来的修改者，尤其是那些健忘的家伙。