1

我主要对代码度量的案例研究感兴趣，将代码可读性与缺陷减少联系起来，证明认真对待圈复杂度或一些类似度量是合理的。维基百科有这个例子：

许多研究调查了圈复杂度与模块中包含的缺陷数量的相关性。大多数此类研究发现圈复杂度和缺陷之间存在很强的正相关关系：具有最高复杂度的模块往往也包含最多的缺陷。例如，度量监控软件供应商 Enerjy 于 2008 年进行的一项研究分析了开源 Java 应用程序的类别，并根据在其中发现错误的常见程度将它们分为两组。他们发现圈复杂度与其故障之间存在很强的相关性，综合复杂度为 11 的类的故障概率仅为 0.28，而复杂度为 74 的类则上升到 0.98。

这很好，但我希望知道是否有更多的研究（或者可能对其他指标进行类似的研究，例如 SLOC）。

我还在IBM 发现了一篇文章，它提倡监控 CC 值，但它缺乏显示 ROI 数据的案例研究支持。然后是关于“箭头代码”的 Coding Horror 文章，其中包含案例研究的摘要，但没有提供案例研究本身，也没有提供证明结论合理的实际数字：

研究表明程序的圈复杂度与其错误频率之间存在相关性。低圈复杂度有助于程序的可理解性，并表明它比更复杂的程序更容易以更低的风险进行修改。模块的圈复杂度也是其可测试性的有力指标。

当然，圈复杂度 (CC) 将有助于发现箭头代码，但我仍然需要显示 ROI 值的案例研究。例如，“组织 X 在方法/功能上的最大 CC 为 10，并在接下来的开发迭代中减少了 20% 的缺陷。”

没有这种数据，很难让管理层关心。谁能指点我一些艰苦的研究？即使只有一个也会有所帮助...

4

3 回答 3

1

“......我仍然需要显示 ROI 值的案例研究。”

为什么投资回报率这么难？

这就是为什么。

单个程序员的工作效率至少相差一个数量级，有时甚至相差两个数量级。

http://forums.construx.com/blogs/stevemcc/archive/2008/03/27/productivity-variations-among-software-developers-and-teams-the-origin-of-quot-10x-quot.aspx

个体差异胜过您可能正在寻找的任何其他影响。你不能做一个“头对头”、“苹果对苹果”的比较。当您使用不同的技术（即不同的复杂性阈值）比较两个相似的团队时，您会发现个人绩效差异只是主导数据，几乎所有内容都是噪音。

“没有那种数据，很难让管理层关心。”

如果管理层不关心质量，你就有大问题。投资回报率数字不会影响管理层改变环境。

您必须在自己的组织中对自己的代码进行自己的实验。

收集圈复杂度、缺陷率、问题单、崩溃，以及任何你能做到的东西。尝试将复杂性与其他不良指标相关联。善于争论的经理总是可以通过指出团队成员之间的个体差异来取胜。

在您的真实组织中使用真实数据。这是你能做的最好的。这不是“一些研究”或“一些白皮书”，而是您的实际组织。

于 2010-07-21T19:38:02.230 回答
0

在这种情况下，您从原始文章中获得的信息比维基百科的更多。他关于如何收集数据等的技术论文显示了 95% 的结论置信度。

没错，这并没有直接提供 ROI 信息。至少对于这项研究来说，这将是相当困难的——例如，他们使用开源项目作为他们的训练数据，而开源项目的实际成本通常甚至难以估计，更不用说衡量了。同时，他们确实使用了我认为至少是真实 ROI 数据的合理代理：他们在源代码控制系统中搜索了他们的每个“培训”项目，寻找似乎与修复相关的签到错误、缺陷等。然后，他们使用朴素贝叶斯算法来查找他们使用的指标与代码中已识别的问题之间的相关性。虽然毫无疑问，至少有一些改进是开放的，但在我看来，这些结果至少应该意味着什么。

还值得注意的是，进行这项研究的同一个人对大量开源项目保持着运行索引。如果您想要更多可靠数据的方式，您可以根据其中一些项目的源代码控制日志检查他们的索引，您可能可以使用他们的数据以直接 ROI 类型结果的方式提出更多。然而，需要注意的是：他们的索引基于相当多的源代码指标，而不仅仅是圈复杂度，所以我不确定与他们所查看的其他指标相比，它究竟能说明多少关于 CC 的信息。

于 2010-07-21T20:18:01.023 回答