SLOC(源代码行)作为度量标准有多糟糕？
我们正在记录我们的软件开发过程.对于技术人员来说,这非常简单:每四周内部里程碑进行迭代开发,每3个月外部一次.
但是,本练习的目的是以他们能够理解的方式为我们的项目管理公开事物.具体而言,这些非技术管理人员需要他们能够理解的指标.
我很了解我们的指标选择,并提出了一整套(满足要求,实际成本与预算成本是我最喜欢的两个).但是,我们确实有一些老手涉及,他们倾向于挂在像SLOC这样的指标上.
我理解SLOC的诱惑:非软件人员似乎很容易理解,这似乎是物理事物中最接近的类比(就像过去计算打孔卡片一样!).
所以这就是问题:如何向非技术人员解释SLOC的危险性？
这里有一些具体的动机:我们致力于一个相当成熟的部署系统,该系统背后有多年的历史.随着我们添加功能,SLOC趋于保持大致水平甚至降低(重构删除旧/死代码,新功能实际上只是对现有功能进行调整等).对于非程序员经理来说,开发项目中不增加的SLOC充其量只是令人困惑....
澄清以下最近的答案:记住,我认为SLOC对于衡量项目进展的目的而言是一个糟糕的指标.我并不是说这是一个不值得收集的数字.它需要广泛的上下文来做任何有用的事情,大多数程序经理都没有这种上下文.
Pet*_*ans 39
有人说:
"使用SLOC测量软件进度就像使用kg测量飞机制造进度一样"
这是完全不合适的,因为它鼓励不良做法,如:
复制粘贴综合征
不鼓励重构以使事情变得更容易
充满无意义的评论
...
唯一的用途是它可以帮助您估算打印完整源树时要放入打印机的纸张数量.
- @Bob Cross:我认为这通常归功于比尔盖茨.(具有讽刺意味的是,考虑到Windows和Office的臃肿怪物.Windows大约有5000万SLOC,Office大约有2.7亿.这超过3亿SLOC,使用2010提供的所有工具,实现了几乎相同的东西Alan Kay和他的团队在1976年做了60*千*SLOC.) (5认同)
- @Bob根据我在网上发现的一篇文章,比尔盖茨:http://www.dev102.com/2008/09/09/measuring-programming-progress-by-lines-of-code/ (3认同)
- 作为衡量标准,它本身就很糟糕.作为导出其他指标的值,它可能很有用,例如预测软件中的缺陷密度. (3认同)
whe*_*ies 19
SLOC的问题在于它是一个简单的游戏指标.高效并不等于生成更多代码.所以我向人们解释Skilldrick所说的方式是这样的:
- 代码行越多,得到的东西越复杂.
- 事情越复杂,理解它就越难.
- 在我添加新功能或修复错误之前,我需要了解它.
- 理解需要时间.
- 时间花钱.
更小的代码 - >更容易理解 - >添加新功能更便宜
Bean计数器可以理解这一点.
- 对于**SLOC作为指标,这是一个很好的论据**.一旦项目成熟,我们应该尝试平稳SLOC计数,而不是让它大幅增加. (2认同)
Ski*_*ick 11
向他们展示以下区别:
for(int i = 0; i < 10; i++) {
print i;
}
和
print 0;
print 1;
print 2;
...
print 9
并询问他们10 SLOC或3 SLOC是否更好.
回应评论:
解释
for循环如何工作不需要很长时间.在向他们展示之后,说"我们现在需要打印最多100个数字 - 这就是你如何做出改变." 并显示更改非DRY代码需要多长时间.
- **我会同意你的看法,第一种情况更好,但"非技术"人士可能会同意第二种情况.并且,它们可能是正确的,第二种情况将编译/运行更快并且需要更少的内存=) (2认同)
- 我同意你和我都看这个例子(或维基百科上的类似)然后说,是的,当然.然而,非程序员看到"胡言乱语"和"更胡言乱语".这有点像在自己的定义中使用一个单词.... (2认同)
- @mkoistinen:编译器可以为你展开循环,如果它实际上是一个好主意.像这样的手动展开循环的臃肿二进制文件通常表现更差,即使直观地看起来计算机应该做的更少"工作". (2认同)
我不同意SLOC是一个糟糕的指标.用十一个答案进入一个多年前的问题可能没有实际意义,但我还是会添加另一个.
大多数论点称之为不好的指标,因为它不适合直接衡量生产力.这是一个奇怪的论点; 它假设指标以疯狂的方式使用.有了这个推理,人们就可以称开尔文为坏单位,因为它不适合测量距离.
代码长度是镇流器的可行措施.
非注释代码行的数量与以下内容相关:
- 未检测到的错误
- 维护费用
- 新贡献者的培训时间
- 迁移成本
- 新功能成本
以及更多类似的成本,例如优化成本.
当然,SLOC计数并不是对这些中的任何一个的精确测量.代码可以介于非常好的和非常难看的任何地方进行管理.但可以假设代码长度很少是免费的,因此,较长的代码通常难以管理.
如果我管理一个程序员团队,我非常想跟踪它创建或删除的镇流器.
很糟糕 (-:
一个更好的想法是覆盖测试用例,而不是代码.
这个想法是这样的:开发人员应该提交一个失败的测试用例,然后在下一个版本中提交修复,测试用例应该通过...只测量开发人员添加的测试用例数量.
作为奖金收集覆盖率统计(分支覆盖率优于线覆盖率).
- 我完全同意测试用例和覆盖率更好。也就是说，我积极拒绝让项目管理人员衡量个人。我们是一个团队，这种事情留在团队内部。 (2认同)