为何青睐循环复杂度？
5.00/5 (2投票s)
在将指标应用于架构时，循环复杂度具有一些良好的不变性。
引言
我编写了一些代码来从源代码中提取架构信息，并为 CodeProject 撰写了其他文章来描述它们。在重构我的代码时，我发现自己正在竞争以优化每个迭代的指标。显然，任何系统都可以被操纵，我选择循环复杂度作为指标是因为它具有一些不变性，可以阻止该值在各种重构下发生变化。
图的循环复杂度定义为 E + P – N，其中 E 是边的数量，P 是部分的数量，N 是节点数量。 假设没有重复的边，该数字在有向图 (digraph) 中从 0 到 N 乘以 (N-1) 不等式之间变化。
示例
一个相当于 3 层架构的基本有向图可以绘制如下：
其循环复杂度为 E + P – N = 2 + 1 - 3 = 0。
添加一个孤立节点也会增加一个部分...
...其循环复杂度为 E + P – N = 2 + 2 - 4 = 0。
向新节点绘制一条边会使整个部分...
...其循环复杂度为 E + P – N = 3 + 1 - 4 = 0。
将两个中间节点组合成它们自己的图...
其循环复杂度为 E + P – N = (2 + 1 - 3) + (1 + 1 - 2) = 0。
注释
所以所有示例都具有相同的循环复杂度，这与声明在所使用的变换下，该数字是不变的相同。如果示例包含一些分支，则不一定如此。
值得注意的主要示例是创建子图时的最后一个示例。在架构建模的上下文中，最好将元素放置在层次结构中以简化架构视图。 能够在不增加或减少适当指标的情况下执行此操作，允许架构师简化他们的视图，同时保持他们的分数。
此属性使我能够编写架构软件，该软件采用由命名空间层结构化的 C# 代码，在每个命名空间级别创建依赖关系图，并对循环复杂度求和，为整个应用程序生成一个数字，并确信它是有意义的。然后，我可以随着时间的推移跟踪它，以了解其改进和恶化的程度。
历史
- 2016/08/03：首次发布