Question

我们正在记录我们的软件开发过程。对于技术人员来说，这非常简单：每四周内部里程碑进行迭代开发，每3个月外部一次。

然而，本练习的目的是以他们能够理解的方式揭示项目管理的内容。具体而言，这些非技术经理需要他们能够理解的指标。

我理解我们对指标的选择并提出了一整套（满足要求，实际成本与预算成本是我最喜欢的两个）。但是，我们确实有一些老手涉及，他们倾向于挂在像SLOC这样的指标上。

我理解SLOC的诱惑：非软件人员似乎很容易理解，这似乎是物理事物的最接近的类比（就像过去计算打孔卡一样！）。

所以这就是问题：如何向非技术人员解释SLOC的危险？

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

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

Answer 1

有人说：

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

这是完全不合适的，因为它鼓励了诸如以下的不良行为：

复制粘贴-综合征
阻止重构以使事情变得更容易
填充无意义的评论
...

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

Answer 2

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

代码越多，得到的东西越复杂。
事情越复杂，理解就越难。
在添加新功能或修复错误之前，我需要了解它。
理解需要时间。
时间花钱。

较小的代码 - ＆gt;更容易理解 - ＆gt;添加新功能更便宜

Bean计数器可以理解。

Answer 3

向他们展示：

之间的区别

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

和

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

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

回应评论：

解释for循环如何工作不需要很长时间。
向您展示后，请说“我们现在需要打印最多100个数字 - 以下是您进行更改的方式。”并显示更改非DRY代码需要多长时间。

Answer 4

我不同意SLOC是一个糟糕的指标。用十一个答案进入一个多年的问题可能没有实际意义，但我仍然会添加另一个答案。

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

代码长度是镇流器的可行措施。

非评论代码行的数量与：

相关联

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

以及更多类似的成本，例如优化成本。

当然，SLOC计数并不是这些中任何一项的精确衡量标准。代码可以介于非常好的和非常难看的任何地方进行管理。但可以假设代码长度很少是免费的，因此，更长的代码通常更难管理。

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

Answer 5

非常糟糕（ - ：

更好的想法是覆盖测试用例，而不是代码。

这个想法是这样的：开发人员应该提交一个失败的测试用例，然后在下一个版本中提交修复，测试用例应该通过......只测量开发人员添加的测试用例数。

作为奖金收集覆盖率统计数据（分支机构覆盖率优于线路覆盖率）。

Answer 6

说明SLOC是应用程序中代码行的一个很好的衡量标准，别的。

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

Answer 7

你不判断一架飞机的重量（sloc）有多好（多少特征，它的表现如何......）。

当您希望您的飞机飞得更高，更长并且表现更好时，您不会增加它的重量。用更轻/更好的材料更换部件。你剥掉了你不需要的部分，以免增加不必要的重量。

Answer 8

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

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

除非2行，否则不要写1行代码版本使代码更容易维护2次。
请不要为不必要的评论填写代码，只是为了使SLOC数量减少。
不要按SLOC支付人数。

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

基本上，在开发过程中，我担心质量，性能，可用性和规范的一致性。做到这一点，项目可能会取得成功。当尘埃落定时，请查看SLOC计数。你可能会惊讶于你从5,000行代码中获得了很多。而你可能会感到惊讶，因为你有点小！（但SLOC计数不会影响质量，性能，可用性和规范的一致性。）

总是编码就像接下来将会处理你的代码的人一样，是一个知道你住在哪里的暴力精神病患者。

干杯，芯片叔叔

Answer 9

为什么SLOC作为单独的生产力指标

将代码视为一块粘土/石头。你需要雕刻，比如10个雕像。这不是你雕刻的雕像数量。这是你雕刻它的重要性。同样地，不是你写了多少行，而是它们的运作情况。在代码的情况下，LOC可以通过这种方式适得其反。

编写复杂的代码时，生产力也会发生变化。编写一个打印语句需要一秒钟，但需要花费大量时间来编写复杂的逻辑。并非所有手指都是平等的。

SLOC如何用于您的利益

我认为缺陷％SLOC是一个很好的指标。是的，难度水平发挥作用，但这是一个很好的参数，经理可以在做生意时抛出。试着从他们的角度思考。他们不讨厌你或你的工作，但他们需要告诉客户你是最好的，因为他们需要有形的东西。给他们你能做的：）

Answer 10

即使是现代代码指标工具也批评SLOC conting，我喜欢ProjectCodeMeter FAQ中的观点：

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

Answer 11

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

Answer 12

为什么他们不理解SLOC没有改变，但是软件比昨天更多，因为你添加了新功能或修复了错误？

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

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

去读这个：

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

SLOC（源代码行）作为度量标准有多糟糕？

13 个答案:

代码长度是镇流器的可行措施。