《《重构2》这本书是我觉得非常有必要看的,对于自己写代码有着比较大的影响,力荐。结合书中和自己实践提炼和总结一些内容分享出来。重构分为服务级别的重构和代码级别的重构,《重构2》这里面主要是说代码级别的。强如阿里,发展的过程中也会出现臃肿问题,后续他们把服务进行了分布式改造和服务化改造。如下摘抄《淘宝技术这10年》的原话。
1. 为什么重构
1.1 重构是什么
重构指在不改变代码外在行为的前提下,对代码做出修改,以改进程序的内部结构。
1.2 重构的作用
a、改进软件设计。
b、使软件(代码)更容易理解。 c、帮助找到bug。
d、提高编程速度。
2. 何时重构
2.1 简单来说,重构不需要刻意去安排时间,不用为了重构而重构,重构是为了把某件事情更好地完成;
2.2 三次法则,即事不过三,同样的程序出现多次就可以考虑重构了;
2.3 添加新功能时重构;
2.4 修补问题功能时重构;
2.5 复审代码时重构;
3. 重构什么
3.1 神秘的命名
命名不合理给阅读带来很大的困扰。给方法、模块、变量和类一个好的名字,才能清晰地表达相应的功能和用法。
3.2 重复的代码
一旦有重复代码存在,阅读这些重复的代码时你就必须加倍仔细,留意其间细微的差异。如果要修改重复代码,你必须找出所有的副本来修改。
3.3 过长的方法
方法越长,就越难理解。越不好维护。
3.4 过长的参数列表
过长的参数,不好理解和维护。
3.5 数据泥团
常常可以在很多地方看到相同的三四项数据:两个类中相同的字段、许多方法签名中相同的参数。这些总是绑在一起出现的数据应该拥有属于它们自己的对象。
3.6 循环语句
循环已经有点儿过时,看是否能用stream替代
3.7 冗赘的元素
可能有这样一个方法,它的名字就跟实现代码看起来一模一样;也可能有这样一个类,根本就是一个简单的方法。起初在编写这个方法时,期望它将来有一天会变大、变复杂,但那一天从未到来。
3.8 夸夸其谈通用性
当有人说“噢,我想我们总有一天需要做这件事”,并企图以各式各样的钩子和特殊情况来处理一些非必要的事情,这种坏味道就出现了。这么做的结果往往造成系统更难理解和维护。
3.9 临时字段
类内部某个字段仅为某种特定情况而设。这样的代码有时让人不易理解。
3.10 过大的类
如果想利用单个类做太多事情,其内往往就会出现太多字段。一旦如此,重复代码也就接踵而至了。
3.11 注释
有时候注释为了掩盖代码的坏味道,作为“除臭剂”使用了。有时注释就作为一个有坏味道的信号了。
4. 重构的技巧
4.1、提炼方法;(反向重构-内联方法)
使用场景如:方法过长、代码复用的角度
一个很好的技巧是:寻找注释。就算只有一行代码,如果它需要以注释来说明,那也值得将它提炼到独立方法中去。
4.2 提炼变量(反向重构-内联变量)
如果表达式非常复杂而难以阅读。这种情况下,局部变量可以帮助我们将表达式分解为比较容易管理的形式。
4.3 引入参数对象
使用场景:数据泥团
4.4 以查询取代临时变量
使用场景:取代临时变量、方便提炼方法
4.5 提炼类 (反向重构-内联类)
使用场景:数据泥团。一般类随着责任不断增加,这个类会变得过分复杂。很快,你的类就会变成一团乱麻。
4.6 拆分循环
让循环只做一件事情,但如果你在一次循环中做了多件不同的事,那么每当需要修改循环时,你都得同时理解这多件事情。拆分循环有利于系统的完善。但是有一点,重构完成之后,如果确实发现会造成性能问题,再合并回来。一般情况下,循环本身也很少成为性能瓶颈。
4.7 stream替换循环
使用场景:stream好处是,允许我们去表达我们想要完成什么而不是要怎样做
4.8 移除死代码
使用场景:无用代码确实会带来很多额外的思维负担。有可能以后又会需要这段代码,就算真的发生,可以从版本控制系统里再次将它翻找出来。
4.9 拆分变量
其他的如果它们被赋值超过一次,就意味它们在函数中承担了一个以上的责任。同一个变量承担两件不同的事情,降低可读性。
4.10 分解条件表达式 (反向重构-合并条件表达式)
将每个分支条件分解成新函数可以带来更多好处:可以突出条件逻辑,更清楚地表明每个分支的作用,并且突出每个分支的原因。
4.11 以卫语句取代嵌套条件表达式
卫语句取代嵌套条件表达式的精髓就是:给某一条分支以特别的重视。如果使用if-else结构,你对if分支和else分支的重视是同等的。
4.12 以命令取代方法 (反向重构-以方法取代命令)
适用场景例如:过长方法,命令对象提供了更大的控制灵活性和更强的表达能力
4.13 方法上移 (反向重构-方法下移)
避免重复代码
4.14 提炼超类
如果我看见两个类在做相似的事,可以利用基本的继承机制把它们的相似之处提炼到超类。
4.15 委托取代子类 (类似-委托取代超类)
继承给类之间引入了非常紧密的关系。与继承关系相比,使用委托关系时接口更清晰、耦合更少。
5. 测试帮助重构
要正确地进行重构,前提是得有一套稳固的测试集合,以帮我发现难以避免的疏漏,这点很重要,只要这方面吃过亏就能认识到。
还有一个问题就是重构代码短期间收益不高,很不容易出kpi,如果上头不是很认可,其实这个工作很不好做,改得不好很容易背锅。