重构：从方法论到实践
Posted rhwayfunn
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了重构：从方法论到实践相关的知识，希望对你有一定的参考价值。
重构：从方法论到实践
最近部门内部组织了一次大型重构，刚好借着这个机会学习了重构相关的内容，重构可以说代码优化利器，可以很好改善代码结构和开发效率。个人觉得重构应该是随时进行的，开发阶段、测试阶段、上线后，任何时候你觉得代码写得不够好或者有bug都应该重构。
什么是重构
通俗讲就是不影响外界访问的前提下，修改代码的行为。这里的修改代码包括重新设计（业务设计和技术设计）和代码结构的调整。
重构是在不改变软件可观察行为的前提下改善其内部结构
重构通常不是一次性的，它贯穿软件的整个生命周期，只要觉得不合理都是重构的时机。
为什么重构
在接手一个遗留项目的时候，我们往往会遇到以下情况
某甲：代码看了半天还是看不懂啊，尼玛，一个方法上千行，心累ing
若干天后，终于看懂代码了，但是发现IDE一堆警告，一看提示说存在重复的代码，整个项目都是警告，那么多重复代码，不会封装一下吗，靠
试着优化下代码，改着改着发现好多if-else，还是多层嵌套，每个嵌套的判断还TM很复杂，想想还是先不改了，万一改出问题，老子要吃P的（线上故障）
以上情景想必大家一定很熟悉，心底肯定在嘀咕：这么烂的代码哪个孙子写的，不该了，老子重新写一套。。。
其实如果代码在最开始写的时候就考虑设计和扩展问题，并且迭代过程中不断重构，也不会出现上面的问题。这就显得重构在软件开发周期镭显得尤为重要，没有重构，腐败的代码就一直扩散，直到出事。
所以，总结下来，重构有以下好处：
让代码更容易理解
改善内部结构，修改更容易
提高编程速度，加快业务迭代
怎么重构
那么问题来了，怎么开始重构呢？说起来就三步：识别要重构的代码，使用特定手段修改代码，测试
先说第一个也是前提：如何识别代码的“坏味道”：在《重构》一书中提到了很多方面去识别腐败的代码，结合《代码整洁之道》我总结了下，主要有以下方面：
重复代码
解决重复的常用手法有：抽取到单独的函数、放在基类中、使用模板函数模式
模板函数模式是指有一些子类，其中某些函数以相同的顺序执行类似的操作，但各个操作的细节有所不同，不同的子类可以实现自己的操作
如果类存在继承关系，那么适合放在基类中，否则可以创建一个工具类，然后改成直接调用工具类
过长的类或函数
过长的类还是函数，通常意味着做的事情太多，是时候展现真正的技术了，这时候可以拆成多个小类或多个短函数。
拆分类
原则是：单一权责、内聚
常用手法：子类化，如果涉及外部接口的调用，可以抽象出一个接口。
拆分函数
原则是：短小、只做一件事、阅读良好
常用手法：以查询替代临时变量、引入解释性变量、分解临时变量、分解临时变量、移除对参数的赋值、以函数对象替代函数
命名随意
命名随意会导致后期修改理解费劲，徒增烦恼。命名记住一点：名副其实，不要取容易误导的名字
类名应当是名词或者名词短语
函数名应当是动词或者动词短语
无效注释
无效注释包括：废弃的代码、过多的信息、多余的注释。好注释包括以下几种：法律信息、关键代码处解释、警示、TODO、公共API的Javadoc
多个条件判断或switch
这个也很常见，如果遇到这种代码，可以使用多态进行修改，让每种特定类型的子类执行其特定逻辑
其他
在try-catch中用单独的函数封装行为，一段冗长的代码夹在try-catch定位代码没那么直接
一个类中的代码（外部函数调用除外）应该可以从上到下阅读下去，而不用在本类中跳来跳去
实践
在实际的重构中，肯定不是上来就开始修改代码，除非是很小的改动。否则一般需要先梳理既有业务的流程和详细规则，业务梳理后就需要梳理既有技术架构的流程了，梳理后就可以开始评估可以重构的地方，包括业务逻辑统一、技术流程优化、微服务化。
因为重构主要是技术内部的改动，所以梳理既有设计是很有必要的，评估出待修改的点后就可以开始重构了
重构后期还需要进行辅助设计，包括监控、性能优化（缓存、数据库）
扩展
以上内容是自己对重构的一些经验，希望能帮到准备或者已经在重构的小伙伴
以上是关于重构：从方法论到实践的主要内容，如果未能解决你的问题，请参考以下文章