[Java] 《重构-改善既有代码的设计》全本笔记整合

整合内容分为以下部分：

              一、重构原则+最近看ROR获得的一些新体会。

              二、主要整合内容。（这部分比较乱，使用Ctrl+F查阅比较方便。

              三、之前几章的项目分享。

        这篇文章的使用方法除了Ctrl+F之外，还可以直接拉内容到百度，直接看别人整合的单条信息，相对更完整。

        那么，开始吧。

              一、重构原则+最近看ROR的一些原则。

为即将修改的代码建立一组可靠的测试环境。

临时变量助长冗长而复杂的函数。

最好不要再另一个对象的属性基础上运用switch语句。如果要switch也要在类自己的数据上使用。

事不过三，三则重构。

首先写出可调的程序，然后调整它以求获得足够速度。

一个好的名字可以省去读函数内容的操作。

每当需要注释说明时，可以被写进一个函数里，并以用途命名，关键不在函数长度，而在函数做什么，怎么做。

条件和循环也是提炼信号。

针对外界变化的所有相应修改，应该只发生在单一类中，这个类的所有内容随外界变化。

一个函数使用几个类的功能，它应该被放在最多被此函数使用的数据一起。

对于出现在不同类/方法内的一些绑在一起的数据，应该给它们设置对象。

少用switch，switch代表重复。

两个帽子原则：不要边写代码边重构，带上写代码的帽子，觉得需要重构了，再带上重构的帽子去做，如此反复。

注释多写为什么这样，过多注释不一定是好，尝试重构。

先编写测试代码可以将关注点放在接口而非实现。

每当出现一个BUG，先写一个测试单元测试BUG。不要修改以前的测试单元，因为它可能会在修复BUG后出错。

测试：异常，边界

测试太多带来的效益呈现递减态势。但是我们尽量测试大多数BUG。

小步前进，频繁测试。

即使想要提炼的函数非常简单，只要新函数名能更好地示意代码意图，也应该提炼它。

重构出来的函数优先使用private修饰，日后可以慢慢放开。