如何評價軟體寫的好還是壞？

軟體自身是一種固化的思維，因此從本質上來看，軟體是不可度量的。

但這並不意味著軟體不需要度量，而只是說軟體中的度量大多都有一定限度。

應用各種度量資料的時候一旦跨過這種限度，結果就會適得其反。

 

在這篇文章裡，我們將考查一下現有的，對軟體進行度量的方法(注意：這篇裡主要考察別人的方法，不是我自己的)。

可能不全面，不足的地方歡迎大家進行補充。

對軟體“直觀可見的品質屬性”的度量比較簡單，比如：Bug率，效能等，這裡就不提了。

這裡主要關注的是軟體的內在的，不直觀可見的品質屬性。

 

• 循環複雜度

 

循環複雜度主要用於度量函數或方法，從《代碼大全》中可以找到循環複雜度的描述。

關於循環複雜度：Tom McCabe曾經建議使用下面的方法來度量複雜度。在這一方法中為了計算複雜度首先要計運算元程式中的決策點(decision points)，規則如下：

 

1. 1. 從函數第一行一致往下通過程式
   2.  一旦遇到以下關鍵字或者同類的詞就加1：if,while,repeat,for,and,or
   3.  給case語句中的每一種情況加1                           --Steve McConell 《代碼大全》

 

很多靜態分析工具都直接提供對循環複雜度的度量，而循環複雜度本身歧義性很小，是非常難得的指標，高於15的代碼基本很難看懂。

但循環複雜度更適合用於度量編碼的結果，對高層設計則不太適用。

 

• 響應集

 

　　響應集是指類的各個方法直接調用的函數數目。響應集無疑的應該儘可能的小，根據得墨忒耳法則：某個對象的任何方法都應該只調用屬於以下情形的方法。

         

class Demeter
{
private:
A* a;
int func();
public:
//... 
void example(B& b);
void Demeter::example(B& b)
{
C c;
int f = func(); //<---- 類自己的方法
b.invert(); //<----傳入參數的方法，當然參數本身也可能是函數
a = new A();
a->setActive();// <---建立的對象所擁有的方法
c.print(); // <---建立的，並歸自己所有的對象的方法
}
};

         ---摘自《程式員修鍊之道》

 

• 關係內聚性(H)

 

在度量包時可以用包內部類的數目除以包內類的總數，其比值用來表示包得內聚性。如果用R表示包內部得類別關係數目，用N表示包內類總數。那麼：

H = (R+1)/N

• 不穩定性(I)

不穩定性由輸入耦合度（Ca)與輸出耦合度(Ce)計算而來。

包得輸入耦合度是指處於包外部，但依賴於包內類的數目。

包得輸出耦合度是指包內部的依賴於包外部類的類數目。

這樣I = Ce / （Ca+ Ce)

 

• 抽象性(A)

 

包的抽象性用抽象類別的數目和包中所有類的數目進行計算。

假如說包中類的總數是Nc, 抽象類別的數目是Na ,那麼抽象度A = Na/Nc

 

關係內聚性(H)，不穩定性(H)，抽象性(H)的進一步說明，請參見《敏捷式軟體開發 (Agile Software Development)：原則，模式與實踐》一書。

 

這些度量指標無疑是有意義的，都可以用來評價軟體寫的好還是壞，但卻不解決這樣一個問題：
如果一個方案在關係內聚性(H)，不穩定性(H)，抽象性(H)上都有好的表現，複雜度有沒有提高？如果說複雜度因此而提高了，那麼這種額外支出的複雜度值不值得？

如果我們認為複雜度是軟體的根本問題，那麼在滿足需求的前提下，使軟體簡單化就是最關鍵的使命（比靈活性等重要）。既如此，究竟應該如何度量軟體的複雜度呢？

這是一個需要進一步展開的話題，我完善後會進一步和大家分享。