如何保持代码质量–度量代码质量的演变史

序论

       现在应该没有多少人会认为代码质量并不重要。高质量的代码和良好的编码实现方式可以使代码更稳固，且更于维护。统一代码标准可以使代码更容易阅读和理解。测量代码覆盖率也是辨别未测试代码的一种极好方式。本文章的主要内容是有关代码质量的课题，以及它们是如何进化，以及在我们该使用哪些工具来适应软件开发的发展历程。

在这篇文章中，我们将寻求用不同的方法和工具来改善和维持高质量的代码，并且提出有关优秀的编码标准和最佳实践。这些步骤主要包括：

• 手工代码复查
• 自动化度量普通构建过程中的代码质量
• 度量IDE中的代码质量
• 度量持续集成服务器中的代码质量
• 度量跨项目的代码质量

手工代码复查 – 艰辛的道路

 

       可以说当下最有效的方法便是让某人用挑剔的眼光，依托大量的经验，以及在这一领域某个问题的扎实理解，并采用友好的方式来复查你的代码。人为代码复查对于传播代码库方面的知识是很好的表达方式，它能辨认设计和架构的缺陷以及bug，指出生涩或者不可读的代码，并且查看并修正哪些本地代码不符合编码标准。事实上，许多重大的问题就只能通过这一双慧眼识别了。

       结对编程能够很好地适用于这种变化。这种结构化方法的另一种尝试就是正式代码检查。但是利用正式的结构化代码检查的主要问题在于，他们需要耗费很多时间，需要相当严格的纪律和结构，并且以可持续的方式进行。

       借助两个方式的工具可帮助你进行代码复查。 一种方式是使用基于Web的代码复查工具，如gerrit(关于git的在线代码复查)和Crucible(Atlassian的在线代码审查工具)等，除此之外，它们使用来创建代码复查的过程更加轻量级和不那么正式。

      另一种方式的工具能帮助你进行更细致的代码复查。诸如Checkstyle和PMD这样的静态分析工具，能协助辨认与编码标准、命名约定的相关问题和不良编程习惯。在这些问题消除之前，它们将进入代码复查阶段。这样手工审查人员就可以专注于更重要的问题，而不会被一些基本问题诸如不良代码编排或者不合标准的变量命名等来分散注意力。

 

快照视图 – 在你的构建中测量代码质量

 

      代码质量分析工具已经在这一领域存在相当长的时间了。像 Checkstyle 和PMD这样的静态分析工具能够协助执行编码标准(其中在保持你的代码可读性和简洁性发挥重要作用)和最佳实践。FindBugs尝试辨认潜在的编码错误或者不良实践。 像Cobertura 和 Clover这样的代码覆盖率工具能协助隔离未经测试的代码。

      也许你在Maven诞生之前一直都在运用这些工具，但是Maven作为第一流的构建工具，它能把这个些工具都集成进来并自动化其构建过程。事实上，拥有这些工具的Maven插件真的让你没有理由不使用，当然偏见除外。

      Maven还引进了Maven 站点插件，这个创造是具有革命性的。Maven站点生成插件只需很少的配置，就能允许你在一个中心位置(服务器专门站点、Web应用某文件夹)生成一个包含代码质量度量报告的主机。这种做法在开源项目里作为有关项目的一站式技术信息店是非常普遍的。Maven站点的多种代码质量插件可以很容易地报告代码的整理质量或者代码覆盖率指标，并深入到代码这一级以便查看实际问题的详细信息。

 

 

      Maven站点插件能有效地在特定时间点为您的项目生成关于代码质量指标的快照。无论如何，通过Maven能构建强壮的代码质量报告并提供额外的分析功能，正如我们所希望看到的那样，这是在现存代码质量度量领域中更好的工具。

 

即时满足 – 在IDE中的代码质量

 

      基于项目层面的代码质量问题报告对于团队建设而言无疑是最好的-它发出一个强烈的信息：代码质量是非常重要的，它有助于确保人们获取到高质量的代码。项目级别的报告还可以非常有效地用于代码审查会议。

      然而，对于一个经常修正代码质量问题的开发者来说，HTML报告是效率低下的。开发人员最需要的是在代码违反约定或者最佳实践时提供即时反馈。幸运的是，Checkstyle、PMD、Findbugs等等插件已经在Eclipse和其它流行的IDE中存在，同样现在的IDE也有自己内建的代码检查功能，无疑这些功能都是非常有益的。很管用吧！然而值得注意的是，开发者必须在他们的IDE报告和项目报告之间统一编码标准。

 

时间机器 – 随着时间的推移代码质量度量

 

       Maven站点插件作为代码质量度量工具的另一个局限性在于它过于被动。如果你对代码质量度量的要求很高，那么你就应该告诉开发者需认真对待；如果你觉得建立代码标准是值得的，那么就必须坚决执行；如果你对待良好的编程习惯非常严肃，那么你就不应该让没有注释的违规行为获得通过。

       持续集成服务器如Hudson、TeamCity 和Bamboo等都有足够的插件以支持Maven生成代码质量度量报告。具体可通过创建一个作业来专注于代码质量度量。这不仅可以让你报告代码的质量度量，而且还能当构建不稳固时主动通知开发者。比如，Hudson violations plugin和Hudson Cobertura plugin都能让你为你的代码质量度量定义可接受的阀值，然后配置当构建的作业不能满足这个最低值时停止。毫无疑问，这是一个很好的策略。像Checkstyle的工具也是高度可配置，它通过一个优化规则集更加有效地把问题的数量压制至0，并保持新问题的痕迹不会出现在现有的问题集里。

      您搭建在CI服务器中的代码质量报告还会随着时间的推移来记录历史版本的代码质量度量。

 

 

全局视野 – 让我们拥有你的所有度量！

 

      迄今为止，我们现在还没有看到一个能同时满足跨时间和跨项目的代码质量的工具。然而Sonar做到了这一点。Sonar能给你一个非常全局的视野，生成代码质量的度量，同时深入到源代码级。Sonar适用于任何的Maven项目，并使用Maven代码质量报告插件-不过，它可以把规则聚集到Sonar服务器中，这使得它更容易地跨项目实现规则标准化。

      Sonar同样也可以作为代码质量规则的一个中央参考点。你可以在Sonar中定义一个Checkstyle规则集，然后通过Maven构建(将通过你的CI服务器产生度量)和IDE配置两方面来引用它。

 

      然而，尽管Sonar拥有众多的优点，它仍然只是一个被动报告工具。它不会取代你在CI服务器上专门的代码质量度量构建或者适当的IDE集成。

 

结论 – 积极获取有关代码质量！

 

     代码质量度量是维持健康的项目、减少代码维护成本的重要组成部分。测量代码质量度量和在代码问题上确定最佳实践的静态分析工具并不能取代一个很好的人力复查人，有时候他们进行人工复查要容易得多。集成代码质量度量在您的CI构建中–意味着允许你更好的项目级报告，也让你的代码质量度量更加积极主动。最后，Sonar在能在关于度量的全局范围内提供给你全面的跨项目的、汇总的、深度的代码质量报告。

评论

1 楼 codyzhang 2012-03-09  

支持一下~\(≧▽≦)/~啦啦啦  ，希望看到更多精彩文章.....