一谈到质量目标，很多人第一反应就是“交付后N个月内的代码缺陷率<n bug/KLOC”。大家都知道交付后的缺陷越多客户越不满意，所以都希望通过制定这个目标来反应项目的最终品质。这个想法本身是没有问题的，相应的数据（统一度量标准后）越低的项目也应该反应该项目的最终品质。
但是，这里有几个问题需要更深入的思考一下：
问题1：假设一个项目的n=0.05，另一个项目的n=0.1 。那么，从数据上看，更小的那个项目应该品质更高，但是很有可能觉得品质好的项目会接受到更多的客户投诉。
毕竟，缺陷除了用数量来衡量，还需要用严重程度来衡量的，对于客户来说，他们是不管你的n等于多少的，他关注的是验收时的使用体验。当n=0.05的项目出现了1-2个重大缺陷严重影响了客户的验收使用，那么客户会对此项目留下非常差的印象；而n=0.1的项目如果都是一些很小的缺陷基本不影响客户正常验收使用，那么客户也是可以接受的。
所以，如果我们要制定交付后的品质目标，那么这么描述应该会比较明确一些“交付后N个月的免责维护期内，在没有1级和2级缺陷的前提下，代码的缺陷率小于等于n BUG/KLOC”。（假设我们对缺陷已经分级，1级为严重缺陷，2级为重大缺陷，3级为一般缺陷，4级为轻微缺陷）
这样的描述，明确的界定了缺陷数据采集的时间段、缺陷数据采集的类型以及最终的目标。同类项目会有更多的可比性。
问题2：现在从事软件行业的人都知道缺陷的单位是“BUG/KLOC”，中文表达就是“每千行代码的缺陷数”。缺陷的数量有可比性，但是这千行代码确不是那么容易可比的。
场景A：同一种语言，复用和不复用，代码的规模是有很大差异的。难道复用了1000行代码，自己编写了1000行代码，整个的规模要算2000行吗？ 这和自己编写2000行代码的项目规模是一样的吗？
场景B：同一种语言，重构和不重构，也会存在很大的区别。一个项目有2000行代码，里面有1000行是复制粘贴的代码，其规模是2000行还是1000 行呢？
场景C：不同的语言，在避免场景A和B的情况下，其规模是不具有可比性的。为了完成同一个功能，高级语言和低级语言的行数有量级的差异，不同语言实现起来也有较大的差异。这些项目的缺陷率该如何横向对比呢？
场景D：同一个项目包含多语言实现，那么总体的规模行数该如何描述呢？（现有的Web项目中此场景很常见）
看起来很简单的KLOC在场景A-D中都对我们产生了极大的挑战。我们希望目标数据能衡量项目交付后的品质，但是规模单位没有明确定义时，其数据基本上是没有太大意义的。
要解决这个问题，可以使用两种方法来完成：
方法一：在有良好度量制度和文化的公司，可以针对以上场景，挑选足够数量的项目和人员，通过代码行和工时的统计分析，得到不同语言间的规模比例关系，形成基线，供其它项目使用。但是这种公司目前看起来极少极少，所以大部分公司还是采用方法二比较合适。
方法二：方法一的研究在国外已经进行了几十年，有专门的大学和专门的团队持续跟踪研究，并且也发布其研究结果。他们将不同语言换算成一个标准代码行，称为 SLOC，来统一衡量不同语言的项目规模。他们的数据也许没有方法一中那么精确，但至少可以为我们提供一个统一的方法来实现度量单位的统一，对于中小型软件企业还是很少实用的。此方法可以解决场景C和场景D，下面我列出一些常用的语言的换算表供大家参考：
例：现计算出JSP代码1000行，JAVA代码500行，换算成SLOC=1000*1.36+500*1.52=2120。
场景A需要配置管理工具协助完成，场景B需要重复代码检查工具协助完成。（工具相关内容，我会单独编写一个系列，敬请大家关注。）
综上所述，我们对原来KLOC的定义需要修改为“SKLOC”，同时要规定全部为自行编写/修改的代码且不存在复制粘贴的代码。这样即可统一规模的度量，使不同语言的项目具有横向可比性。当然，自己有能力的企业，还是可以尝试方法一来计算出自己的代码比例关系，这样会更准确一些。
相关文章：
