重构:从方法论到实践

重构:从方法论到实践

最近部门内部组织了一次大型重构,刚好借着这个机会学习了重构相关的内容,重构可以说代码优化利器,可以很好改善代码结构和开发效率。个人觉得重构应该是随时进行的,开发阶段、测试阶段、上线后,任何时候你觉得代码写得不够好或者有bug都应该重构。

什么是重构

通俗讲就是不影响外界访问的前提下,修改代码的行为。这里的修改代码包括重新设计(业务设计和技术设计)和代码结构的调整。

重构是在不改变软件可观察行为的前提下改善其内部结构

重构通常不是一次性的,它贯穿软件的整个生命周期,只要觉得不合理都是重构的时机。

为什么重构

在接手一个遗留项目的时候,我们往往会遇到以下情况

某甲:代码看了半天还是看不懂啊,尼玛,一个方法上千行,心累ing

若干天后,终于看懂代码了,但是发现IDE一堆警告,一看提示说存在重复的代码,整个项目都是警告,那么多重复代码,不会封装一下吗,靠

试着优化下代码,改着改着发现好多if-else,还是多层嵌套,每个嵌套的判断还TM很复杂,想想还是先不改了,万一改出问题,老子要吃P的(线上故障)

以上情景想必大家一定很熟悉,心底肯定在嘀咕:这么烂的代码哪个孙子写的,不该了,老子重新写一套。。。

其实如果代码在最开始写的时候就考虑设计和扩展问题,并且迭代过程中不断重构,也不会出现上面的问题。这就显得重构在软件开发周期镭显得尤为重要,没有重构,腐败的代码就一直扩散,直到出事。

所以,总结下来,重构有以下好处:

让代码更容易理解

改善内部结构,修改更容易

提高编程速度,加快业务迭代

怎么重构

那么问题来了,怎么开始重构呢?说起来就三步:识别要重构的代码,使用特定手段修改代码,测试

先说第一个也是前提:如何识别代码的“坏味道”:在《重构》一书中提到了很多方面去识别腐败的代码,结合《代码整洁之道》我总结了下,主要有以下方面:

重复代码

解决重复的常用手法有:抽取到单独的函数、放在基类中、使用模板函数模式

模板函数模式是指有一些子类,其中某些函数以相同的顺序执行类似的操作,但各个操作的细节有所不同,不同的子类可以实现自己的操作

如果类存在继承关系,那么适合放在基类中,否则可以创建一个工具类,然后改成直接调用工具类

过长的类或函数

过长的类还是函数,通常意味着做的事情太多,是时候展现真正的技术了,这时候可以拆成多个小类或多个短函数。

拆分类

原则是:单一权责、内聚

常用手法:子类化,如果涉及外部接口的调用,可以抽象出一个接口。

拆分函数

原则是:短小、只做一件事、阅读良好

常用手法:以查询替代临时变量、引入解释性变量、分解临时变量、分解临时变量、移除对参数的赋值、以函数对象替代函数

命名随意

命名随意会导致后期修改理解费劲,徒增烦恼。命名记住一点:名副其实,不要取容易误导的名字

类名应当是名词或者名词短语

函数名应当是动词或者动词短语

无效注释

无效注释包括:废弃的代码、过多的信息、多余的注释。好注释包括以下几种:法律信息、关键代码处解释、警示、TODO、公共API的Javadoc

多个条件判断或switch

这个也很常见,如果遇到这种代码,可以使用多态进行修改,让每种特定类型的子类执行其特定逻辑

其他

在try-catch中用单独的函数封装行为,一段冗长的代码夹在try-catch定位代码没那么直接

一个类中的代码(外部函数调用除外)应该可以从上到下阅读下去,而不用在本类中跳来跳去

实践

在实际的重构中,肯定不是上来就开始修改代码,除非是很小的改动。否则一般需要先梳理既有业务的流程和详细规则,业务梳理后就需要梳理既有技术架构的流程了,梳理后就可以开始评估可以重构的地方,包括业务逻辑统一、技术流程优化、微服务化。

因为重构主要是技术内部的改动,所以梳理既有设计是很有必要的,评估出待修改的点后就可以开始重构了

重构后期还需要进行辅助设计,包括监控、性能优化(缓存、数据库)

扩展

以上内容是自己对重构的一些经验,希望能帮到准备或者已经在重构的小伙伴

你可能感兴趣的:(java开发问题分析,Clean,Code)