8

这里有一些关于代码度量的问题，尤其是关于目标值的问题。我正在寻找的是在现实生活中的制作项目中“常见”的东西。也许只有我一个人，但我参与的任何项目都没有考虑过这些事情，所以当我运行 ReSharper Code Issues 或 Visual Studio Code Metrics 时，我似乎是第一个 - 所以这些值总是让我感到惊讶。

我当前的 SharePoint 作业示例：

Maintainability | Cyclomatic cmplx. | Inher. depth | Class coupl. | LOC
67              | 6,712             | 7            | 569          | 21,649
68              | 3,192             | 7            | 442          | 11,873

所以，问题是，你通常在“野外”看到什么价值观？除了最优值和最佳实践，通常会遇到什么值？

4

2 回答 2

11

我假设这些值是在装配级别上的。如果是这样，圈复杂度和代码行在方法级别上最有帮助。继承深度应该主要在类级别上查看。当首先查看方法级别然后查看类级别时，类耦合会提供更有用的反馈。

除了您包含的堆栈溢出链接中提供的指南之外，Code Complete 2nd Edition 还谈到了方法 Cyclomatic Complexity，第 458 页：

  • 0-5 例行程序可能没问题。
  • 6-10 开始思考简化例程的方法。
  • 10+ 将部分例程分解为第二个例程并从第一个例程中调用它

在“现实生活”项目中，可接受的可能取决于您使用的开发过程的类型。如果团队正在实践 TDD（测试驱动开发）并努力编写SOLID代码，那么这些指标应该接近最优值。

如果 TAD（开发后测试），或者更重要的是，没有单元测试的代码，那么期望所有指标都高于最佳指标，因为可能有更多的耦合、更复杂的方法和类，以及可能更多产的继承升高。尽管如此，目标应该是限制具有“不良”指标的情况，无论代码是如何开发的。

于 2012-03-26T14:07:18.433 回答
6

关于软件度量的基本误解是，它们在放入漂亮的报告时很有用。

大多数人使用以下有缺陷的过程：

  • 收集他们的工具支持的任何指标
  • 编制报告
  • 将其与推荐值进行比较
  • 开始寻找他们新找到的答案可能解决的问题

这是错误的，在很多层面上都是错误的、倒退的和适得其反的，甚至都不好笑。收集任何指标的正确方法是首先找出原因。你测量的原因是什么？有了这个答案，您可能会弄清楚要衡量什么，并且假设您知道自己的原因以及您可以弄清楚如何获得一些可能指导进一步调查的信息。

我已经看到您列出的指标的范围很广，老实说，跨项目或环境进行比较确实没有多大意义。

你可以相当肯定，同一个团队会生产出与他们之前所做的相似的东西。但是您不需要指标来解决这个问题。

您可以使用这些指标来查找“热点”进行调查，但如果您有质量问题，错误无论如何都会聚集在有问题的模块中，并且寻找它们几乎是无用的。

现在不要误会我的意思。我喜欢指标。我已经编写了多个脚本和工具来提取可视化并用它们做各种花哨的东西，这一切都很有趣，甚至可能是有益的，但我不太确定后者。

于 2012-03-27T12:18:35.840 回答