今天在新浪微博上又看到有人討論千行代碼缺陷率，還討論的很細致——怎么計算，怎么統計....
引用郭德綱的一句話：統計那玩意兒沒用，一句話解決你心中所有疑惑。（原文是：學那玩意兒沒用）
首先我們來看看，千行代碼缺陷率是怎么定義的？
缺陷率 = 缺陷數量/ (代碼行數/1000)
然后看組織如何關心這個數字
越小越好
那么結論是什么？
沒有能力減少缺陷數量，就加大代碼行數唄
一些常見的招數
把 {單獨占一行
把 }else { 寫成
}
else
{
上面這些還只是影響到代碼可讀性，下面這些就有些奇葩了。
把定長循環分開寫，寫成順序方法
把配置文件的行數統計進去
而下面這些就令人發指了
復制、粘貼
重新發明輪子
-----------------
我們不怎么采用這些招數 ，可以用這個數字了吧?
統計“千行代碼缺陷率”和“每日生產代碼行數”一樣，都是沒經過大腦思考，而直接打算把優秀員工踢出團隊的懶人式管理方式。
因為優秀的程序員是通過減少代碼行數來增加功能的。
雖然沒有明確鼓勵增加代碼行數，但是這個計算結果對於優秀的員工來說是相當的不公平。它隱含的推廣了“盡量增大代碼行數”這個意思。
----------------
我們團隊的人能力都差不多，總可以用這個來衡量吧？
這句話的意思是在暗示“我們的團隊都很平庸”嗎？如果是這樣，那就更不要用這個數字了。因為平庸的人無法像優秀的人那樣
—— 爺寫的太高深你們看不懂 ——來自我安慰。他們經常會在這樣的毫無根據的數字面前自信心被打擊。
-----------------
公司管理體制要求，我們得統計吧？
不可否認，這么明顯的一個錯誤，還是有很多公司在犯，而且不犯這個錯誤都不好意思跟人打招呼。（還是以前那句話，SQA/PPQA都是一些不想、不願、不能寫代碼的人從事的，別指望他們做什么正確的事。我用一個比較惡毒的詞兒形容這些人：Salary Thief）
如果你的公司還在犯這個錯誤，那么你有若干種選擇：
1. 證明這個是錯誤的，然后從公司統計數據中抹掉它
2. 忍受，然后假裝自己很平庸，寫很長的代碼來稀釋缺陷密度
3. 離職，尋找一家不統計這個數字的公司
也許還有更多的選擇。
推薦看看 張松著的 《精益軟件度量》