《重构》——如何如何改善代码

代码的坏味道：

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查找与修复的过程中要理解代码，并找到需要改正的地方。

由于代码中风格不一，代码中全局变量使用广泛，长函数随处可见。由于没有采用统一的对齐方式，代码对齐混乱（也有可能是自己编辑器设置的缘故）。在理解代码的时候着实头疼。很多时候，都怕因为没有正确理解函数原意，造成修改的错误。在修改的过程中，也确实发生过修改过的函数执行出现了异常。

在经过了艰难的初步修改后，能够正常使用，但却也因为自己的修改引入了新的BUG。对于修改过程仍感到十分痛苦。在想怎么才能在修改代码的过程中能更好一些，更遵循代码的愿意，同时改善代码。在之后遇到的《代码大全》中介绍了《重构》。

读了《重构》后，发现自己以前修改代码的过程，其中一部分在修改过程中不改变代码原意，而是使代码更容易理解以及添加新的功能的一些修改，专业点就可以说是重构。但是以前没有这个概念。里边介绍的一些方法，在修改的过程中都用到了一些。经过这里的总结，发现对重构理解加深了很多。或许这些，总需要先经历一番这个过程，才会看到重构的价值。

在重构的过程中，如何把握重构的度，需要大量的实践才能获得。如其作者Martin Fowler 所言“因为你还不知道何时应该使用它们，何时不应该使用；何时开始，何时停止；何时前进，何时等待。使重构成功的，不是前面各自独立的技术，而是这种节奏”。