代码的二十二道臭味





这是一篇关于阅读《重构，改善既有代码的设计》后的笔记，记住了代码发臭的二十二种形式，并形成这样的意识，自己每次写代码的时候都能时刻提醒自己代码是否在发臭，那么我们的生活会更轻松。重构不可避免，但是尽量减少重构的概率还是很不错的。

1.重复代码。重复代码是我们这些初学者最容易犯的错了，复制粘贴固然省力，但是省的只是当时的力。一般来讲，可以复制粘贴的代码都是实现相似甚至相同功能的代码，要是这个序列的功能改了一点点，(⊙o⊙)…好累

2.过长的函数。我想看看这个函数主要做了些什么，怎么做的，可是…咦，这个变量是什么意思，这个If句子开始于哪里，这个花括号的前半截开始于哪里，我把光标滚到前面，可是滚回来的时候找了半天才回来，可是还是没能看到这个函数的主要步骤，(⊙o⊙)…好累，等等，这段代码在哪见过，是从那拷贝过来的？

3.过大的类。类太大了本身不是错，但是当它很长的时候就该提醒自己，是不是耦合了相关性不是很强的功能在这个类里？是否可以让这个类更单纯一点，只做好一件事？是否可以请其他类来帮忙完成相关工作？

4.参数列表过长。当一个函数参数列表过多时使用起来会很累，函数体也会倾向于过长，考虑把相似或紧密相关的参数封装起来，能够作为中间变量的把生成该变量的代码提出来做成另一个函数，然后使用局部变量。

5.发散式变化。如果需求有了改变，修改代码时就要大量的删除代码行再生成新代码时就该注意了。理想状况是如果要改代码，那么只改相关的少数几个点，而不影响其他代码的运行。

6.霰弹式修改。这和发散式变化相似，不同的是发散式变化在每一处变化都很少，但是却在很多点上进行类似修改。

7.依恋情结。写了很多类，但是他们在功能上却彼此相依，很难单独使用某些类，不利于复用，修改起来也会陷入前面两种困境。

8.数据泥团。几个类里都有语意相似的变量，这也是代码重复的一种形式，也可能是这些数据没有找到正确的依附的类，需要进一步抽象已达到封装数据的目的。

9.基本类型偏执。基本类型是做一切事情的基础，但是将他们组织为更有意义的复合类型（结构体和类）会让代码的编写、阅读、维护轻松很多很多。

10.switch惊悚现身。switch和if的问题在于重复，如果可以使用继承与多态把他们从代码中去除重复代码的话，就坚决地去除。但是不是所有的switch 和if都是不必要的。

11.平行继承体系。新增一个继承类时，马上就去另一个继承体系里增加一个类名前缀相似的子类时，就要警惕了。

12.冗赘类。每创建一个新的类都需要别人理解、维护，但是很多情况下他们只是临时工，仅为了实现某项功能而出现，不具有持久的生命力，换一个环境竟然不能复用。

13.夸夸奇谈未来性。编码时考虑未来可能会变更的地方，然后费力地使用各种淫巧奇技为特殊情况考虑是好习惯，但是考虑得过多就有问题了，那些概率很小的不是很重要的变化没有必要考虑。但是这和为了安全而防范不是一回事。这里说的变化是功能性或结构性的。

14.临时工字段。类中某些字段只是为了某些特殊状态时使用，就像临时工一样。类的字段应该是很重要的，必须的。

15.过度的消息链。不停地转发消息，消息经过长长的路径才到达实际处理者，这往往是类的职责划分不当，导致协作时很费力。

16.中间人。过度使用代理。

17.狎昵关系。为了合作，两个类需要费力地了解彼此的私有字段，表现得过于亲密。在初学者面前的表现形式为了协作的两个类公开了应该私有的字段。（理想状况下字段应该都是私有的）

18.异曲同工的类。这个说得很明白了，关键在于怎么识别。

19.不完美的类库。我也不懂做着要说的是什么，希望懂的人指导一下。

20.纯稚的数据类。一个类除了包含字段和存取字段的方法外，竟然再没有其他功能，只是充当了数据的容器。这个就看这个类的封装是否合理了，如果真的是，那么没话说。如果不是，那就一定是另一个类承担了这个类应有的职责，在其他地方产生了臭味。

21.被拒绝的馈赠。父类拥有的字段子类应该都需要，如果不是，那么就出了问题，这很怪异，可能不能满足is-a语意。

22.过多注释。这不是少些注释的借口，而是说注释关注的方面正确吗？注释存在的理由正确吗？

二十二道臭味已经呈现了，大家一起防臭吧！具体怎么防，请关注《重构，改善既有代码的设计》一书，以及设计模式相关的书籍。其实我们从前面也可以看到，有的臭味本身并没有错，却导致了其他地方的不合理，这是我们必须要注意的。作为结束，再加一道臭味：没有注释！