我主要对代码度量的案例研究感兴趣,将代码可读性与缺陷减少联系起来,证明认真对待圈复杂度或一些类似度量是合理的。维基百科有这个例子:
许多研究调查了圈复杂度与模块中包含的缺陷数量的相关性。大多数此类研究发现圈复杂度和缺陷之间存在很强的正相关关系:具有最高复杂度的模块往往也包含最多的缺陷。例如,度量监控软件供应商 Enerjy 于 2008 年进行的一项研究分析了开源 Java 应用程序的类别,并根据在其中发现错误的常见程度将它们分为两组。他们发现圈复杂度与其故障之间存在很强的相关性,综合复杂度为 11 的类的故障概率仅为 0.28,而复杂度为 74 的类则上升到 0.98。
这很好,但我希望知道是否有更多的研究(或者可能对其他指标进行类似的研究,例如 SLOC)。
我还在IBM 发现了一篇文章,它提倡监控 CC 值,但它缺乏显示 ROI 数据的案例研究支持。然后是关于“箭头代码”的 Coding Horror 文章,其中包含案例研究的摘要,但没有提供案例研究本身,也没有提供证明结论合理的实际数字:
研究表明程序的圈复杂度与其错误频率之间存在相关性。低圈复杂度有助于程序的可理解性,并表明它比更复杂的程序更容易以更低的风险进行修改。模块的圈复杂度也是其可测试性的有力指标。
当然,圈复杂度 (CC) 将有助于发现箭头代码,但我仍然需要显示 ROI 值的案例研究。例如,“组织 X 在方法/功能上的最大 CC 为 10,并在接下来的开发迭代中减少了 20% 的缺陷。”
没有这种数据,很难让管理层关心。谁能指点我一些艰苦的研究?即使只有一个也会有所帮助...