5个权衡软件质量的尺度（可主动化）

   1、Sourc Lines of Code（SLOC）

统计代码行数多是最俭朴的方式。它能表现软件的范围，为项目的生长和打算供应一些数据支持。例如，我们每一个月统计一次代码的行数，我们就能够年夜体明白项目的生长环境。固然，这不是一个值得置信的尺度，由于有重构和想象的身分。

SLOC 最好是统计 Source Logical Line of Code （SLLOC） 以获得更准确的信息。Logical code lines 不包括空行，单个括号行和正文行。你能够经由过程 Metrics 多么的东西很随便的统计 SLLOC。

代码行数不该该被用来权衡开拓效能。不然随便构成重复的，不容易维护的和不专业的代码。

2、Bugs per code_section/module/time_period

标题跟踪是包管测试和可维护性的关头步伐。假定一切的标题（bug）都是有跟踪的话，每一个代码单位，每一个模块或某个特按时间（day， week， month...）的标题就很随便被统计（例如 Mantis 东西）。当我们有了这些数据今后，标题的根源便能够被尽早发现并处置。

标题数目能够作为权衡开拓质量的一个尺度，但必需用的很慎重。假定过度夸张 bug 数目，那末开拓和测试的关头就会很严重。在一个有用率的公司，一切的员工都应当调和的相处。

为了更好的对代码质量中止评价。Bug 能够分为 low， medium， high 三种级别，由于它们的主要性和修复的本钱是纷歧样的。

3、Code Coverage

Code coverage 表白了代码被测试的程度。有良多东西能够主动统计这个数据，例如 Cobertura 。

Code coverage 不克不及声明单位测试的全体质量，可是能声明测试的笼盖面。它能够和其他一些目的一路用来权衡软件的质量。固然，我们也需求常常回首单位测试代码和集成测试的用例。

4、Design/Development Contraints

软件开拓中有良多想象规律，例如：

- 类/方式的长度

- 方式/属性的数目

- 方式的参数数目

- 特别数值和字符串的应用量

- 正文的比例

这些规律都是包管代码可读性和可维护性的主要目的。开拓团队应中选择一些或全数的规律来实行（例如 maven pmd plugin ）。这将帮助进步软件产物的质量。

5、Cyclomatic Complexity（环路复杂度）

把环路复杂度零丁列出来说是由于它和其他的想象准侧不太一样。环路复杂度是关于代码完成和实行。它也可以经由过程东西主动计较，例如 pmd 。

这个数值是自力的代码实行途径数目。例如：

Cyclomatic Complexity = E(edges) - N(nodes) + 2P (exit nodes)

So, Cyc.Cmp. = 8 - 7 + 2*1 = 3

你也可以看到，从动身点到起点，有三条分歧的途径。这个值常常是针对方式来计较。依照分歧的项目类型，我们能够设定这个值的下限，例如6,8，或10。

一个目的不克不及声明全部项目的质量。应用更多的目的，会让你对项目的质量有更周全的体会。