代码重构的一些感想

最近公司再搞中台化，自己有幸参与其中一个项目的重构，从中学到很多，也有很多感受。

1、准备工作

作为程序猿，重构代码是很常见的一件事。重构代码的目的都是为了让代码更好地适应后续的发展和变化。

当你打算重构代码的时候，你先思考下，你为啥要重构？重构势必要投入一定得时间和人力，在现有的需求的基础上，需要考虑能否稳定抽出时间来进行重构？人力时间抖允可的情况下，当你打算要重构某部分的代码逻辑了，还是得先问自己几个问题，帮助你更好的理清重构的思路：

1. 重构代码逻辑的问题在哪里，你的重构能解决这些问题嘛？
2. 新的架构模式有什么优点，后续产品需求变更，对新的框架改动大吗？
3. 你清楚现有业务逻辑嘛，试用场景，方便后续重构后进行回归验证？

如果这几个问题对你来说都不是大问题，基本上对这部分代码重构，你已经想的比较清楚了。

2、重构设计

1、重构框架

对于框架的重构，你得想清楚旧有的框架都有哪些问题。新框架是完全解决这些问题，还是减少出现这些问题得可能。

对于我负责的这部分业务来说，现有的框架业务逻辑已经比较混乱，两个不同业务场景混用一套代码逻辑，业务逻辑相互杂糅在一起。当你修改某个业务功能，很容易对另一个模块也会造成影响，QA也需要对另一个业务场景回归，造成人力时间的浪费。

刚好趁着中台输出的机会，就准备好好重构一把。

对于我参与的这个项目，相对来说比较简单，整体采用MVP，总体分成三层：接口层，基础层，业务层。

• 接口层：基于其他团队开发的一个服务框架实现的调用接口，主要是对第三方提供调起图片查看器的能力。

• 基础层：整体基于mvp的设计模式，根据现有的业务逻辑，从中抽取通用逻辑放到基础层，根据不同的作用，行成不同的接口来输出。

• 业务层：根据业务，基于基础层，构建不同的业务层，业务层之间互不干扰。

其实，以前也是采用MVP模式，只不过以前没有分层，在业务不断增长的情况下，各种业务逻辑也越来越多，导致整个代码业务逻辑变得更加混乱。

3、代码重构的一些体会

1. 类与类之间的关系理清楚，减少互相之间的依赖。

2. 类A中有比较长的函数的时候，要注意分解。分解的时候要注意局部变量和参数。局部变量过多，可以将其抽到一个类B，这样调用类B就好了。

3. 某个类A包含某个类B，当类A中的某个方法都是和类B相关，就应该把这个方法放到类B中。

4. 重复代码，如果是兄弟类含有相似代码，就抽到父类中；不同类的可以抽取为公共代码。

5. 一个类A比较臃肿，就得抽出另一个类B出来了。可以把某些相关性比较强的属性和方法放到一个新的类B里面。类B应该是在类A里面还是放到外面依据属性而定。

6. 如果函数中临时变量过多，首先是分解临时变量，尽可能变成 final 形式。然后再看看代码如何重构比较好，能否拆分成一些细小的函数粒度。

7. 对于以前的一段代码，如果你发现有更好的写法，那么就用最好的写法。

8. 有时候，为了隐藏实现，会采用代理的形式。可是有时候代理过多，使得代码复杂的时候，又会移除代理，到底是使用还是不使用依据当前的具体形态来定

9. 不要使用魔法数字，使用静态常量。

10. 封装字段变量，建立取值/设值函数。一般情况下，可以可以在类中自由使用直接变量，不用取值/设值函数。但是当存在继承的时候，或者子类需要与父类有区别的时候，这时候，重写取值/设值函数，不影响原有的功能。

11. 开发初期，字段比较简单，直接写在某个类中。到后期功能越来越多的时候，就会很庞大，这时候就需要抽取对象。

12.  重构时最好小步前进，做一次搬移，编译测试，在搬移，在测试。

13. 命名不合理的地方得提出来进行修改；重新命名。

14. 重构过程中，会慢慢发现有些方法变得很剪短，这时候可以考虑要不要在调用的地方用函数本体来替换，这样可以减少方法数，看代码逻辑也清晰。

15. 重构方式，当你要新加一个类的时候，最好的办法是copy原来的类，然后重命名，删除无关的方法和变量，在一步一步慢慢调整。最后当你改完以后，再看看是否每个变量都有用到，或者有些变量是不属于这个新类的。

16. 如何处理依赖。或者说当别人依赖你的时候，你怎么去提供一个好的接口，让别人能够轻松处理，一两行代码足矣。很多其他事都你帮他处理好了。而不是，还要在别人的业务模块添加一大块代码。多从使用方的角度去考虑，现在的方法或者实现是否已经足够简洁了。