重构代码的思路和方法

重构前需要考虑

• 全面的了解系统的过去，包括以前的架构/技术背景、业务需求
• 分析以前架构的问题，例如：可维护性低、在哪个方面已经不满足现有需求等等
• 查看至少80%的核心代码，最好有一定时间的真实在以前代码基础上编码的经历

有了上面几点后还需要搞一个有效地重构计划，保证重构有条不紊的进行，才不会出现重构没有动力或者无法推动，或者与其他的业务需求冲突。

重构重点关注

几个比较丑陋的代码：

• 臃肿的类: 类之所以会臃肿，是因为开发者缺乏对最基本的编码原则，即“单一职责原则”（SRP）的理解。这些类往往会变得很臃肿，是由于不同的且在功能上缺少关联的方法都放在了相同的类里面。
• 长方法: 方法之所以会变得很长主要是有以下几个原因：
  1、许多没有关联性的、功能复杂的模块的代码都放在相同的方法内。这主要是开发者缺乏SRP的概念。
  2、多种条件都放在同一个方法内，这在长方法内经常会发生的。这是由于缺乏McCabe代码复杂度和SRP的概念的比较。
• 大量的传参: 我经常遇到这几种情况，一些方法跟另一些方法进行交互，或者调用另一些方法的时候传入大量的参数。这就会出现如果更改了其中一个参数，就得在多个方法内进行更改。
• 常量值无处不在: 经常会发现开发者（尤其是新手）会使用一些具有明确含义的常量值（主要是魔鬼数字），但没有给它们赋予合适的常量变量。这会降低代码的可读性和可理解性。
• 模糊的方法名: 许多时候，以下取的方法名会影响代码的可读性和可理解性：模糊的不具有任何意义的方法名，技术性的，却没有提及