重构之度

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/caowenbin/article/details/44103863
     再写重构是在CSDN上看到了一篇关于重构软件并不会改善代码质量的文章。一笑了之之后,还想再谈谈个人对重构的看法。
     在我的职业生涯中,有很多重构的经历,最后也都得到了很好的效果,因此,本人谨以自己的经历为例,从重构的法与度两个方面进行一些总结。至于重构的作用与学习思路,可以参见我4年前的两篇文章《在代码重构中蜕变》《再谈对“重构”的学习》。
     本文主要谈重构的程度与度量,另成一文谈重构的方法

     先来谈谈重构的程度,主要问题就是什么时候应该停止重构。要想回答这个问题,还是得回到重构的目的,要把目的搞清楚。
     如果目的是调整局部的代码可读性,那么当代码易于阅读、易于理解的时候就可以停止了,做得更多,就会适得其反。比如运用函数提取的方式进行代码重构,把重复的语句提取成了小函数,把大段语句分解成了几个小函数,把复杂语句提取成了意义明确的小函数,原来大段的函数已经变为几个小函数的调用了,这时易读性比原来已经好了很多,就可以告一段落。若继续进行下去,把部分小函数分离到另一个类中,再额外封装一层Facade、Helper、Proxy等等,反而陷入复杂的泥潭。
     如果目的是结构调整,那么当调整到结构清晰就可以了,额外引入的过度设计不仅会造成资源的浪费,而且会降低结构的清晰性。
     如果是某个模块分阶段进行,那么当某个阶段完成了一些工作,再进行下去会遇到更大的困难的时候,就可以结束这个阶段了,按调整后的重新梳理相关模块间的关系,设计新的重构方案,而不是从这个模块开始无穷无尽的开展下去。假设要重构A、B、C三个模块,当A模块再重构就会影响B、C的时候就可以停止,把目标放在B、C,直到各自得到了一些改善以后,再回过头来梳理确认是否需要在已经完成的基础上再继续进行一轮。
     恰到好处是艺术,不是科学,是目标,不是结果。

     再来谈谈重构的度量。我们依然得重申一次重构的目标,按Martin Fowler的理论,重构是对代码结构的改善。所以重构的度量就围绕着这个点来进行,而不是运行速度、带宽节约、响应时间等性能指标。
     我们常用的度量指标有代码重复率,可以说明重复代码的情况;复杂度,可以说明类或方法的复杂程度分布;依赖关系,尤其是循环依赖数量,可以说明耦合情况。这里推荐使用SonarQube工具,可以直观的看到这些数据。


     有了度量,对重构的收益和效果才更容易评估,对软件工程管理有非常重要的意义。

     总之,重构不单纯是工具、方法,更应该是一种能力,对重构活动,尤其是架构重构活动的实施,需要提升到架构层面来进行,利用架构师的丰富经验避免重构不足和重构过度,同时利用度量指标进行跟踪评价。

——欢迎转载,请注明原文出处 http://blog.csdn.net/caowenbin ——
——欢迎关注微信号“曹文斌的软件思考”,共同探讨软件人生——


展开阅读全文

没有更多推荐了,返回首页