重构之度

     再写重构是在CSDN上看到了一篇关于重构软件并不会改善代码质量的文章。一笑了之之后，还想再谈谈个人对重构的看法。

     在我的职业生涯中，有很多重构的经历，最后也都得到了很好的效果，因此，本人谨以自己的经历为例，从重构的法与度两个方面进行一些总结。至于重构的作用与学习思路，可以参见我4年前的两篇文章《在代码重构中蜕变》《再谈对“重构”的学习》。

     本文主要谈重构的程度与度量，另成一文谈重构的方法。

     先来谈谈重构的程度，主要问题就是什么时候应该停止重构。要想回答这个问题，还是得回到重构的目的，要把目的搞清楚。

     如果目的是调整局部的代码可读性，那么当代码易于阅读、易于理解的时候就可以停止了，做得更多，就会适得其反。比如运用函数提取的方式进行代码重构，把重复的语句提取成了小函数，把大段语句分解成了几个小函数，把复杂语句提取成了意义明确的小函数，原来大段的函数已经变为几个小函数的调用了，这时易读性比原来已经好了很多，就可以告一段落。若继续进行下去，把部分小函数分离到另一个类中，再额外封装一层Facade、Helper、Proxy等等，反而陷入复杂的泥潭。

     如果目的是结构调整，那么当调整到结构清晰就可以了，额外引入的过度设计不仅会造成资源的浪费，而且会降低结构的清晰性。

     如果是某个模块分阶段进行，那么当某个阶段完成了一些工作，再进行下去会遇到更大的困难的时候，就可以结束这个阶段了，按调整后的重新梳理相关模块间的关系，设计新的重构方案，而不是从这个模块开始无穷无尽的开展下去。假设要重构A、B、C三个模块，当A模块再重构就会影响B、C的时候就可以停止，把目标放在B、C，直到各自得到了一些改善以后，再回过头来梳理确认是否需要在已经完成的基础上再继续进行一轮。

     恰到好处是艺术，不是科学，是目标，不是结果。

     再来谈谈重构的度量。我们依然得重申一次重构的目标，按Martin Fowler的理论，重构是对代码结构的改善。所以重构的度量就围绕着这个点来进行，而不是运行速度、带宽节约、响应时间等性能指标。

     我们常用的度量指标有代码重复率，可以说明重复代码的情况；复杂度，可以说明类或方法的复杂程度分布；依赖关系，尤其是循环依赖数量，可以说明耦合情况。这里推荐使用SonarQube工具，可以直观的看到这些数据。

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

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

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