衡量軟件質量的常用指標
最近，資深軟件工程師 Cagdas Basaraner 在博客中總結了軟件開發實踐過程中常用的幾個衡量軟件質量的指標，包括源代碼行數、代碼段/模塊/時間段內的平均 Bug 數、代碼覆蓋率、設計/開發約束等。
源代碼行數（SLOC）
計算源代碼行數也許是最簡單的辦法。它主要體現了軟件的規模，并為項目的發展和規劃提供了有用的信息。比如，如果我們每月計算一次源代碼行數，那么就可以繪制一個項目成長圖。當然，這種方式并太不可靠，原因是重構和設計階段等因素會對此產生影響，但是至少可以為項目描繪一個趨勢。
源代碼行數的統計如果只計算邏輯代碼行，那么會得到比較準確的信息。邏輯代碼行不包括空行、單個括號行和注釋行等等。統計源代碼行數的工具有很多，比如 Metrics 等。
代碼行數不應該用于評估開發人員的效率，這可能會導致重復的、無法維護和不專業的代碼。
Shahar Yair 和 Steve McConnell 早己指出，首先，使用代碼行數之和無法有效評估一個項目的實際進度，因為它更注重行為而不是結果。最終產品在多大程度上依賴于代碼的性能和質量，這也是代碼行數無法說明的。因此，聚焦于此實際上是非常有限的工作效率測量方式。SLOC 無法表明要解決的問題的復雜性，也不能以可維護性、靈活性、擴展性等等因素來說明最終產品的質量。說到質量，它反而可能起到負面作用。通過重構、使用設計模式會減少代碼行數，同時提升代碼質量。代碼量大，可能意味著有更多不必要的代碼、更高不必要的復雜性、更加僵化難懂。
代碼段/模塊/時間段內的 Bug 數
缺陷跟蹤對于更好的測試和維護是必不可少的。通過缺陷跟蹤，我們可以利用報告工具（如 Mantis）計算出每個代碼段、模塊或者特定時間段內的 bug 數量。憑借這些數據，我們可以盡早的查出和解決缺陷起因。
Bug 數量可能會作為衡量開發人員效率的指標之一，但是必須非常謹慎。如果把這項指標看得太重，那么開發人員和測試人員可能會成為敵人。在一個高效率的公司，所有的員工必須團結協作。為了更好地實現評估，bug 可以被分為低、中、高等，因為這些缺陷的重要性和解決成本不是相同的。
此前，InfoQ 中文站曾經針對“Bug 統計是否在浪費時間”做了討論，大家的看法包括：
其實我一直都不低調：bug 統計到底有沒有用見仁見智，關鍵要看怎么統計，想得到什么。從來沒有認真分析過 bug 數據的人，肯定不會知道數據里面隱藏著什么。拋開 bug 統計這個問題，缺陷追蹤工具到底是一個什么地位？一個項目 2000bug，如果沒有工具輔助，所有人估計要崩潰了。沒有人直接反對這個想法，應該這是 DEV 的內部會議，與測試無關。
雙子的天馬行空-Adey：其實我覺得他說得很有道理的， 真正的敏捷應該不需要 bug track system。非死book 的開發模式，就是 dev 直接面向客戶，它有多個直接面向客戶的開發團隊，，只要有需求，開發后直接上線。如果后面有 issue，是有 second tier 的 dev team 來 support fix。tier one 的 dev 永遠在敏捷快速狀態。
柴阿峰：回復@雙子的天馬行空-Adey:三五個人的成熟團隊敏捷也許不需要，大部分還是需要的。否則各種基于 bug trace 的管理系統就不需要開發持續集成、變更驅動測試的功能了。好的軟件可以幫助實施敏捷，而不是反過來，不可能什么都靠嘴和白板的。
Sab866：敏捷的基礎是團隊成員都是自律自發且積極的，不需要用報告來鞭策，但是簡單易用的缺陷管理工具還是必須的，不然還真是會一片混亂。
代碼覆蓋率
代碼覆蓋率反映了程序當中源代碼被測試的程度。有許多自動化工具可以完成該功能，比如 Cobertura。
代碼覆蓋率不能完全代表單元測試的整體質量，但是可以反映出測試覆蓋率的問題。它可以和其他測試指標一起作為軟件質量的指標。同時，單元測試代碼、集成測試場景和結果應該經常地被審查。
有關質量模型的問題，支付寶 SQA 團隊的西劍提出有效的代碼度量模型應具備以下特征：
- 與組織的目標一致：代碼度量模型的底線要與組織的要求一致，和業務相關的東西會體現在規范里。在支付寶，代碼安全規范、敏感信息處理規范被作為代碼質量最基本的要求。
- 有針對性：要做針對性分析，比如對線上故障的研發原因進行分析，分析的規則會有周期性變動的，但不要太頻繁，而且規則會隨著組織的成熟度而改變。
- 可操作性：要對度量維度做進一步分解，比如測試要有明確的檢查點，覆蓋要完整，可重復運行。支付寶就制定了具體的度量維度，從多個維度對系統加以度量。
- 有工具支持：這不是必要條件，工具不能解決所有問題！能用工具最好，不行的話就人工檢查。工具檢測維度要按照優先級和操作性，逐步增加精細化維度。這一點上，支付寶將一些編碼規則的檢查放入了持續集成工具之中，以求盡早檢查、頻繁檢查。
設計/開發約束
在軟件開發過程中，存在許多設計約束和準則，其中包括：
- 類和方法的長度
- 單個類里方法和屬性的個數
- 方法或者構造函數的參數個數
- 代碼中的魔數、字符串用法等等
- 注釋行比例等
這些準則對代碼可維護性和可讀性至關重要。開發團隊可以選擇一些工具來統計這些約束的實施情況，比如 maven pmd plugin。