版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/elricboa/article/details/78137931
<div class="markdown_views">
<h3 id="重构前需要考虑"><a name="t0"></a>重构前需要考虑</h3>
- 全面的了解系统的过去，包括以前的架构/技术背景、业务需求
- 分析以前架构的问题，例如：可维护性低、在哪个方面已经不满足现有需求等等
- 查看至少80%的核心代码，最好有一定时间的真实在以前代码基础上编码的经历
有了上面几点后还需要搞一个有效地重构计划，保证重构有条不紊的进行，才不会出现重构没有动力或者无法推动，或者与其他的业务需求冲突。
重构重点关注
几个比较丑陋的代码：
- 臃肿的类: 类之所以会臃肿，是因为开发者缺乏对最基本的编码原则，即“单一职责原则”（SRP）的理解。这些类往往会变得很臃肿，是由于不同的且在功能上缺少关联的方法都放在了相同的类里面。
- 长方法: 方法之所以会变得很长主要是有以下几个原因：
1、许多没有关联性的、功能复杂的模块的代码都放在相同的方法内。这主要是开发者缺乏SRP的概念。
2、多种条件都放在同一个方法内，这在长方法内经常会发生的。这是由于缺乏McCabe代码复杂度和SRP的概念的比较。 - 大量的传参: 我经常遇到这几种情况，一些方法跟另一些方法进行交互，或者调用另一些方法的时候传入大量的参数。这就会出现如果更改了其中一个参数，就得在多个方法内进行更改。
- 常量值无处不在: 经常会发现开发者（尤其是新手）会使用一些具有明确含义的常量值（主要是魔鬼数字），但没有给它们赋予合适的常量变量。这会降低代码的可读性和可理解性。
- 模糊的方法名: 许多时候，以下取的方法名会影响代码的可读性和可理解性：模糊的不具有任何意义的方法名，技术性的，却没有提及相关领域的名称
6个处理上面代码异味的重构方法（手法）
以下是6个可以用来帮助你解决80%（80-20原则）的代码质量问题的重构方法，并能帮助你成为一个更优秀的开发者。
- 提取类/抽离方法：正如上面提到的，像“臃肿的类”（一个类提供了本该有几个类提供的功能）这种代码异味应该将原有类中的方法和属性移动到适当数目的新类中去。旧类中对应新类的方法和属性应该被移除。另外，有时候一些类过于臃肿是因为它包含了被其他类使用本应该是其他类的成员方法的成员方法。这些方法也应该被迁移到合适的类中。
- 提取方法：像上面提到的“过长的方法”这种代码异味可以通过从旧方法中提取代码到一个或多个新方法中消除。
- 分离条件：许多时候，一个方法很长是因为包含好几个分支语句（if-else）。这些分支条件可以被提取和移动到几个单独的方法中。这确实能大大改善代码可读性和可理解性。
- 引入参数对象/保留全局对象：在我做代码审查时发现另外一个很常见的情况 - 好几个参数被传入方法。问题主要与需要从已有方法中增加或者移除一个方法参数有关。在这种场景，建议将相关方法参数组成一个对象（引入参数对象），让方法传递这些对象而不是每个单独的参数。
- 用符号常量替换魔法数字：对于有意义的并且到处被使用的字面常量，应该为它们分配一个命名常量。这能大大增强代码可读性和可理解性。
- 重命名方法：正如上面提到的，模糊不清的方法名会影响代码的可使用性。这些模糊不清的名称应该重命名为有意义的可能与业务术语有关的名称，来帮助开发者通过业务上下文更好地理解代码。这很需要技巧并且要求开发者与业务专家一起协作来理清代码需要满足的业务需求。
重构的方法
代码结构
- 良好的结构组织，MVC，面向接口；
- 风格统一，代码复查，pr->review；
批量、多线程、并行异步
- 异步请求，任务分离，按业务拆分线程池；
- 集中管理，自动配置（spring-task@async）；
缓存、异构化
- Local + 集中缓存，异步刷新、永不过期（mq、task）；
- 数据异构化，别的系统都挂了，自己的系统依然坚挺；
监控治理
- 合理监控，量化报表；
- 报警及时，复盘总结；
重构是一个过程，需要稳步小跑，不能停留，任何一个优秀的系统都是进过无数次重构优化的。
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/elricboa/article/details/78137931
<div class="markdown_views">
<h3 id="重构前需要考虑"><a name="t0"></a>重构前需要考虑</h3>
- 全面的了解系统的过去，包括以前的架构/技术背景、业务需求
- 分析以前架构的问题，例如：可维护性低、在哪个方面已经不满足现有需求等等
- 查看至少80%的核心代码，最好有一定时间的真实在以前代码基础上编码的经历
有了上面几点后还需要搞一个有效地重构计划，保证重构有条不紊的进行，才不会出现重构没有动力或者无法推动，或者与其他的业务需求冲突。
重构重点关注
几个比较丑陋的代码：
- 臃肿的类: 类之所以会臃肿，是因为开发者缺乏对最基本的编码原则，即“单一职责原则”（SRP）的理解。这些类往往会变得很臃肿，是由于不同的且在功能上缺少关联的方法都放在了相同的类里面。
- 长方法: 方法之所以会变得很长主要是有以下几个原因：
1、许多没有关联性的、功能复杂的模块的代码都放在相同的方法内。这主要是开发者缺乏SRP的概念。
2、多种条件都放在同一个方法内，这在长方法内经常会发生的。这是由于缺乏McCabe代码复杂度和SRP的概念的比较。 - 大量的传参: 我经常遇到这几种情况，一些方法跟另一些方法进行交互，或者调用另一些方法的时候传入大量的参数。这就会出现如果更改了其中一个参数，就得在多个方法内进行更改。
- 常量值无处不在: 经常会发现开发者（尤其是新手）会使用一些具有明确含义的常量值（主要是魔鬼数字），但没有给它们赋予合适的常量变量。这会降低代码的可读性和可理解性。
- 模糊的方法名: 许多时候，以下取的方法名会影响代码的可读性和可理解性：模糊的不具有任何意义的方法名，技术性的，却没有提及相关领域的名称
6个处理上面代码异味的重构方法（手法）
以下是6个可以用来帮助你解决80%（80-20原则）的代码质量问题的重构方法，并能帮助你成为一个更优秀的开发者。
- 提取类/抽离方法：正如上面提到的，像“臃肿的类”（一个类提供了本该有几个类提供的功能）这种代码异味应该将原有类中的方法和属性移动到适当数目的新类中去。旧类中对应新类的方法和属性应该被移除。另外，有时候一些类过于臃肿是因为它包含了被其他类使用本应该是其他类的成员方法的成员方法。这些方法也应该被迁移到合适的类中。
- 提取方法：像上面提到的“过长的方法”这种代码异味可以通过从旧方法中提取代码到一个或多个新方法中消除。
- 分离条件：许多时候，一个方法很长是因为包含好几个分支语句（if-else）。这些分支条件可以被提取和移动到几个单独的方法中。这确实能大大改善代码可读性和可理解性。
- 引入参数对象/保留全局对象：在我做代码审查时发现另外一个很常见的情况 - 好几个参数被传入方法。问题主要与需要从已有方法中增加或者移除一个方法参数有关。在这种场景，建议将相关方法参数组成一个对象（引入参数对象），让方法传递这些对象而不是每个单独的参数。
- 用符号常量替换魔法数字：对于有意义的并且到处被使用的字面常量，应该为它们分配一个命名常量。这能大大增强代码可读性和可理解性。
- 重命名方法：正如上面提到的，模糊不清的方法名会影响代码的可使用性。这些模糊不清的名称应该重命名为有意义的可能与业务术语有关的名称，来帮助开发者通过业务上下文更好地理解代码。这很需要技巧并且要求开发者与业务专家一起协作来理清代码需要满足的业务需求。
重构的方法
代码结构
- 良好的结构组织，MVC，面向接口；
- 风格统一，代码复查，pr->review；
批量、多线程、并行异步
- 异步请求，任务分离，按业务拆分线程池；
- 集中管理，自动配置（spring-task@async）；
缓存、异构化
- Local + 集中缓存，异步刷新、永不过期（mq、task）；
- 数据异构化，别的系统都挂了，自己的系统依然坚挺；
监控治理
- 合理监控，量化报表；
- 报警及时，复盘总结；
重构是一个过程，需要稳步小跑，不能停留，任何一个优秀的系统都是进过无数次重构优化的。