最近一段时间在看《重构，改善既有代码的设计》这本书，本书的前四章从第一个重构的例子入手讲解，然后循序渐进的去说它是什么，重构的好处，重构的时机等等。
第一章：第一个案例。这个例子简单易懂，用到了很多基本的处理代码的思路和方式，比如：提取函数，消去临时变量等。
第二章：重构的原则。其中，何时该重构，和何时不该重构，重构与设计这一小节和重构与性能这一小节，值得去反复思索。不该重构的几点：一，既有代码已经不能正常运作了，不得不重写新的；二、既有代码混乱，但又可以正常运作，重构起来要比重写困难复杂得多的时候，这时候我们就需要选择更简单有效的方式，去重写了；三、当项目接近期限或者工期紧急的时候，没有足够的时间和足够的把握去重构，就不要进行重构了。
第三章:代码的坏味道。这里讲述了几点“坏味道”，值得引起注意，考虑是否需要重构。当然，重构不是死板的，具体情况具体分析。下面罗列一下这些坏味道，我会对其中不易理解的总结一下书中的解释：
（1）、重复代码
（2）、过长函数
（3）、过大的类
（4）、过长参数列
（5）、发散式变化：当一个类中，因为A变化的引入，其中的几个方法需要改动；因为B变化的引入，需要改动其中的另几个方法，这时候就需要将这个类拆分成两个类，让他们因为某一单一变化只改变一个类。
（6）、霰（xian）弹式修改：因为某种变化，需要改动很多类，就试着去将这些类中需要改动的地方放到一起，如果没有就可以创造一个出来。
（7）、依恋情结
（8）、数据泥团：多个类中相同的字段、许多函数签名中相同的参数，如果这样的状况时有发生，就可以考虑为他们创建专属的独立对象了。
（9）、基本类型偏执
（10）、switch惊悚现身
（11）、平行继承体系
（12）、冗赘类
（13）、夸夸其谈未来性
（14）、令人迷惑的暂时字段
（15）、过度耦合的消息链
（16）、中间人：当过度运用委托的时候，可以考虑去掉中间人让他们直接打交道。
（17）、狎昵关系：将过度亲密的类，划清界限。
（18）、异曲同工的类：有着相同或者几乎相似行为的类，我们可以试着将他们合并起来。
（19）、不完美的类库：很多库类，不能总是满足我们的需求，所以 我们可以通过 外加方法和本地扩展类 来进行有效的补充。
（20）、纯稚的数据类：Data Class是指拥有一些字段和字段读取函数，这样的数据容器。
（21）、被拒绝的馈赠：“如果子类复用了超类的行为（实现），却又不愿意支持超类的接口，Refused Bequest的坏味道就会变得强烈。”---原话。
（22）、过多的注释:有时候不得不用注释来解释这段代码是做什么的，就要留意被解释的这段代码是否需要重构。
第四章：构筑测试体系。重构的基础是有一个安全可靠的测试系统，以帮助一步一步完成重构，这是重构的前提，作为java开发，junit即可。
以上为，对于书本身的一些介绍总结。以下是个人的一些感想：
个人对重构的初识印象：重构是让程序更加清晰，结构变得更加合理，清晰的逻辑和结构设计，便于维护和管理。但是这种代码优化和性能优化又是两码事。甚至可以说是，很难兼容到一起的。代码重构，可能导致更多的方法调用，更多的资源消耗，当然也未必，但这和性能优化是相悖的，但是不代表重构必然导致性能降低。
重构与设计，我们可能在最初开发的时候会对即将要做的程序进行预期设计，并极有可能这就是我们需要达到的最终设计。但是即使在没有预期设计的情况下，给予最基本的实现基础上，我们进行重构进而向上提取等手法，最终也会形成一个良好的设计和体系。因此，重构和设计是相辅相成的，是互补的。
以上笔记，谨以记录读书的过程，如有不妥之处，大家指正交流，后续还会写此书的读书笔记。