代码度量的魅力是什么?[闭门]

这条线索中的答案有点奇怪,因为他们说:

• “指标”,就像它们本身意味着什么一样。

1/指标不适用于 人口,但是 :

• 开发者:他们关心的是 瞬间的 关于代码的静态分析(圈复杂度、注释质量、行数等)
• 项目负责人:他们关心的是 实时代码度量 来自单元测试、代码覆盖率、持续集成测试
• 商业赞助者(他们总是被遗忘,但他们是利益相关者,是为开发付费的人):他们关心 每周的

当然,所有这三个群体都可以观察和分析所有这些指标,但每种指标都是为了更好地为每个特定群体所使用。

2/度量本身代表一种 快照

正是这些指标的组合,以及这些不同层次的分析的组合,可能表明代码是“好的”或“坏的”,但更重要的是,它是 这很重要。

这就是问题所在 在这些指标中,什么将带来真正的附加值,因为它们将帮助业务经理/项目负责人/开发人员 按重要性排列

• “漂亮”的代码(尽管这总是在旁观者的眼中)

因此,例如,圈复杂度为9的函数可以定义为“美丽”,而不是一个圈复杂度为42的长卷积函数。

• 稳步的 复杂性 与…结合 代码覆盖率为95%,
• 而前者有一个 增加的 对……的报道。。。0%,

• 后者代表了一种 好的
• 前者是"一个", 令人不快的 “代码(它仍然需要添加一些案例和条件来涵盖它必须做的所有事情,并且没有简单的方法来进行回归测试)

一个单独的指标,其本身总是表示[…]

是否有一些神奇的洞察力可以从我忽略的代码度量中获得?

只有 结合体 和 趋势 一系列的指标给出了你所追求的真正的“神奇洞察力”。

几个月前,我做了一个项目,作为一个人的工作,测量圈复杂度。这是我第一次接触到这些指标。

对于另一半的例程,我作为一名程序员的自豪感开始了,我试图以一种与之相同的方式重写它们,只是更简单、更具可读性。这是有效的,我能够将大部分内容降低到客户的复杂性阈值。

我认为,如果您使用度量作为改进代码的理由/动机,那么度量是一件好事。不过,知道什么时候停下来并要求一笔违反度量标准的补助金是很重要的。

我用过的最好的度量标准是 C.R.A.P. score .

CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) 其中comp(m)是方法m的圈复杂度,cov(m)是自动测试提供的测试代码覆盖率。

上述文章的作者(请去读一下……这很值得你花时间)建议C.R.a.P.的最高分数为30分,具体如下:

Method’s Cyclomatic Complexity        % of coverage required to be
                                      below CRAPpy threshold
------------------------------        --------------------------------
0 – 5                                   0%
10                                     42%
15                                     57%
20                                     71%
25                                     80%
30                                    100%
31+                                   No amount of testing will keep methods
                                      this complex out of CRAP territory.

正如您很快看到的,度量标准奖励编写不复杂的代码以及良好的测试覆盖率(如果您正在编写单元测试,您应该这样做,并且没有测量覆盖率……那么,您可能也会喜欢随风吐痰)。;-)

对于我的大多数开发团队来说,我非常努力地让C.R.A.P.的分数低于8分,但是如果他们有充分的理由证明增加的复杂性是可以接受的,只要他们通过足够的测试覆盖复杂性。(编写复杂的代码总是很难测试……这是该指标的一个潜在好处)。

对我来说,识别错误代码的一个最重要的指标是圈复杂度。我的项目中几乎所有的方法都低于CC 10,并且在CC超过30的遗留方法中总是会发现bug。 高CC通常表示:

• 匆忙编写的代码(即没有时间找到优雅的解决方案,而不是因为问题需要复杂的解决方案)
• 未经测试的代码(没有人为这样的野兽编写测试)
• 经过多次修补和修复的代码(即充满ifs和todo注释)
• 重构的主要目标

代码度量是放在工具箱中的另一个工具,它们本身并不是一个解决方案,它们只是一个适当使用的工具(当然,所有其他工具都在工具箱中!)。

我同意“代码良好性”的指标和“好文章”的指标一样合理。但这并不意味着指标是无用的,只是可能被误用了。

例如 极端 某些指标的值 指路 解决可能出现的问题。一个1000行长的方法是 无法维护的。单元测试代码覆盖率为零的代码 可能 引起额外注意。

我认为,如果我们把指标作为一个建议——一个危险信号——也许它们会有用。问题在于,当人们开始用SLOC来衡量生产率,或者用测试行的百分比来衡量质量。

我非常主观的观点是,代码度量表达了一种不可抗拒的制度魅力,即能够量化本质上无法量化的东西。

在某种程度上,至少在心理上是有意义的——你怎么能对你无法评估或理解的事情做出决定?当然,归根结底,你不能评估质量,除非你对这个主题很了解(并且至少和你要评估的内容一样好),或者问一个有知识的人,这当然只会让问题倒退一步。

从这个意义上说,也许一个合理的类比是通过SAT分数来评估大学入学者,这是不公平的,而且遗漏了每一种微妙之处,但如果你需要量化,你必须做点什么。

并不是说我认为这是一个好的措施,只是我可以看到它的不可抗拒性。而且,正如您所指出的,可能有一些合理的指标(很多500+行方法,高复杂性可能很糟糕)。不过,我从来没有去过一个相信这一点的地方。

我相信有一个代码度量。

这个数字越小越好。

度量和自动化测试并不意味着取代完整的代码审查。

只有在以下情况下,测量才有用:

• 小组同意了他们的意见
• 它们被用于识别特定区域

我认为度量对于识别趋势是有用的,事实上,我已经看到了一些有用的度量,比如构建中断时的绘图、代码搅动(整个项目中代码行数的变化)以及其他事情。但是,如果团队没有提出这些建议,或者他们不同意或不理解这些建议,那么你很可能会受到伤害。

stan4j .

我喜欢这个工具和指标。我将指标视为统计数据、指标和警告消息。有些时候,由于某些方法或某些类确实有一些复杂的逻辑,使得它们变得复杂,应该做的是密切关注它们, 检查它们,看看是否需要重构它们或仔细检查它们,因为它们通常容易出错。我还将它用作分析工具来学习源代码,因为我喜欢从复杂到简单学习;Kemerer度量,计数度量 但我最喜欢这个

圈复杂度度量

圈复杂度(CC)

平均圈复杂度 应用程序、库、包树或包的所有方法的圈复杂度度量的平均值。

工件的Fat度量是工件的适当依赖关系图中的边数。依赖关系图类型取决于度量变量和所选工件:

脂肪

包的Fat度量是其单元依赖关系图的边计数。此图包含包的所有顶级类。

类的Fat度量是其成员图的边计数。此图包含该类的所有字段、方法和成员类。(只有在使用详细级别成员(而不是类)执行代码分析时,此图和Fat值才可用。)

应用程序库依赖关系的Fat度量是其库依赖关系图的边计数。此图包含应用程序的所有库。(要在合成视图中查看相应的图形,必须启用结构资源管理器的“显示库”切换。)

平面包依赖的Fat(Fat-包) 应用程序的Fat for Flat Package Dependencies度量是其Flat Package dependency图的边计数。此图包含应用程序的所有包。(要在合成视图中查看相应的图形,必须启用结构资源管理器的“平面包”切换,并禁用“显示库”切换。)

库的Fat for Flat Package Dependencies度量是其Flat Package dependency图的边计数。此图包含库的所有包。(要在合成视图中查看相应的图形,必须启用Structure Explorer的平面包和显示库切换。)

顶级类依赖项的Fat(Fat-单位) 应用程序或库的顶级类依赖关系度量的Fat是其单元依赖关系图的边计数。此图包含应用程序或库的所有顶级类。(对于合理的应用程序,它太大而无法可视化,因此无法在组合视图中显示。单元依赖关系图可能仅针对包显示。)

度量可能有助于确定项目中的改进或降级,并且肯定可以发现违反样式和约定的情况,但没有什么可以替代同行代码审查。没有它们,您不可能知道代码的质量。

答案的一部分是,一些代码度量可以为您提供一个非常快速的初步答案:这个代码是什么样的?

正如在另一个答案中提到的,度量的趋势为您提供了最多的信息。

这些指标本身并不特别有趣。重要的是你如何对待他们。

例如,如果你正在测量每行代码的注释数量,你认为什么是一个好的值?谁知道呢?或许更重要的是,每个人都有自己的观点。

现在,如果您收集了足够的信息,能够将每行代码的注释数与解决错误所需的时间或与发现的归因于编码的错误数相关联,那么您可能会开始找到一个经验上有用的数字。

在软件中使用度量与在任何其他过程中使用任何其他性能度量之间没有区别——首先进行度量,然后进行分析,然后改进过程。如果你所做的只是测量,那你就是在浪费时间。

编辑:回应史蒂文·A·洛的评论——这绝对正确。在任何数据分析中,必须小心区分因果关系和单纯的相关性。基于适用性的度量标准的选择非常重要。试图衡量咖啡消费量和评价代码质量是没有意义的(尽管我确信有些人已经尝试过;-)

但是,在你能找到这种关系(因果关系与否)之前,你必须有数据。

要收集的数据的选择取决于您希望验证或改进的流程。例如,如果您试图分析代码审查过程的成功(使用您自己的“成功”定义,即减少的bug或减少的编码bug,或更短的周转时间或其他),那么您可以选择度量代码审查过程中bug的总比率和bug的比率的指标。

我不认为度量标准中的小变化是有意义的:复杂度为20的函数不一定比复杂度为30的函数更干净。但运行度量来寻找巨大差异是值得的。

我们是程序员。我们喜欢数字。