1. Sourc Lines of Code (SLOC)

統(tǒng)計代碼行數(shù)可能是最簡單的方法。它能體現(xiàn)軟件的規(guī)模，為項目的發(fā)展和計劃提供一些數(shù)據(jù)支撐。例如，我們每個月統(tǒng)計一次代碼的行數(shù)，我們就能大體知道項目的發(fā)展情況。當(dāng)然，這不是一個值得信賴的標準，因為有重構(gòu)以及設(shè)計的因素。

SLOC ***是統(tǒng)計 Source Logical Line of Code (SLLOC) 以獲得更準確的信息。Logical code lines 不包含空行，單個括號行以及注釋行。你可以通過 Metrics 這樣的工具很容易的統(tǒng)計 SLLOC。

代碼行數(shù)不應(yīng)該被用來衡量開發(fā)效率。否則容易造成重復(fù)的，不易維護的和不專業(yè)的代碼。

2. Bugs per code_section/module/time_period

問題跟蹤是保證測試和可維護性的關(guān)鍵步驟。假如所有的問題（bug）都是有跟蹤的話，每個代碼單元，每個模塊或者某個特定時間（day, week, month...）的問題就很容易被統(tǒng)計（例如 Mantis 工具）。當(dāng)我們有了這些數(shù)據(jù)以后，問題的根源就可以被盡早發(fā)現(xiàn)并處理。

問題數(shù)量可以作為衡量開發(fā)質(zhì)量的一個標準，但必須用的很小心。假如過分強調(diào) bug 數(shù)量，那么開發(fā)和測試的關(guān)鍵就會很緊張。在一個有效率的公司，所有的員工都應(yīng)該融洽的相處。

為了更好的對代碼質(zhì)量進行評估。Bug 可以分為 low, medium, high 三種級別，因為它們的重要性和修復(fù)的成本是不一樣的。

3. Code Coverage

Code coverage 表明了代碼被測試的程度。有很多工具可以自動統(tǒng)計這個數(shù)據(jù)，例如 Cobertura 。

Code coverage 不能說明單元測試的整體質(zhì)量，但是能說明測試的覆蓋面。它可以和其他一些指標一起用來衡量軟件的質(zhì)量。當(dāng)然，我們也需要經(jīng)?；仡檰卧獪y試代碼和集成測試的用例。

4. Design/Development Contraints

軟件開發(fā)中有很多設(shè)計規(guī)則，例如： 

• 類/方法的長度 
• 方法/屬性的數(shù)量 
• 方法的參數(shù)數(shù)量 
• 特殊數(shù)值以及字符串的使用量 
• 注釋的比例

這些規(guī)則都是保證代碼可讀性和可維護性的重要指標。開發(fā)團隊應(yīng)該選擇一些或者全部的規(guī)則來實施（例如 maven pmd plugin ）。這將幫助提高軟件產(chǎn)品的質(zhì)量。

5. Cyclomatic Complexity（環(huán)路復(fù)雜度）

把環(huán)路復(fù)雜度單獨列出來講是因為它和其他的設(shè)計準側(cè)不太一樣。環(huán)路復(fù)雜度是關(guān)于代碼實現(xiàn)和執(zhí)行。它也可以通過工具自動計算，例如 pmd 。

這個數(shù)值是獨立的代碼執(zhí)行路徑數(shù)量。例如： 

Cyclomatic Complexity = E(edges) - N(nodes) + 2P (exit nodes)   
So, Cyc.Cmp. = 8 - 7 + 2*1 = 3  

你也可以看到，從起點到終點，有三條不同的路徑。這個值往往是針對方法來計算。根據(jù)不同的項目類型，我們可以設(shè)定這個值的上限，例如6,8，或者10。

一個指標不能說明整個項目的質(zhì)量。使用更多的指標，會讓你對項目的質(zhì)量有更全面的了解。

原文鏈接，OSChina.NET 編譯