我的結論是：統計Bug率有意義。但是統計千行代碼Bug率沒有意義。

為什么千行代碼Bug率是沒有意義的？

某公司最近出了一個方案，用來量化程序員的工作績效。叫做千行代碼Bug率。在一個統計周期內，程序員每增加或者修改的代碼行數與QA發現的Bug數，根據如下規則計算Bug率：

• 1000行代碼，1個bug，那么Bug率是100%；
• 2000行代碼，4個bug，那么Bug率是200%；
• 5000行代碼，3個Bug，那么Bug率是60%
• n行代碼，m個Bug，那么Bug率是m / n * 1000

先不考慮這個規則本身是否有問題。我覺得，所有和代碼行數掛鉤的績效統計，都是沒什么意義的。因為代碼行數是可以刷的。如果某個績效需要代碼行數越少越好，那么可以使用行數少的寫法；某個績效需要代碼行數越多越好，那么可以使用行數多的寫法。

例如，對于字符串賦值：a = '今天天氣竟然有40度，我要被烤化了。'，可以把它擴寫成：

a = ('今天天氣'
     '竟然有40'
     '度，我要'
     '被烤化了。'
    )

甚至再進一步，擴寫成：

a = '今天天氣'
b = '竟然有40'
c = '度，我要'
d = '被烤化了。'

e = (a 
     + b
     + c
     + d
     )
a = e

這三種寫法的效果完全一樣。

還有些功能，原本就一行原生代碼搞定。但是為了增加行數，故意使用第三方庫。這樣第三方庫的代碼行數也就統計進去了。代碼總行數增加，相當于分母增大，千行代碼Bug率就降下來了。

要縮寫也簡單，在Python里面，如果使用lambda表達式，通過非常炫技反人類的寫法，你可以把常規要40行的代碼縮成1行。但是這樣的一行代碼根本沒法維護。

為什么Bug率是有意義的？

對于一個有實際用處的項目代碼來說，Bug數是一個系統誤差，只能設法減少，但是沒有辦法變成0。

同樣實現一個功能，好的程序員能提前預判到別人會怎么使用，提前處理好非法邏輯和不合理的數據流程，從而降低Bug數。而差的程序員，寫出來的代碼，別人一用就出問題。因此，用Bug率來評判程序員水平，我覺得是合理的。但是從Bug數到Bug率，這個計算方法應該要精心設計。

開發階段

如果公司有QA的話，在軟件開發階段，一般產品經理會先提出需求，然后拉上開發和QA一起評測需求。QA會在需求評審會后，設計測試案例。這些測試案例是公開的，每個開發都會看到。

這些公開的測試案例，我覺得可以用來作為分母。程序員寫好了代碼，卻無法通過其中的部分測試案例。那就是程序員的水平不行。失敗的測試案例數/所有公開的測試案例數。可以作為衡量程序員水平的參考指標之一。好的程序員應該盡量讓這個比值為0.

但有時候，在測試的過程中，QA可能會臨時增加測試案例，這些案例是程序員提前不知道的。那么這些案例如果測試失敗了，也可以作為一個評判指標，用來評判程序員是否有提前預防的能力。但公平起見，可以給他乘以一個小于1的系數，降低它的權重：

開發階段Bug率 = (已經公開的測試案例數 + 系數 × 臨時增加的測試案例數) / 總測試案例數

說個題外話，今天我們不考慮單元測試數、單元測試覆蓋率這種問題。因為據我所知，國內互聯網公司會主動寫單元測試的程序員太少了。有時候，一個原本要寫單元測試的優秀程序員，進了某些大廠以后，迫于業務和工期壓力，也逐漸放棄了。所以我們今天只考慮QA的測試案例。

線上階段

如果只看QA的測試案例，可能會出現面向QA編程的問題。因為人是很聰明的，上有政策，下有對策。QA的一個測試API接口的案例，輸入5，輸出10.程序員直接在代碼里面判斷，如果輸入是5，直接返回10，跳過中間的所有邏輯。這樣就能100%通過QA的所有測試案例。但是這樣做對產品本身是沒有價值的。

市場是檢驗代碼質量的重要標準。程序質量好不好，上線以后，讓用戶來評測。

你永遠不知道你的用戶有多蠢，你永遠猜不透用戶會怎么使用你的產品。

用戶反饋的Bug，也可以用來評價代碼的好壞，進而反映出程序員的能力高低。但需要考慮下面兩個情況：

同一個功能，兩個程序員實現：

• A程序員寫出的功能一上線，用戶一用就報Bug
• B程序員寫出的功能上線很久了。幾十萬個用戶都正常使用，有個沙雕用戶亂操作，偶然暴露出了一個Bug。

大家憑主觀判斷都知道，B程序員應該比A程序員好。

我們再來考慮第二種情況，A程序員實現X功能，B程序員實現Y功能：

X功能每天會被使用幾百萬次，一周就發現了二十多個Bug

Y功能一個月總共就被用了3次。沒有發現Bug

這種情況下，我們沒有辦法根據Bug數來判斷AB兩個程序員誰更好。也許B程序員去寫X功能，一天就會被發現上百個Bug也說不定。

因此，根據這兩種情況，我拍腦袋總結了一個經驗公式：

某功能線上Bug率 = Bug數 / (log(功能使用次數 + 1) + 1)

其中的log?是以10為底的對數。因為一個功能很輕松就能使用上百上千次，而Bug數一般來說就是個位數或者兩位數。因此對使用次數求個對數，避免Bug率太小。公式中的兩次+1。一次是因為不能對0求對數，另一次是分母不能為0.

對程序員開發的多個線上功能的Bug率統計，我們可以這樣計算：

程序員線上Bug率 = A功能線上Bug率 * 功能重要性系數 + B功能線上Bug率 * 功能重要性系數 + ……

其中，相同重要性的功能，他們的功能重要性系數應該是相同的。不同重要性的功能，功能越重要，這個系數就越大。

這里，這個系數應該用功能重要性系數?還是功能復雜性系數，我們可以討論一下。我個人是覺得用重要性比較好。一方面是代碼復雜性不好量化。第二是因為程序員的代碼質量和業務是不能分開看的。對于重要的功能，應該優先做，應該更用心。在更用心的情況下bug還那么多，不就說明能力差嗎。對于不重要的功能，最后做，可能后面時間來不及了，趕工完成有一些Bug。但是因為這個功能沒什么人用，對業務影響不大，有一些Bug也沒什么。

拍腦袋綜合公式

綜合開發階段與線上階段，我們可以得出一個綜合公式。由于一般來說，某某率的值范圍應該是0-100%，這兩個公式合在一起以后，結果很可能大于1.因此我們改個名字，叫做程序員Bug指數：

程序員Bug指數 = 開發階段Bug率 * 開發階段系數 + 程序員線上Bug率 * 線上階段系數

這個指數越高，說明程序員能力越差。

最后還是強調一下，以上公式是我拍腦袋想出來的，僅做參考。但我認為它的價值應該比千行代碼Bug率高得多。

最后，歡迎大家留言討論，你們公司是怎么評估程序員能力水平和代碼質量的呢？