26

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

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

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

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

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

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

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

4

13 回答 13

45

有人说：

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

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

  • 复制粘贴综合症

  • 不鼓励重构以使事情变得更容易

  • 充斥着无意义的评论

  • ...

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

于 2010-09-22T13:34:18.313 回答
24

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

  1. 代码行越多，事情就越复杂。
  2. 事情越复杂，就越难理解。
  3. 在添加新功能或修复错误之前，我需要了解它。
  4. 理解需要时间。
  5. 时间花钱。

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

豆类柜台可以理解这一点。

于 2010-09-22T13:38:51.360 回答
13

向他们展示以下之间的区别：

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

和

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

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

回应评论：

  1. 很快就可以解释for循环是如何工作的。

  2. 在你向他们展示这个之后，说“我们现在需要打印最多 100 个数字——这就是你如何进行更改的方法。” 并显示更改非 DRY 代码需要多长时间。

于 2010-09-22T13:34:09.770 回答
11

于 2010-09-22T13:36:51.407 回答
7

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

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

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

非注释代码行的数量与：

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

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

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

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

于 2014-11-20T18:46:13.660 回答
5

说明 SLOC 是对应用程序中代码行数的极好衡量，仅此而已。

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

于 2010-09-22T16:10:05.587 回答
5

很糟糕 （-：

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

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

作为奖励收集覆盖率统计信息（分支覆盖率比线路覆盖率更好）。

于 2010-09-22T13:33:20.017 回答
3

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

当你想让你的飞机飞得更高、更长、性能更好时，你不会增加它的重量。你用更轻/更好的材料替换它的一部分。您剥去不需要的部分，以免增加不必要的重量。

于 2010-09-22T13:37:51.047 回答
3

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

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

  • 不要写 1 行代码时写 2 行代码，除非 2 行版本使代码更容易维护 2 倍。
  • 不要仅仅为了弄乱 SLOC 计数而使用不必要的注释来弄乱代码。
  • 不要按 SLOC 计数向人们付款。

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

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

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

干杯，芯片叔叔

于 2016-07-17T08:03:00.763 回答
1

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

计算代码行数（SLOC / LLOC）有什么问题？

于 2011-11-04T08:22:38.633 回答
1

为什么 SLOC 作为生产力的单个指标不好

把代码想象成一块粘土/石头。你需要雕刻，比如说 10 个雕像。重要的不是你雕刻了多少雕像。重要的是你雕刻得有多好。同样，重要的不是你写了多少行，而是它们运行得有多好。在代码的情况下，LOC 可能会适得其反。

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

如何使用 SLOC 为您带来好处

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

于 2010-09-22T13:37:47.997 回答
0

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

于 2010-09-22T13:34:47.637 回答
0

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

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

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

去读这个：

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

于 2010-09-22T15:50:43.300 回答