如同Tom DeMacro说的：无法控制的东西就不能管理，无法测量的东西就无法控制。

软件的度量对于设计者和开发者非常重要，之前只是对这些有一个简单的了解。今天看来，了解的还远远不够。

• Cyclomatic Complexity （圈复杂性）
• Response for Class （类的响应）
• Weighted methods per class （每个类重量方法）

一个系统中的所有类的这三个度量能够说明这个系统的设计上的一些问题（不是全部），这三个度量越大越不好。
如果一个类这三个度量很高，证明了这个类需要重构了。

以第一个度量来说，有下面的一个表格：

CC Value	Risk
1-10	Low risk program
11-20	Moderate risk
21-50	High risk
>50	Most complex and highly unstable method

CC数值高，可以通过减少if else（switch case也算）判断来达到目的；
可以通过减少类与其他类的调用来减少RFC；
通过分割大方法和大类来达到减少WMPC.

而Uncle Bob和Jdepend的度量标准应该算是另一个度量系统。

• 关系内聚性（H）

• Number of Classes (Cc)

• Afferent Couplings (Ca)

• Efferent Couplings (Ce)

• Abstractness (A)

• Instability (I)

• Distance (D)
  

          被分析package和理想曲线A＋I＝1的垂直距离，用于衡量package在稳定性和抽象性之间的平衡。理想          的package要么完全是抽象类和稳定（x＝0，y＝1），要么完全是具体类和不稳定（x＝1，y＝0）。
          取值范围为0－1，D＝0表示完全符合理想标准，D＝1表示package最大程度地偏离了理想标准。
          D = |A+I-1|/0.70710678
          注：0.70710678*0.70710678 =2，既为“根号2“

我认为D是一个综合的度量，架构和设计的改善可以通过D数值的减少来体现，反之就可以认为是设计和架构的退化。


读过http://javaboutique.internet.com/tutorials/metrics/index.html之后的一些想法

另一篇中文的内容相近的文章可以参考http://www.jdon.com/artichect/coupling.htm

不过第二篇的中文文章中间关于Cyclomatic Complexity，有一个情况遗漏了
public void findApplications(String id, String name){

     if(id!=null && name!=null) {
        //do something
     }else{
        //do something
     }
}

这种情况的CC不是2+1，而是2+1+1，依据是公式（1）。公式(2)应该是公式（1）的简化版。

Cyclomatic Complexity （CC） = no of decision points + no of logical operations +1        （1）

Cyclomatic Complexity (CC) = number of decision points +1                                （2）

参考了JDepend的参数和Uncle Bob的《Agile Software Development: Principles, Patterns, and Practices》 （敏捷软件开发：原则、模式与实践）