代码的坏味道：
1、重复代码；
2、过长函数；
3、过大的类（C中可说过大的结构体）；
4、过长参数列表；
5、发散式变化；
6、依恋情结；
7、霰弹式修改；
8、数据泥团；
9、基本类型偏执；
10、switch惊悚现身；
11、冗余类；
12、平行继承体系；
13、夸夸其谈未来性；
14、过度耦合的消息链；
15、令人迷惑的暂时字段；
16、异曲同工的类；
17、狎昵关系；
18、中间人；
19、纯稚的数据类；
20、不完美的库类；
21、过多的注释；
22、被拒绝的遗赠；
何时需要重构：
1、如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地打成目标，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。
2、重构之前首先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验能力。
3、重构技术就是以微小的步伐修改程序。如果你犯下错误，很容易便可发现它。
4、任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优秀的程序员。
5、重构：对软件内部结构的一种调整，目的是在不改变软件客观查行为的前提下，提高其可理解性， 降低其修改成本。
6、重构：使用一系列重构收发，在不改变软件可观察行为的前提下，调整其结构。
7、事不过三，三则重构。
8、不要过早发布接口，请修改你的代码所有权政策，使重构更顺畅。
9、当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余。
重构中的测试：
1、确保所有测试都自动化，让它们检查自己的测试结果。
2、一套测试就是一个强大的BUG侦测器，能够大大缩减查找bug所需的时间。
3、频繁地运行测试，每次编译请记得把测试也考虑进去——每天至少执行每个测试一次。
4、每当收到BUG报告，请先写一个单元测试来暴露bug。
5、编写未臻完善的测试并实行实际运行，好过对完美测试的无尽等待。
6、考虑可能出错的边界条件，把测试火力集中在那儿。
7、当事情被认为应该会出错时，别忘了检查是否抛出了预期的异常。
8、不要因为测试无法捕捉所有bug就不写测试，因为测试的确可以捕捉到大多数bug。
重构步骤：
1、随时挑一个目标；
2、没有把握就停下来；
3、学习原路返回；
4、结对重构。
之所以会找到重构，因为在公司接手了一个项目要将其转化为产品。由于代码是一年前写就的，之后在需要做演示的时候会对以前的代拿进行适当的增减，完成要演示的功能。但是至于代码的质量无法保证。于是要进行BUG查找与修复。
由于一开始代码经由三个人写就，中间代码风格不统一，每个人写函数的方式也不一样。
在进行BUG查找与修复的过程中要理解代码，并找到需要改正的地方。
由于代码中风格不一，代码中全局变量使用广泛，长函数随处可见。由于没有采用统一的对齐方式，代码对齐混乱（也有可能是自己编辑器设置的缘故）。在理解代码的时候着实头疼。很多时候，都怕因为没有正确理解函数原意，造成修改的错误。在修改的过程中，也确实发生过修改过的函数执行出现了异常。
在经过了艰难的初步修改后，能够正常使用。但是对于修改过程仍感到十分辛苦。在想怎么才能在修改代码的过程中能更好一些。在之后遇到的《代码大全》中介绍了《重构》。
读了《重构》后，发现自己以前修改代码的过程，其中一部分在修改过程中不改变代码原意，而是使代码更容易理解以及添加新的功能的一些修改，专业点就可以说是重构。但是以前没有这个概念。里边介绍的一些方法，在修改的过程中都用到了一些。经过这里的总结，发现对重构理解加深了很多。或许这些，总需要先经历一番这个过程，才会看到重构的价值。
在重构的过程中，如何把握重构的程度，需要大量的实践才能获得。如其作者Martin Fowler 所言“因为你还不知道何时应该使用它们，何时不应该使用；何时开始，何时停止；何时前进，何时等待。使重构成功的，不是前面各自独立的技术，而是这种节奏”。
畅学电子
