代码的评价方法和一个工具

刚刚做了统计，当前我们的项目的函数已经达到了8000以上。这样多的代码，如何找出要优化的？
以往的做法都是用代码矩形法。这个矩形的长度为代码行数，宽度为代码嵌套深度，公式为： 代码矩形面积=  代码行X代码嵌套深度 [1000copy 2010.3]
面积越小，效果往往越好。
事实上，以往的代码评审，都是基于这样的一个理论，大概的看看代码行和嵌套深度，选择出要优化的代码，然后根据重构的思想来提出建议。
还有一个做法，叫做圈复杂度。什么是圈复杂度？它的基本想法是直线代码最好读，完全是直线的圈复杂度=1，然后多一个if foreach，for就加1，多一个and，or，not在加1，反正有控制指令出现，就要+1，因为控制指令比如导致代码变得曲曲折折的，因此会提升阅读代码和调试代码的时间。
圈复杂度最找我在《代码大全2》看到，Steve Mcconnel 在这本书上用了比较多的篇幅来讲圈复杂度。举了例子：
void foo()
{
    if(!visible)
      doSomething();
}
这个代码的圈复杂度就是3.因为初始值为1，有一个if ，一个not，因此圈复杂度为3.
依我看，  代码行X代码嵌套深度X圈复杂度 就是非常不错的代码复杂度度量了，为了简化问题：CCC = 代码行X代码嵌套深度X圈复杂度。
我常常会发现这样的案例：
  尽管 CCC(代码A) > CCC(代码B), 但是实际代码的阅读效果并不比后者更困难。
这是因为 这个3维的CCC度量，并不是复杂度本身，而是一个复杂度的模型，并没有考虑到算法的选择，大小写，代码布局规范这样的、会影响到代码阅读的因素。
后者是需要人来判断的，而CCC规则，可以用于工具，从而让找到问题代码更容易，而找到后，是否真的需要修改和重构，也是需要人工来判断的。
因此，这样的思维是非常自然的——通过CCC规则，完成一个工具，帮助找到可能需要优化的代码，然后在人工判断是否需要重构，以及如何重构。
世界上的问题分两种，一种确定的问题，毫无争议，简单明快，比如直角三角形的公式 x2 + y2 = z2  . 还有一类问题是不确定的，因素很多的，比如“轮胎要多少公里需要更换？”，这样的问题才是现实世界的问题。
代码复杂度的评估，尽管可以有数字化的CCC，披着确定性的外衣，本质上却和“轮胎磨损”问题并无二致。这样的问题，研究方向上更多的基于统计原理。因此，厂家说我的轮胎30000公里更换，而作为个人的情况，1000公里换一个也并非不可能。
CCC 方法为很多工具支持，包括NDepend，SourceMonitor，Visual studio team options。在我看来，NDepend，Visual studio team options 过于复杂而且仅仅可以用于Dotnet，SourceMonitor就非常的直观，简单，并且可以用于多种语言，还是freeware。拿到 SourceMonitor ，可以说喜不自胜，溢于言表。原来我的做法都是遍历代码工程，一步步的找出需要优化的代码，现在——工作量大大减少——我可以现场的找出复杂度最高的代码，并且现场演示优化的方法。还可以比较优化前后的度量变化。