读 《重构-改善既有代码的设计》 要点记录

读 《重构-改善既有代码的设计》 要点记录 [TOC] 书本的年代:作者在写此书时还在流行使用java1.1, 我在读这本书时流行java7和8.

重构的定义:

  1. 对软件内部 结构 的一种调整,目的是在不改变【软件之可察行为】前提下,提高其可读性, 降低修改成本。

  2. 使用一系列重构准则,在不改变【软件之可察行为】前提下,调整其结构

为何重构?

 如果没有重构,程序 的设计 会逐渐腐败变质 。  重构 使软件更易被理解。  重构的确能够提高生产力  如果没有重构就必须保证【预先设计】正确无误,毫无差池。

:-:asdf:-:

重构方法

1.过长的方法

拆分成若干 表达明确小方法

2.过长的类

拆分

3.重复的代码

方法提取,重用

4.使用了太多的间接层

确认其不具多态性,删了这些不必要的委托

5.以查询取代临时变量(局部变量)

临时变量会驱使你天之写出更长的函数,减少他们。

6.循环变量 集用临时变量

临时变量应该只被赋值一次,只承担一个责任。 
如果同一个临时变量承担两件不同的事情, 会令代码难以阅读。

7.移除对参数的赋值动作

注:由于作者还停留在java只能按值传递的java1.1年代, 所以和现在有所区别

8.替换新的算法

如果有更简单、优秀的算法出现时

9.搬移函数

何时不该重构?

  1. 重构不如重写来得简单的时候。
  2. 项目接近最后期限

重构目标:

代码复用,去除重复代码。

Tip: 如果你发现自己需要为程序 添加一个特性, 而代码 结构 使你无法很方便 地那么做, 那就先重构那个程序 , 使特性的添加比较容易 进行, 然后再添加特性。

重构的关键: 可靠的测试(单元测试的重要地位)

重构时最好小步前进,编译并测试(文中指测试脚本),确保没有破坏任何东西,使犯错的几率降到最小 重构和优化,分为两个不同目标下所产生的行为,区别对待、不混淆。

书中有大量篇幅用来介绍 JUnit 单元测试法、用法。 不断丰富单元测试代码使它能在重构过程中及时的发现bug。

当测试数量达到一定程度之后,测试效益会呈现递减态势,而非持续递增,应该把测试集中在可能出错的地方。

两顶帽子

添加新功能

添加新功能 时,你不应该修改既有代码 ,只管添加新功能 。

重构

重构时你就不能再添加功能 ,只管改进程序结构。

重构VS设计 

  虽然这是不最有效的途径,但是将重构作为‘预先设计’的替代品, 不必做任何设计, 只管按照最初想法开始编码,让代码有效运作,然后再将它重构成型这种方式是可行的。   如果没有重构就必须保证【预先设计】正确无误,毫无差池。

灵活VS简单

灵活的解决方案总是比简单的解决方案复杂许多, 最终得到的软件通常复杂度更高\更难维护。 其中肯定有些灵活性的确派不上用声,但你无法预测到底是哪些派不上用场 ,为了获得想要的灵活性,  你不得不加入比实际需要更多的灵活性。 追求灵活容易劳而无获。 而重构可以带来简单的设计 ,同时又不损失灵活性。

代码性能优化

如果一视同仁的优化所有代码,90%的工作都是白费劲。 重构的确会使软件变慢,但它使优化阶段中的软件性能调整更容易 避免猜测性能问题所在,而是要实际量度系统

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

赞赏支持
X
支付宝
9.99
无法付款,请点击这里
金额: 0
备注:
转账时请填写正确的金额和备注信息,到账由人工处理,可能需要较长时间
如有疑问请联系QQ:565830900
正在生成二维码, 此过程可能需要15秒钟
JSRUN前端笔记, 是针对前端工程师开放的一个笔记分享平台,是前端工程师记录重点、分享经验的一个笔记本。JSRUN前端采用的 MarkDown 语法 (极客专用语法), 这里属于IT工程师。