SLOC（源代码行）作为衡量标准有多糟糕？ [关闭]答案

【问题标题】：How bad is SLOC (source lines of code) as a metric? [closed]SLOC（源代码行）作为衡量标准有多糟糕？ [关闭]
【发布时间】：2011-04-15 17:52:39
【问题描述】：

我们正在记录我们的软件开发过程。对于技术人员来说，这很容易：迭代开发，内部里程碑每 4 周一次，外部每 3 个月一次。

但是，此练习的目的是为我们的项目管理人员以他们可以理解的方式揭示事物。具体来说，这些非技术经理需要他们能够理解的指标。

我非常了解我们的指标选项，并提出了一整套建议（满足要求和实际成本与预算成本是我最喜欢的两个）。但是，我们确实有一些老手参与其中，他们倾向于坚持使用 SLOC 等指标。

我理解 SLOC 的诱惑：对于非软件人员来说，它似乎很容易理解，而且它似乎是最接近物理事物的模拟物（就像过去计算打孔卡一样！）。

那么问题来了：我如何向非技术人员解释 SLOC 的危险？

以下是一些具体的动机：我们致力于开发一个相当成熟的部署系统，该系统拥有多年的历史。当我们添加功能时，SLOC 往往会保持大致水平甚至下降（重构会删除旧/死代码，新功能实际上只是对现有功能的调整等）。对于非程序员经理来说，开发项目中不增加的 SLOC 充其量是令人困惑的......

澄清以下最近的回答：请记住，我认为 SLOC 是衡量项目进度的糟糕指标。我并不是说这是一个不值得收集的数字。它需要广泛的上下文来做任何有用的事情，而大多数项目经理没有这种上下文。

【问题讨论】：

如果你想在某处钉钉子，你会数锤子的敲击次数吗？
“你能从页数看出一本书有多好吗？”
SLOC 非常好的指标！！ ...因为事情有多糟糕。您拥有的 SLOC 越多，您所处的位置就越差。
告诉他们“1 行代码”是最糟糕的“2 行\n 代码”。
我知道这是一个老问题，但我认为它仍然高度相关！我们对框架的抽象程度越高，SLOC 对于衡量生产力就越没有意义。

标签： code-metrics

【解决方案1】：

相当糟糕（-：

一个更好的主意是覆盖测试用例，而不是代码。

这个想法是这样的：开发人员应该提交一个失败的测试用例，然后在下一次构建中提交修复，并且测试用例应该通过......只需测量开发人员添加了多少测试用例。

作为奖励，收集覆盖率统计数据（此处的分支覆盖率优于线路覆盖率）。

【讨论】：

我完全同意测试用例和覆盖率更好。也就是说，我积极拒绝让项目管理人员对个人进行衡量。我们是一个团队，这种事情留在团队内部。

【解决方案2】：

向他们展示两者之间的区别：

for(int i = 0; i < 10; i++) {
    print i;
}

和

print 0;
print 1;
print 2;
...
print 9

并询问他们是 10 SLOC 还是 3 SLOC 更好。

回应cmets：

很快就会解释for 循环的工作原理。
在您向他们展示此内容后，请说“我们现在需要打印最多 100 个数字 - 这是您进行更改的方法。”并显示更改非 DRY 代码需要多长时间。

【讨论】：

我同意你的观点，第一种情况更好，但“非技术人员”可能会同意第二种情况。而且，他们可能是对的，第二种情况将编译/运行更快并且需要更少的内存 =)
我同意你和我都看这个例子（或维基百科上的类似例子）并说，是的，当然。但是，非程序员会看到“胡言乱语”和“更多胡言乱语”。这有点像在自己的定义中使用一个词......
@mkoistinen：如果这确实是个好主意，编译器可以为您展开循环。像这样带有手动展开循环的臃肿二进制文件通常表现更差，尽管从直觉上看，计算机似乎应该做更少的“工作”。
@mkoistinen 第二个例子更好？？你确定吗，如果你做了一千万，一千万，你会花一整天时间输入别人需要 10 秒才能输入的代码吗？你是不是要多花1000万美元买一个1000万版本的人，它和三行版本做同样的事情，更不用说1000万行版本不能缩放，而三行版本可以....
@YunfeiChen 你在回复我 10 年前发表的评论。

【解决方案3】：

有人说：

“用 SLOC 衡量软件进度就像用 kg 衡量飞机制造进度”

这是完全不合适的，因为它会鼓励不良做法，例如：

复制粘贴综合症
不鼓励重构以使事情变得更容易
用无意义的 cmets 填充
...

唯一的用途是，当您打印完整的源代码树时，它可以帮助您估算要在打印机中放入多少纸张。

【讨论】：

我以前听过这个评论，但不知道引文。你有它的参考吗？
@Bob 根据我在网上找到的一篇文章是比尔盖茨：dev102.com/2008/09/09/…
@Bob Cross：我认为这通常归功于比尔盖茨。（这有点讽刺，考虑到 Windows 和 Office 是多么臃肿的怪物。Windows 大约有 5000 万个 SLOC，Office 大约有 2.7 亿个。这超过 3 亿个 SLOC，使用 2010 提供的所有工具来实现几乎相同的目标Alan Kay 和他的团队在 1976 年做到了 60 000 SLOC。）
作为一个指标本身就很糟糕。作为派生其他指标的值，它可能很有用，例如预测软件中的缺陷密度。
比尔盖茨从未说过“640K 应该对任何人都足够”。 wired.com/politics/law/news/1997/01/1484

【解决方案4】：

通过放置额外的空行（“为了便于阅读”）或放置或删除 cmets，可以显着改变 SLOC。所以只依赖 SLOC 会导致混乱。

【讨论】：

空白（额外行）和/或 cmets 不计入 SLOC。
这不是非技术人员需要知道的。

【解决方案5】：

【讨论】：

当然，如果你尝试的话，很容易在任何事情上看到 Dilbert。也就是说，我们不能只说“所有指标都是愚蠢的”。我们必须提出更好的建议。也就是说，SLOC 绝对是愚蠢的。
您可以编辑条带以删除面板 3、4 和 5。然后消息将变得更少“指标是愚蠢的”而更多的是“考虑不周的指标是愚蠢的”，以及 SLOC 和PHB 的“字数”指标将保持清晰。
我们必须减去您删除的面板。
如果你足够努力，我的直觉会同意一切都是可以衡量的，这很糟糕吗？ SLOC 是一个绝对糟糕的指标，但这并不意味着没有相关指标。
@JoshLee 我们将不得不减去您删除的错误...我认为这应该更多与编程相关...

【解决方案6】：

为什么 SLOC 不能作为衡量生产力的单个指标

将代码想象成一块粘土/石头。你需要雕刻，比如说 10 个雕像。重要的不是你雕刻了多少雕像。重要的是你雕刻得有多好。同样，重要的不是你写了多少行，而是它们运行得有多好。如果代码 LOC 可以通过这种方式作为指标适得其反。

编写复杂代码时，工作效率也会发生变化。编写打印语句需要一秒钟，但编写复杂的逻辑需要很多时间。并非所有手指都是平等的。

如何利用 SLOC 为您带来好处

我认为缺陷百分比的 SLOC 是一个很好的指标。是的，难度级别发挥了作用，但这是一个很好的参数，经理们可以在做生意时扔掉。试着从他们的角度思考。他们不讨厌你或你的工作，但他们需要告诉客户你是最好的，为此他们需要一些有形的东西。给他们你能做的:)

【讨论】：

用现代语言来说，感觉SLOC的粒度太细了。示例：Findbugs 报告每个 Java 类和包的错误。这更有用——我们可以查看一个类列表并说“这是最差的类/包”，我们应该集中精力。每行代码的错误很难采取行动 - 我们应该怎么做？
@Bob 如果您有更好的指标，那么坚持 SLOC 是没有意义的。您可以向经理解释这一点。为什么他们仍然对它感到震惊是因为该行业仍然坚持它。告诉他们，从 QA 的角度来看，最好有 findbug 类型的报告。尝试了解“他们”的关注点，如果是内部监控，他们会同意 findbugs，如果是外部监控，他们仍然需要 SLOC，因为这是客户所理解的。
@Sidarth，如果不清楚，一些相关人员是客户。他们不够精明，无法理解 Findbugs（尤其是因为他们正在此类别中寻找“大小”指标）——他们不是我们领域的技术人员。
连我都不知道 FindBugs 是什么，而且我是一名从事软件开发的 C++ 程序员，它是在代码中查找 bug 的新工具还是 IDE 之类的？？

【解决方案7】：

您不能根据飞机的重量 (sloc) 来判断飞机的好坏（有多少功能，性能如何......）。

如果您希望您的飞机飞得更高、更长、性能更好，就不要增加它的重量。你用更轻/更好的材料替换它的一部分。去掉不需要的部分，以免增加不必要的重量。

【讨论】：

“用代码行衡量编程进度就像用重量衡量飞机制造进度。” ——比尔盖茨

【解决方案8】：

SLOC 的问题在于它是一个简单的游戏指标。高效并不等于生产更多代码。所以我向人们解释 Skilldrick 所说的方式是这样的：

代码行数越多，事情就越复杂。
事情越复杂，就越难理解。
在添加新功能或修复错误之前，我需要了解它。
理解需要时间。
时间成本。

更小的代码 -> 更容易理解 -> 添加新功能更便宜

豆类计数器可以理解。

【讨论】：

好的，这 5 个步骤的过程实际上非常引人注目。谢谢。
这是一个很好的论据对于 SLOC 作为一个指标。一旦一个项目成熟了，我们就应该尝试稳定 SLOC 数量，而不是让它疯狂增加。

【解决方案9】：

为什么他们不明白 SLOC 没有改变，但软件比昨天做得更多，因为您添加了新功能或修复了错误？

现在像这样向他们解释。通过比较代码行来衡量你的代码完成了多少工作与衡量手机中有多少功能是通过大小比较来衡量的。 20 多年来，手机尺寸不断缩小，同时由于技术改进和技术增加了更多功能。好的代码遵循同样的原则，因为我们可以用越来越少的代码行来表达相同的逻辑，使其运行更快、更容易维护、更容易理解，因为我们提高了对问题的理解并引入了新的开发技术。

我会让他们专注于通过功能开发、维护和错误修复返回的业务价值。如果对软件感到满意的人说他们可以看到改进，请不要担心 SLOC。

去读吧：

https://stackoverflow.com/questions/3800707/what-is-negative-code

【讨论】：

【解决方案10】：

说明 SLOC 是衡量应用程序中代码行数的绝佳指标，仅此而已。

一本书的行数或一部电影的长度并不'不确定它有多好。您可以改进电影并缩短它，您可以改进应用程序并减少代码行数。

【讨论】：

我同意你和我会理解这个长度！=更好。但是，对于习惯于需要生产很长电缆（例如）的项目的非技术人员来说，长度是他们理解的衡量标准。细分是软件==知识。它没有物理模拟。

【解决方案11】：

即使是现代代码度量工具也会批评 SLOC conting，我喜欢 ProjectCodeMeter FAQ 中提出的观点：

What's wrong with counting Lines Of Code (SLOC / LLOC)?

【讨论】：

【解决方案12】：

我不同意 SLOC 是一个糟糕的指标。回答一个有 11 个答案的老问题可能没有实际意义，但我还是会添加另一个。

大多数论点称其为糟糕的指标，因为它不适合直接衡量生产力。这是一个奇怪的论点；它假定该指标以疯狂的方式使用。有了这个推理，人们可以称开尔文为一个糟糕的单位，因为它不适合测量距离。

代码长度是镇流器的一种可行度量。

非注释代码行的数量与：

未检测到的错误
维护费用
新贡献者的培训时间
迁移成本
新功能成本

还有更多类似的成本，例如优化成本。

当然，SLOC 计数并不是对其中任何一项的精确衡量。代码可以在非常好和非常难管理之间的任何地方进行管理。但可以假设代码长度很少是免费的，因此，较长的代码通常更难管理。

如果我管理一个程序员团队，我非常想跟踪它创建或移除的镇流器。

【讨论】：

如果您阅读了我的问题的最后一段（以及几个答案），您会发现同意您的观点。测量 SLOC 是一个好主意（并且可以自动处理）：例如，在测量测试覆盖率时。我继续争论（大多数答案也是如此）是“新编写的 SLOC”不是项目进度的良好指标。如果您可以实现更多接近零 SLOC 增加的需求，那么您每行代码的价值就会增加。
@BobCross 我想我们都同意。关注 SLOC 确实意味着什么而不是它没有意味着什么可能会更好。那更具建设性；经理们得到他们的指标，这确实很有用，并学习如何解释它。它是否直接衡量生产力的问题几乎不需要额外提及。
感谢您的建议。如果您重新阅读最初的问题，我建议使用两个比 SLOC 更好地向项目管理传达进度和价值的指标。最初的问题集中在惰性指标的问题上：相当于计算打孔卡并称其为进步。
@Vandroiy 更具建设性，编写冗余重复代码并引入更难调试的代码更具建设性？？？

【解决方案13】：

我相信 SLOC 是一个很好的指标。它告诉你你的系统有多大。这有利于判断复杂性和资源。它还可以帮助您为下一个开发人员准备代码库。

但只有在应用了其他适当的代码质量指标之后，才应分析 SLOC 计数。所以...

不要写 2 行代码，而 1 行，除非 2 行版本使代码易于维护 2 倍。
不要仅仅为了弄乱 SLOC 计数而使用不必要的 cmets 弄乱代码。
不要按 SLOC 计数付钱。

我管理软件项目已有 30 年了。我一直使用 SLOC 计数，以帮助了解成熟的系统。在项目接近 1.0 版本之前，我从来没有发现查看 SLOC 计数很有用。

基本上，在开发过程中，我担心质量、性能、可用性和是否符合规范。做对了，这个项目很可能会成功。尘埃落定后，查看 SLOC 计数。你可能会惊讶于你从 5000 行代码中得到了这么多。你可能会惊讶于你得到的这么少！（但 SLOC 计数不会影响质量、性能、可用性和对规范的符合性。）

并且总是像下一个将编写代码的人一样编码是一个知道你住在哪里的暴力精神病患者。

干杯，芯片大叔

【讨论】：

我不同意你的第一点，Do NOT write 2 lines of code when 1 will do, unless the 2-line version makes the code 2 times easier to maintain.
按照这个逻辑，选择排序是最好的排序算法，因为它是最短的，不需要快速排序、堆排序和合并排序......
快速排序比大 n 的选择排序快 2 倍以上。 n^2 与 nlogn。