重构真的能提高代码质量吗？

  与传统观点相反，新的研究发现，想要为了更高效和更具可维护性，而去重组软件代码，我们所花的时间和精力并不一定是值得的。

重构软件，也就是，重组现有的源代码，以使其更高效，更具可读性和可维护性，这可能是所有开发人员时不时在做的一件事情。当然，重构背后隐含的假设 是，将来的收益——可节省的人力物力，要能大于现在投入的成本——所耗费的时间和努力。然而，新的实验研究表明，情况可能并不像你想像得那样美好，重构或 许并不能大幅度地改善软件代码质量，有时候甚至是完全没有起到一点改善作用。

此研究是由研究人员在斯里兰卡完成，近期发表于国际周刊“International Journal of Software Engineering Applications”上，题目为《An Empirical Evaluation of Impact of Refactoring On Internal and External Measures of Code Quality》。目的是测试常见的重构技术是否真的可以改进外部（例如，代码是不是更易于维护？）和内部（例如，代码行数）两个方面的软件质量。

研究人员选择了一个小型的应用程序（约4500行C#代码），原先是Kelaniya大学的教学人员用于制定日程计划和管理在线文档的应用程序。然后在其代码上实施10种常见的重构技术（例如，用子类替换类型码，用多态替换条件语句）。

为了衡量重构对外部软件质量的效果，研究人员从Kelaniya大学，挑了一些懂得面向对象编程和C#的计算机专业的学生。其中一半学生通过可分析性和可变性评价了重构后的代码，而另一半则去评估未重构的代码。

运行每个代码库1000次然后平均结果，来分别衡量重构和非重构代码的执行时间和资源利用。

使用Visual Studio分别计算重构和非重构内部代码的软件质量。这些指标是：可维护性指数、时间复杂度、继承深度、类耦合，以及代码行。

下面是这些研究人员得出的主要结论：

唯一的利好是，有证据表明，重构过的代码的确更易于维护

不过，上述研究结果依然待验证，因为试验对象是一个小样本——一个小型的应用程序和固定的重构技术组。所以，就目前而言，此结果还是别用到实际工作上的好。

作者：小峰

来源：51CTO

如何提高代码质量 说起代码质量，脑子里会冒出很多词，命名规范、格式规范、日志规范、单元测试覆盖率... 但我觉得，代码质量总结起来就两个：好看和好用。 好看是指代码可读性好，容易理解、容易维护，别人接手了不骂你；好用则指代码健壮，不容易出错，机器跑着不骂你。即使出错，也容易定位，容易止损和恢复。
记一次代码重构 # 单一职责 ## 功能单一 功能单一是SRP最基本要求，也就是你一个类的功能职责要单一，这样内聚性才高。 比如，下面这个参数类，是用来查询网站Buyer信息的，按照SRP，里面就应该放置查询相关的Field就好了。 ```java @Data public class BuyerInfoParam { // Required Param private L