code-metrics - SLOC(源代码行)作为一个指标有多糟糕？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

4年前关闭。




Improve this question




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

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

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

我理解 SLOC 的诱惑:对于非软件人员来说，它似乎很容易理解，而且它似乎是最接近物理事物的模拟(就像过去数打洞卡一样!)。

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

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

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

Answer 1

有人说:

“使用 SLOC 来衡量软件进度就像使用公斤来衡量飞机制造的进度”

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

复制粘贴综合症

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

充斥着无意义的评论

...

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