重构改善既有代码设计-读书笔记

这本书买了很久了，最近才读完，做个简单的记录，方便以后复习。

• 重构的目的：改善代码的可读性和可维护性

• 重构带来的影响：软件的功能不便，可阅读性，可维护性增强，性能得到优化

• 重构的指导原则：重构的各种发放应该遵循基本的软件设计原则

• 重构的时机：一般在项目实践中，专门安排时间重构是不太可能的，因为老板只关心功能和进度，至于软件的内部结构根本不在考虑范围之内。因此重构的时机很重要，一般重构可以在以下几种情况下进行：
  1、舔加新功能时
  2、修改bug时
  3、代码评审时

• 重构的意义：重构对于软件本身的意义很明显，如改善代码结构，增加可读性，可扩展性，提升性能，这里就不再赘述了。说一说重构对于程序员本身的意义。
  1、提升设计思维：由于重构本身是基于基本的设计原则，因此程序员开始审视重构代码的时候，其实是用各种设计原则去评审代码是否合理，在潜意识中强化了编码者设计思维的习惯。
  2、提升技术自信心：大家知道重构其实是对自己或者他人既有的代码的修改，当你以一种更优雅的结构去替换原本丑陋的结构的时候，内心自然会有一种自豪感，由此提升自身对技术的自信。对技术的自信，是提升学习兴趣的不二法门。即：越优秀，越想优秀
  3、修炼心性：很多时候，重构并不是一蹴而就的，由于既有的代码谜团可能导致重构之前需要大量的思考。思考过后修改了代码还需要谨慎的测试。这都需要耗费大量的心力。最为关键的时，重构通常并不在项目计划内（没有哪个老板愿意花时间在看不到的影响上），因此程序员需要合理安排重构时间。最大的问题是还需承担修改原有代码带来的改变原有稳定功能的风险。（这应该才是大家回避重构的最大原因）

下面说说重构的具体实践,我们都知道，重构是对既有代码的改善，那么，什么样的既有代码需要改善呢？这里就引出了代码坏味道的概念：
书中阐述了一系列坏味道，挑一批简单的说一下：
1、重复代码：

• 概述：重复代码一般表示类中不同方法都含有相同的逻辑，或者各个类中含有相同的逻辑
• 不良影响：代码重用性低，不便于维护，修改逻辑时，所有地方都要修改，导致遗漏
• 重构手法：一般就是抽出方法，如果是同一类，就抽出一般方法放在类的内部。如果是重复代码分散在多个类，就需要抽出公共方法，或者是抽出一个单独的类来处理
  2、过长函数：
• 概述：函数太长，其中代码结构和逻辑都混乱，尤其是N多逻辑判断结构，if-else,for循环和异常处理之间反复纠缠，一团乱麻。
• 不良影响：首当其冲的就是可读性，这其实是时间成本，5秒钟能读懂一个函数和5分钟读懂肯定不是一回事，而且大家都知道，每个人能保持专注力的时间是有限的，如果一个高度复杂的函数，完全可能耗费你大量的专注力，最后由于精力耗尽还不得不重新来过，这个在实践中是经常出现的。
• 重构手法：首先需要遵循单一职责的原则，看一看方法是否担任了过多的职责，这往往是导致方法过长的主要原因，如果是，需要拆分为多个方法。
  抽出方法把功能模块分析，用查询替换临时元素消除过多临时变量，引入参数对象消除过长的参数列表
  3、过大类：
• 概述：一个类如果承担过多的职责，必然导致类过大
• 不良影响：可读性差，违反单一职责原则，破坏封装性，类间强耦合，扩展性可维护性都很差
• 重构手法：理清逻辑，划分功能，将不同的功能单独抽出成不同的类。根据需要或许还应该抽出子类。
  4、过长参数列表：
• 概述：参数列表一长串，各种类型的，参数命名可读性差
• 不良影响：人能记住的数据点是有限的，一长串参数在方法体内频繁出现，势必导致阅读时需要反复回顾参数意义，可读性降低，而且容易出错，特别是某些参数还要被作为其它方法的参数被代入到其它方法体内的时候。有时候需要往回翻好几层才能回顾参数的具体意义。增加阅读难度
• 重构手法：用参数对象取代单纯的参数，参数对象对于方法来说只有一个元素，需要记忆的量为1，而且对象可以归类分散的参数，使其具有更明确的意义。
  5、发散式变化：
• 概述：一个人在公司太重要了，管理要做，技术要做，财务也要做，还得做业务。有点什么事都要找到他，哪天他身体抱恙出了点问题，公司瘫痪了。类也是如此，一个类负责了太多的功能，导致系统有什么变化都会引起该类的修改。
• 不良影响：职责不单一，不符合开闭原则，老是改来改去，容易出问题
• 重构手法：划分功能，抽出类。注意此处是多处业务对应一个类，下面的霰弹式修改是修改一个业务，却要改N个类
  6、霰弹式修改：
• 概述：业务变一点，要改N个地方，还经常改漏
• 不良影响：业务变更导致多处修改，代码重用性低，漏改风险大
• 重构手法：如果是代码块重复就应该抽出方法，如果是方法分散就应该move method把相关的功能移到一个类中
  7、依恋情节：
• 概述：函数需要的数据大多来自其它类
• 不良影响：造成类与类之间的耦合
• 重构手法：把方法移到其所需要的数据所在的内，这样方法可以直接访问数据，类与类之间也解耦了
  8、基本类型偏执：
• 概述：喜欢使用基本数据类型
• 不良影响：不符合面向对象原则
• 重构手法：使用对象代替基本类型
  9、Switch Statement：
• 概述：用switch语句判断
• 不良影响：增加代码复杂度，而且需要频繁修改类，不符合开闭原则
• 重构手法：用多态代替
  10、临时字段：
• 概述：代码中大量的临时变量，并且命名也不清晰，不知道变量要表达什么意思
• 不良影响：增加阅读难度
• 重构手法：
  11、中间人：
• 概述：过度使用委托
• 不良影响：过度使用委托，增加代码层次，复杂度
• 重构手法：移除中间人
  12、过度耦合的消息链：
• 概述：过度的使用代理导致大量的中间人
• 不良影响：牵一发而动全身，某个修改可能导致一个链的修改。风险增大
• 重构手法：
  13、过多的注释：
• 概述：注释过多，有的是历史遗留的，有的还是错误的注释
• 不良影响：注释过多实际上影响代码的可读性，因为代码中穿插注释，容易引起阅读人注意力分散。并且过多的注释往往使代码看起来凌乱不堪，有的错误的注释反而会让人迷惑。对编码者来说，以为有注释可以依赖，就不会注重代码本身的可读性。
• 重构手法：尽量用规范，有意义的命名方法命名类，方法，字段

总结：重构是一个循序渐进的过程，很少有代码重构是一步就绪的。要做好重构，需要掌握以下技能点：
1、熟悉基本设计原则和软件设计模式，多看优秀的代码，从审美上提升自己，只有这样，才会有发现代码坏味道的能力
2、熟悉常用的重构手法,时不时翻翻本书.
3、养成重构的习惯，哪怕项目中不允许，也可以用项目代码做重构练习（不提交）
4、英文要学好，对方法和变量的 命名很有帮助，只有这样才能给出命名清晰的变量