你的leader還在考覈你的千行代碼Bug率嗎？

管理學大師德魯克說：你若是你沒法度量它，就沒法管理它。要想作有效的管理，就很難繞開度量的問題。

軟件開發的過程或者技術團隊的管理也存在着如何去合理的度量效率的問題。而度量是把雙刃劍，度量具備極強的引導性。度量指標會激勵團隊重視並改善可以度量元素，也會致使你忽視沒法度量的元素，並使得問題進一步惡化。因此，選擇合適的度量指標考覈技術團隊成員，須要慎重考慮。例如，代碼行數和千行代碼Bug率指標就值得商榷。

什麼是千行代碼Bug率

首先咱們來看一下，千行代碼Bug率是怎麼定義的：

千行代碼Bug率 = Bug數量/ (代碼行數/1000)

度量的標準：千行代碼Bug率數值越小質量越好。

關於CMMI級別中和BUG率相關的信息以下：

CMMI級別	BUG率
CMM1級	11.95‰
CMM2級	5.52‰
CMM3級	2.39‰
CMM4級	0.92‰
CMM5級	0.32‰

考覈千行代碼Bug率的問題

從考覈千行代碼Bug率來看，主要存在兩個方面的問題： 
首先，從考覈標準上來講，Bug率數值越小就說明越好，基於這個結果，會引導團隊成員作出一些對長遠和總體效率無益的行爲，例如： 
1. 增大基數，增長無心義代碼 
2. 把定長循環分開寫，寫成順序方法 
3. 把可配置信息寫死到代碼中 
4. 大量的複製、粘貼代碼 
5. 從新發明各類輪子

統計「千行代碼Bug率」和「每日生產代碼行數」同樣，都是沒通過大腦思考，而直接打算把優秀員工踢出團隊的懶人式管理方式。特別是對從事智力型工做工程師來講，是很不合適的考量指標。

由於優秀的程序員是經過減小代碼行數來增長功能的。

千行代碼Bug率，雖然沒有明確鼓勵增長代碼行數，可是這個計算結果對於優秀的員工來講是至關的不公平。它隱含的推廣了「儘可能增大代碼行數」這個意思。

其次，從考覈階段看，Bug率的數據主要產出在研發階段的後期，及提交測試後產出bug數。從項目的研發階段和效率價值金字塔來看，其對項目的總體質量方面更多的聚焦在微觀層面問題，總體的質量的影響範圍會較小。而前面幾個階段的缺陷，會影響整個項目的進度，甚至致使項目失敗，管理者和團隊更應該將風險控制和度量指標向前移。 

    

 

研發階段和效率價值金字塔

 

 

如何更合理的度量質量

若是考覈千行代碼Bug率不能很好的解決質量核心問題，那咱們還有那些方法和方案來提升項目的總體質量呢？ 
我的以爲，咱們仍是從項目的研發階段和效率價值金字塔出發，重總體上去把控質量，上下游一體，從源頭開始：

1. 需求的評審 
2. 架構設計方案評審 
3. 代碼模塊設計，包的依賴的規劃，接口的設計的review
4. 代碼的review的機制 
5. 測試用例評審
6. 使用代碼檢測工具，自動發現問題

 

過程評審是最有效也是成本最低的質量和效率保證和提高的手段。另外，過程評審仍是迅速提升新人能力及其成果物的規範性的一個有效手段。 
可是過程評審，也存在一些問題： 
1. 前期過分依賴於團隊的人員素質 
2. 規則的定義也比較難，產出很差量化 
3. 評審耗時多 
4. 團隊的意識不一致

對於過程評審的實施，最核心的統一團隊意識，團隊意識不一致時，效果必定很差。 意識意識不一致，在資源的投入上就會縮手縮腳；只有把過程評審作到位，才能體會到評審活動的高效，避免那種蜻蜓點水式的「評審」，是浪費時間，不是真正的評審。到位地完成評審後，會有那種對系統質量「踏實了」的感受，過程當中輔以嚴密的變動管理和風險控制手段，系統質量出大問題可行性會很小或者近乎爲零。

系統質量是要靠上游工程作出來的，並且上游的工做質量會更爲重要，上游的問題的影響範圍將更廣，對效率和價值的影響更大，應該是咱們重點關注的地方。僅僅依賴下游工程(種種測試)來把質量關，是十分低效，並且代價是很是昂貴的。

 

總結

想作有效的管理，就很難繞開度量的問題。在選擇度量指標上，大部分管理者老是傾向於關注容易度量的指標，而忽略難以度量的指標。可是容易度量的指標不必定是重要的，難以度量的反而多是重要的。 
軟件開發產出最直觀的結論就是一行行代碼，實際上代碼行數的多少並不表明價值的多少。當考覈不合理致使出現大量的複製，不合理的設計，大量的冗餘，不但難以理解和維護，甚至沒有實際運行起來。這樣就形成大量的時間浪費，同時也形成質量的嚴重腐化。 
而基於全過程的評審機制和持續改進方法，能夠很好的改善質量。但持續改進須要一個過程，需全團隊從認知達成一致，並共享問題，統一步調和規範，持續的執行和改進。

另外，從工程師自身來講，千行代碼Bug率用來自我評估和改進，仍是頗有價值的。