读《重构》的读书笔记

第一章

重构的目的

• 让你以更少的工作量的对程序添加新特性。

重构的技巧

• 构建可靠的、可以自我检验的测试环境，因为对比测试结果会浪费大量时间
• 注意返回值范围与是否需要浮点数的问题，比如返回int还是double，返回int还是long
• 分解长代码
  • 代码块越小，它的处理和移动越轻松
  • 好的代码应该清楚地表达自己的功能，而变量是实现这一点的关键
  • 如果某段代码只用到了一个类中的数据，那应该考虑这段代码是否放错了位置，他是否本应该是该类的某个方法、某个功能。
• 去掉只用一次的临时变量，使用查询性质的函数代替临时变量

从改造getTotalCharge和getTotalFrequentRenderPoints的例子来看，代码可读性经常与高性能是一对冤家，二者经常不能同时达到，比如作者在这里就对同一集合做了三次循环。

• 当同一段数据处理在多个类中都可以时，我们要选择那个在未来最可能变化的那个类中进行处理。这样可以限制未来变动带来的影响（假设A/B两个类，B更容易变化，那我选择在B中写处理A、B数据的代码，将来B变化，我只需要改B类，而不需要去改动A类）

  比如，在实际开发中，同一段A表B表连表的SQL可以写在AMapper.xml、BMapper.xml中都可以，那现在应该看未来AB那个表更容易变化，那我就在哪个表中写这段SQL

• 当多条件判断后有不同的逻辑时，我们可以将不同的条件后的逻辑抽象出来成为一个abstract类，然后扩展多个子类，从而将不同的条件的逻辑处理实现到相同的方法中去。当然我们还需要多条件判断注入不同的子类，只不过我们原有的程序本来面对的是不同条件下的不同逻辑处理，现在使用了State模式后，面对的是不同的abstract类的子类，我们将不同的逻辑抽离出去，以后想修改哪个条件下的逻辑，可以直接去对应子类中去修改，达到了解耦的效果

• 期间，我们还可以使用默认方法的方式为abstract类提供一个默认实现

spring中

保证service之间的引用都是树状的，不是网状的。是按照业务逻辑一个层级一个层级的树状结构，才可以避免循环依赖。

第二章

• 重构就是整理代码，让代码回到它该去的地方
• 待代码趋于整洁后，我们看一看到一些设计层面的东西
• 搞清楚代码结构后，更容易揪出bug
• 良好的设计可以提升开发速度，因为它会让你减少花在调试上的时间和添加新功能的代码
• 重复做了三次类似的事情，那么应该重构了
• 重构的三个时机
  • 添加新功能
  • 修复错误时
  • 复审代码时
• 大多数重构都是为程序引入更多的间接层

第三章

代码的坏味道

• 重复代码
  • 同一个类的两个函数有相同的表达式，重复代码拿出来
  • 互为兄弟的两个类有相同的函数，抽象到超类中
  • 两个完全不相关的类有相同的代码，考虑逻辑是否有问题
• 过长函数
  • 每当想写点注释的时候，我们就要考虑将接下来的代码抽出来作为一个方法，以其用途作为方法名
  • 条件表达式和循环也是提炼的信号
• 过大的类
• 过长的参数列表会影响对该方法的理解
• 一个类受多种变化的影响
  • 应该找出修改多处的原因，将其提炼到另一个类中
• 当有一处修改需求时，需要修改多处
• 一个类中的某个函数过度依赖另一个类
• 当若干个（两个及以上）数据项在多个类中都重复出现了，那么应该将这些重复数据项提炼到一个类中，哪怕在某个地方只使用了这个新类的其中两个字段也是值得的
• switch语句
• 一个类没怎么被用到
• 删掉认为“未来可能用到”的代码，比如参数列表，钩子，接口
• 一个类中某些字段只是在某种特殊情况下才会用到，但这样的字段会让人confuse的
• 过度运用委托，太多“不干实事”的类出现
• 子类只使用到一部分超类的代码
  • 应该创建一个兄弟类，把使用不到的代码推给兄弟类，保证超类中存放的是所有类都用到的代码
• 当想写注释时，可以使用抽象出方法，通过方法名来表明你的意图，而不是通过注释