我是靠谱客的博主 超级短靴,最近开发中收集的这篇文章主要介绍《重构 改善既有代码的设计》 第2版前三章观后感重构是什么重构有什么作用何时重构开展重构的流程重构如何学以致用个人感觉重构和设计模式关系,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

重构是什么

书中原文解释的很好
分为名词,动词两种含义
重构(名词):对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本。
重构(动词):使用一系列重构手法,在不改变软件可观察行为的前提下,调整其结构。

重构有什么作用

好的方面

  1. 代码结构优化,降低重复代码,提高代码可读性
  2. 重构基于测试验证功能准确性的前提下,可以降低bug产生的概率
  3. 对于复杂和开发周期长的项目,重构可以提高开发效率
    3.1 基于测试的重构可以快速暴露bug的位置,越快暴露bug越容易解决(毕竟刚写代码产生的BUG修复成本,远低于过了一段时间后再发现BUG,再去回忆业务逻辑,跟找到对应代码琢磨哪里出错时的成本)
    3.2 基于测试的重构,虽然开发测试的代码会占用额外的开发时间,但是如果开发整体过程中需要多次验证代码准确性时,快速测试的时间节省会慢慢填补之前开发测试的耗时.

坏的方面

  1. 重构 不等于 性能最优! 重构本质还是让代码结构合理,容易阅读等.可还是跟性能优化不能一概而论.有些重构手法会降低性能(比如书里举例的:用查询替换掉临时变量.减少方法传参,但是可能导致多次查询反而不如设置一个临时变量,记录查询返回结果,避免多次查询的性能高.
  2. 虽然基于测试,但是重构还是存在风险的.毕竟测试覆盖率如果没有实现100%,也许本次修改只是开发在意的部分测试通过了,但是一些没有测试的功能盲区还是会有出现BUG的风险.
  3. 时间!虽然重构长期使用节省时间,但是毕竟还是有开发测试代码+重构构思和代码多次重构修改花费的时间,在时间十分紧张的情况下,还保持重构的方式开发,时间线的追求可能会高于代码质量的要求.

何时重构

  1. 开发中就重构;(个人感觉时间允许的前提下,这是最合适的时机,因为对于需求和当前代码内容结构理解最好的就是此刻了)
  2. 维护期增加功能,修复BUG;
  3. 需求变动修改较多逻辑;
  4. 对于某些性能差的功能方法需要性能调优等原因.

如果上线后代码能正常运行,还能满足业务需求的代码一般是不需要重构的.毕竟时间有限,还有开发不完的N多需求 (BUG)等待着大家!

开展重构的流程

  1. 已有能正常运行的代码:重构的对象
  2. 能够校验代码是否运行正确的测试,比如单元测试等:保证重构后代码依然正确的手段!!!
  3. 找到需要重构的代码块,也就是原书里提到的坏味道(书中第三章,建议精读):
    3.1 表达不够清楚的参数,方法,类等的命名
    3.2 可以抽出的重复代码块
    3.3 过多的方法参数
    等等
  4. 找出适合的应对重构方法(翻书,查资料)进行部分重构,书中建议每次重构内容不必过多.稳健第一.
  5. 测试重构代码是否能通过单元测试.
  6. 循环第5步,第6步 直到结束

重构如何学以致用

  1. 学会写测试,并开始写!!!
  2. 学会找到需要重构的代码跟结构,也就是所谓的坏味道的情况.
  3. 查阅书籍资料对症下药的重构实施

个人感觉重构和设计模式关系

个人感觉重构的一些原则跟设计模式的原则是不谋而合的.感觉每一次重构都是向这设计模式原则更靠近了一步.所以如果对于设计模式了解还不够深刻的小伙伴想练习重构,建议先学习下设计模式之后,再学重构可以互相印证的思考和加深两边的知识印象,关联记忆也会提高记忆掌握效果.
当熟悉这些设计模式原则和23种设计模式后,再看本书的一些重构举例,会有一种殊途同归,同源的感觉.

设计模式六大原则(转自:https://www.cnblogs.com/Sam-2018/p/principle.html)
1.单一原则(Single Responsibility Principle):一个类或者一个方法只负责一项职责,尽量做到类的只有一个行为原因引起变化;
a、业务对象(BO business object)、业务逻辑(BL business logic)拆分;
2.里氏替换原则(LSP liskov substitution principle):子类可以扩展父类的功能,但不能改变原有父类的功能;(本质其实就是c++/java的多态)
  (目的:增强程序的健壮性)实际项目中,每个子类对应不同的业务含义,使父类作为参数,传递不同的子类完成不同的业务逻辑。
3.依赖倒置原则(dependence inversion principle):面向接口编程;(通过接口作为参数实现应用场景)
  抽象就是接口或者抽象类,细节就是实现类
  含义:
    上层模块不应该依赖下层模块,两者应依赖其抽象;
    抽象不应该依赖细节,细节应该依赖抽象;
通俗点就是说变量或者传参数,尽量使用抽象类,或者接口;
【接口负责定义public属性和方法,并且申明与其他对象依赖关系,抽象类负责公共构造部分的实现,实现类准确的实现业务逻辑】
4.接口隔离(interface segregation principle):建立单一接口;(扩展为类也是一种接口,一切皆接口)
   定义:
    a.客户端不应该依赖它不需要的接口;
    b.类之间依赖关系应该建立在最小的接口上;
简单理解:复杂的接口,根据业务拆分成多个简单接口;(对于有些业务的拆分多看看适配器的应用)
 【接口的设计粒度越小,系统越灵活,但是灵活的同时结构复杂性提高,开发难度也会变大,维护性降低】   
5.迪米特原则(law of demeter LOD):最少知道原则,尽量降低类与类之间的耦合;
一个对象应该对其他对象有最少的了解  
6.开闭原则(open closed principle):用抽象构建架构,用实现扩展原则;(总纲)
(solid稳定的 记忆首字母)

最后

以上就是超级短靴为你收集整理的《重构 改善既有代码的设计》 第2版前三章观后感重构是什么重构有什么作用何时重构开展重构的流程重构如何学以致用个人感觉重构和设计模式关系的全部内容,希望文章能够帮你解决《重构 改善既有代码的设计》 第2版前三章观后感重构是什么重构有什么作用何时重构开展重构的流程重构如何学以致用个人感觉重构和设计模式关系所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(47)

评论列表共有 0 条评论

立即
投稿
返回
顶部