it-swarm.cn

对源代码有用的指标是什么?

捕获源代码的有用指标是什么?

度量标准如何(Executable?)代码行Cyclomatic Complexity有助于质量保证,或者它们总体上对软件开发过程有什么好处?

33
cschol

“通过代码行来衡量软件生产率就像通过衡量飞机的重量来衡量飞机的进度。”-比尔·盖茨

30
chrisaycock

看一下Jeff在该主题上的帖子:

度量衡女仆的拜访

软件工程:已死?

Joel也有一篇老文章,但很好,与软件指标密切相关,我强烈建议阅读: Econ 101管理方法

对我来说,关键点是引用Jeff: 负责任地使用这些指标与首先收集它们一样重要。”

12
Machado

使我对代码指标感到困惑的是,它做得还不够。大多数公司都会报告其员工,供应商和系统的效率,但是似乎没有人愿意报告代码。我肯定会同意这样的答案:陈述更多的代码行是一种责任,但是您的代码所做的却更为重要。

代码行:正如我已经提到的,这是一项至关重要的测量,应该在每个级别上都认真对待。函数,类,文件和接口可以指示长期难以维护且成本高昂的所有代码。比较代码的总行数和系统的工作量是无限困难的。它可能做很多事情,在这种情况下,将有很多行代码!

Complexity:此度量很适合在您尚未使用的代码库上进行,并且可以很好地指示问题所在的位置。作为一个有用的轶事,我在自己的一个代码库中测量了复杂度,而最复杂的区域是我在更改时花费最多的时间。降低复杂性的努力大大减少了维护时间。如果管理人员手头有这些度量,他们可以计划系统特定区域的重构迭代或重新设计。

代码重复:就我而言,这是非常重要的度量。代码重复是一个非常糟糕的信号,它可能会指出系统设计水平低下的深层问题,或者指出复制粘贴的开发人员,从长远来看会导致大量问题,而系统则难以维护。

Dependency Graphs查找不良的依赖关系和循环依赖关系是代码中的重要度量。这几乎总是指向需要修改的不正确的高级设计。有时,一个依赖关系会吸收很多不必要的其他依赖关系,因为有人在电子邮件库中使用addNumber进行财务计算。更改电子邮件库和财务中断后,每个人都会感到震惊。如果一切都取决于一件事,那么它也可以指向所有难以维护且设计不当的库。

良好的度量始终可以告诉您系统的每个功能都占用很小的空间。更少的依赖关系,更少的复杂性,更少的重复。这表明耦合松散和内聚性高。

11
Tjaart

这种“源代码指标”废话不会消失吗?

原始代码行(SLOC)是最古老,最简单,最基本的指标。

Halstead最初提出了一整套指标。许多人在编写测量程序之前都玩得很开心,直到一些剧透进行了明显的研究,并证明了每个Halstead指标都与SLOC密切相关。

那时,Halstead的指标被放弃了,因为SLOC总是更容易测量。

8
John R. Strohm

用于质量保证的源代码指标旨在两个目标:

  • 编写代码,减少内部错误
  • 编写代码以便于维护

两者都导致编写代码尽可能简单。这表示:

  • 简短的代码单元(函数,方法)
  • 每个单元中的几个元素(参数,局部变量,语句,路径)
  • 以及许多其他或多或少复杂的标准(请参阅Wikipedia中的 软件指标 )。
8
mouviciel

据我所知,发现的错误数量与代码行(可能搅动),模语言,程序员和领域直接相关。

我不知道与错误紧密相关的任何其他简单而实用的指标。

我想做的一件事是开始运行我所参与的不同项目的数字-Test Coverage :: kLOC,然后讨论“感知质量”以查看是否存在相关性。

7
Paul Nathan

仅当您知道如何处理所获得的答案时,指标才有用。本质上,软件指标就像温度计。在98.6°F的温度下测量物体这一事实并不意味着任何事情,除非您知道正常的温度是多少。上面的温度对人体温度有好处,但对冰淇淋却很不利。

可以使用的常见指标是:

  • 每周发现的错误
  • 每周解决的错误
  • #需求定义/发布
  • #实施/发布需求

前两个度量趋势。您发现错误的速度超过了解决它们的速度吗?两个可能的结果:也许我们需要更多的资源来修复错误,也许我们需要停止实施新功能,直到我们赶上来。后两者提供了您完成工作有多接近的图片。敏捷团队将其称为“疲倦”图表。

循环复杂度是一个有趣的指标。它的基本概念是函数/方法中唯一执行路径的数量。在繁重的单元测试环境中,这对应于验证每个执行路径所需的测试数量。但是,仅因为您具有Cyclomatic Complexity为96的方法,并不意味着它一定是错误的代码-或您必须编写96个测试以提供合理的置信度。生成的代码(通过WPF或解析器生成器)创建这种复杂的代码并不少见。可以粗略地了解调试方法所需的工作量。

底线

您进行的每次测量都需要定义以下内容,否则将无用:

  • 了解什么是“正常”。这可以在项目的整个生命周期内进行调整。
  • 在“正常”范围之外的阈值,您需要采取某种措施。
  • 超过阈值时处理代码的计划。

您所采用的指标可能因项目而异。您可能在整个项目中使用了一些指标,但是“正常”的定义会有所不同。例如,如果一个项目平均每周发现5个错误,而新项目每周发现10个错误,则不一定表示有问题。这次可能只是测试团队更加细致。同样,“正常”的定义可能会在项目的整个生命周期内发生变化。

该指标只是一个温度计,您该如何处理取决于您自己。

7
Berin Loritsch

源代码是负债,而不是资产。 考虑到这一点,测量代码行类似于跟踪建造房屋时花费的美元。如果您想使预算保持在预算之内,则需要完成此操作,但是您不一定会认为每天花费1000美元比每天花费50美元更好。您想知道有多少钱用来盖房子。软件项目中的代码行也是如此。

简而言之,没有用于源代码的有用指标,因为仅测量源代码本身就没有用。

6
Larry Coleman

由于源代码只是序列,选择和重复的组合。如果我要描述我们可以合理预期要生产的最佳软件,则将如下所述。具有几乎100%的测试代码覆盖率的软件,使用该工作所需的最少代码行数,但又足够灵活以承受更改。

4
Xenohacker

揭示KLOC计数为什么对评估性能无用(甚至有害)的轶事。

几年前,我参与了一个大型项目(公司中有70多名员工,客户中有30多名员工),该项目使用KLOC计数作为衡量团队和个人绩效的唯一标准。

为了我们的Y2K工作(告诉您它是多久以前的:)),我们对团队负责的代码部分进行了大量清理。我们最终发布了约30.000行代码,对于5个人来说,这是一个不错的3个月的工作。我们最终还废弃了另外70.000行代码,这是3个月工作的出色表现,尤其是与新代码结合使用时。

该季度的最终结果:-40.000行代码。在本季度之后的性能评估期间,由于未能满足我们每季度生产20.000行代码的生产力要求(毕竟,这些工具表明我们生产了-40.000行代码),我们受到公司的正式谴责。如果没有项目经理和质量保证团队的干预,得到了谴责的推翻并被表扬,那么我们所有人都将被列为表现不佳并被绕过晋升,培训,加薪等工作。

几个月后(这些事情需要时间),我们被告知该公司正在审查其生产力标准,并雇用了一个专家团队根据功能点分析来创建新系统。

4
jwenting

我很惊讶没有人提到单元测试的声明/决策覆盖率(单元测试所执行代码的百分比)。

代码覆盖率很有用,因为您知道应用程序的百分之几不会灾难性地失败;其余的有用性取决于单元测试的质量。

2
StuperUser

这些在进度方面不是很有用absolute度量标准,但是可以用来给出代码状态的一般概念。

我发现,在可视化给定代码库的模块化方面,我发现“循环复杂性”很有用。通常,您需要较低的复杂度,因为这意味着每个模块的源数量很少,并且模块很多。

1
user1249

通常,提交越小越好。这是关于SCM工具的,而不是本质上的代码,但这是一个非常可衡量的指标。提交越小,越容易将每个更改视为一个原子单位。还原特定更改并在出现问题时查明位置越容易。

只要没有提交破坏构建...

1
Assaf Lavie

在我的工作中,很多情况下我都使用代码指标:

编写代码时

我日常工作中最大,也许最重要的用途是 Checkstyle ,这是一种用于Java开发人员的工具,它会不断检查(除其他事项外)我代码的指标我们定义了一组规则,并标记出我的代码不符合这些规则的位置。在我开发代码时,它实时地告诉我我的方法是变长,变复杂还是耦合,从而使我退后一步。考虑将其重构为更好的东西。

开发人员可以完全自由地违反所有规则,因为它们永远不会适用于所有情况。那里的“规则”可以激发思想并说:“嘿,这是最好的方法吗?”

在质量检查/代码审核期间

当我执行代码审查时,我通常要做的第一件事是结合使用代码覆盖工具来检查我正在审查的代码的代码覆盖率,该工具会突出显示已覆盖了哪些代码行。这使我对测试代码的完整性有一个大致的了解。我并不在乎覆盖率是20%还是100%,只要对重要代码进行了良好的测试即可。因此,所覆盖的百分比多少没有意义,但0%的确定性就像我要仔细查看的拇指酸痛一样脱颖而出。

我还要检查团队同意的哪些指标已被“破坏”(如果有),以查看我是否同意开发人员的观点,或者是否可以提出改进建议。我们的团队已同意这些开发指标来编写新代码,这为改进我们的代码做出了巨大努力。现在,我们编写的整体方法少得多,并且在 单一责任原则 方面要好得多。

对遗留代码的改进我们有很多遗留代码需要改进。在任何时间点的指标都没有用,但是对我们来说重要的是随着时间的流逝,代码覆盖率会上升,而复杂性和耦合性则会下降。因此,我们的指标已插入到我们的持续集成服务器中,从而使我们可以花时间查看以确保我们走上正确的轨道。

掌握新的代码库我唯一一次使用源代码度量标准的行是在看一个我不熟悉的代码库时用。与我合作过的其他项目相比,它使我能够快速评估项目的粗略规模。使用其他指标,我也可以对项目质量有一个更粗略的了解。

关键是要使用指标作为趋势,讨论或前进方向的起点,而不是虔诚地将其管理成准确的数字。但是我坚信,如果正确使用它们,它们可以帮助您改进正确的代码。

1
Chris Knight

我经常使用巨大的C++程序包,并且在寻找有问题的代码值得重构 Cyclomatic Complexity 或可怕的 FanIn/FanOut 时,通常是非常好的危险信号。解决那里的问题通常会导致整个代码库的改进。

当然,这些数字只能作为值得一看的提示。在无法通过构建或拒绝提交之后设置此硬性阈值将是荒谬的。

1
Benjamin Bannier

问:捕获源代码有哪些有用的指标?

对于企业:

答:工时数

对于编码员的主管:

答:没关系。今天就做吧

对于编码者的自尊心:

答:SLOC的数量(代码源代码行)

对于编码员的母亲:

答:多吃这些柔软的法式面包和喝茶

继续下面的评论...

0
Genius