最近公司再搞中台化, 自己有幸参与其中一个项目的重构, 从中学到很多, 也有很多感受.
1, 准备工作
作为程序猿, 重构代码是很常见的一件事. 重构代码的目的都是为了让代码更好地适应后续的发展和变化.
当你打算重构代码的时候, 你先思考下, 你为啥要重构? 重构势必要投入一定得时间和人力, 在现有的需求的基础上, 需要考虑能否稳定抽出时间来进行重构? 人力时间抖允可的情况下, 当你打算要重构某部分的代码逻辑了, 还是得先问自己几个问题, 帮助你更好的理清重构的思路:
重构代码逻辑的问题在哪里, 你的重构能解决这些问题嘛?
新的架构模式有什么优点, 后续产品需求变更, 对新的框架改动大吗?
你清楚现有业务逻辑嘛, 试用场景, 方便后续重构后进行回归验证?
如果这几个问题对你来说都不是大问题, 基本上对这部分代码重构, 你已经想的比较清楚了.
2, 重构设计
1, 重构框架
对于框架的重构, 你得想清楚旧有的框架都有哪些问题. 新框架是完全解决这些问题, 还是减少出现这些问题得可能.
对于我负责的这部分业务来说, 现有的框架业务逻辑已经比较混乱, 两个不同业务场景混用一套代码逻辑, 业务逻辑相互杂糅在一起. 当你修改某个业务功能, 很容易对另一个模块也会造成影响, QA 也需要对另一个业务场景回归, 造成人力时间的浪费.
刚好趁着中台输出的机会, 就准备好好重构一把.
对于我参与的这个项目, 相对来说比较简单, 整体采用 MVP, 总体分成三层: 接口层, 基础层, 业务层.
接口层: 基于其他团队开发的一个服务框架实现的调用接口, 主要是对第三方提供调起图片查看器的能力.
基础层: 整体基于 mvp 的设计模式, 根据现有的业务逻辑, 从中抽取通用逻辑放到基础层, 根据不同的作用, 行成不同的接口来输出.
业务层: 根据业务, 基于基础层, 构建不同的业务层, 业务层之间互不干扰.
其实, 以前也是采用 MVP 模式, 只不过以前没有分层, 在业务不断增长的情况下, 各种业务逻辑也越来越多, 导致整个代码业务逻辑变得更加混乱.
3, 代码重构的一些体会
类与类之间的关系理清楚, 减少互相之间的依赖.
类 A 中有比较长的函数的时候, 要注意分解. 分解的时候要注意局部变量和参数. 局部变量过多, 可以将其抽到一个类 B, 这样调用类 B 就好了.
某个类 A 包含某个类 B, 当类 A 中的某个方法都是和类 B 相关, 就应该把这个方法放到类 B 中.
重复代码, 如果是兄弟类含有相似代码, 就抽到父类中; 不同类的可以抽取为公共代码.
一个类 A 比较臃肿, 就得抽出另一个类 B 出来了. 可以把某些相关性比较强的属性和方法放到一个新的类 B 里面. 类 B 应该是在类 A 里面还是放到外面依据属性而定.
如果函数中临时变量过多, 首先是分解临时变量, 尽可能变成 final 形式. 然后再看看代码如何重构比较好, 能否拆分成一些细小的函数粒度.
对于以前的一段代码, 如果你发现有更好的写法, 那么就用最好的写法.
有时候, 为了隐藏实现, 会采用代理的形式. 可是有时候代理过多, 使得代码复杂的时候, 又会移除代理, 到底是使用还是不使用依据当前的具体形态来定
不要使用魔法数字, 使用静态常量.
封装字段变量, 建立取值 / 设值函数. 一般情况下, 可以可以在类中自由使用直接变量, 不用取值 / 设值函数. 但是当存在继承的时候, 或者子类需要与父类有区别的时候, 这时候, 重写取值 / 设值函数, 不影响原有的功能.
开发初期, 字段比较简单, 直接写在某个类中. 到后期功能越来越多的时候, 就会很庞大, 这时候就需要抽取对象.
重构时最好小步前进, 做一次搬移, 编译测试, 在搬移, 在测试.
命名不合理的地方得提出来进行修改; 重新命名.
重构过程中, 会慢慢发现有些方法变得很剪短, 这时候可以考虑要不要在调用的地方用函数本体来替换, 这样可以减少方法数, 看代码逻辑也清晰.
重构方式, 当你要新加一个类的时候, 最好的办法是 copy 原来的类, 然后重命名, 删除无关的方法和变量, 在一步一步慢慢调整. 最后当你改完以后, 再看看是否每个变量都有用到, 或者有些变量是不属于这个新类的.
如何处理依赖. 或者说当别人依赖你的时候, 你怎么去提供一个好的接口, 让别人能够轻松处理, 一两行代码足矣. 很多其他事都你帮他处理好了. 而不是, 还要在别人的业务模块添加一大块代码. 多从使用方的角度去考虑, 现在的方法或者实现是否已经足够简洁了.
来源: http://www.bubuko.com/infodetail-3122974.html