虽然圈复杂度是一个有价值的指标,但我倾向于发现它不是识别难以维护的代码的糟糕工具。特别是,我倾向于发现它只是突出了某些类型的代码(例如解析器),而忽略了困难的递归、线程和耦合问题以及许多已定义的反模式。
还有哪些其他工具可用于识别有问题的 Java 代码?
请注意,我们已经使用了 PMD 和 FindBugs,我认为它们非常适合方法级别的问题识别。
虽然圈复杂度是一个有价值的指标,但我倾向于发现它不是识别难以维护的代码的糟糕工具。特别是,我倾向于发现它只是突出了某些类型的代码(例如解析器),而忽略了困难的递归、线程和耦合问题以及许多已定义的反模式。
还有哪些其他工具可用于识别有问题的 Java 代码?
请注意,我们已经使用了 PMD 和 FindBugs,我认为它们非常适合方法级别的问题识别。
我的经验是,查看代码可维护性时最重要的指标是:
在检查其他人编写的代码时,包含动态技术通常很有用。只需通过分析器/代码覆盖工具运行常见使用场景即可发现:
任何分析器、代码覆盖率和度量工具等常见的嫌疑人通常会帮助您获取进行这些评估所需的数据。
谷歌可测试性资源管理器检查例如单例和其他在设计中难闻的静态事物。Metrics是一个 Eclipse 插件,可以测量人类已知的几乎所有代码指标。我使用并且可以轻松地推荐两者。
我从未使用过它,但我发现这相当有趣和有希望:
http://erik.doernenburg.com/2008/11/how-toxic-is-your-code/
我使用了这个,发现它非常有用,因为依赖关系的良好可视化
http://www.headwaysoftware.com/products/structure101/index.php
用于 .NET 代码的NDepend工具可让您分析代码复杂性的多个维度,包括代码指标,例如:圈复杂性、嵌套深度、方法缺乏凝聚力、测试覆盖率......
...包括依赖关系分析和包括LINQ 查询上的代码规则 (CQLinq),专门用于询问我的代码中的复杂性以及编写规则。提供了大约200 条默认代码规则。他们关注像Singleton这样的反模式、线程问题的检测、UI 层等耦合问题的检测不应该直接使用 DB 类型......
前段时间,我写了一篇文章总结了代码复杂度的几个维度: Fighting Fabricated Complexity