我的結(jié)論是：統(tǒng)計(jì)Bug率有意義。但是統(tǒng)計(jì)千行代碼Bug率沒有意義。

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

某公司最近出了一個(gè)方案，用來量化程序員的工作績效。叫做千行代碼Bug率。在一個(gè)統(tǒng)計(jì)周期內(nèi)，程序員每增加或者修改的代碼行數(shù)與QA發(fā)現(xiàn)的Bug數(shù)，根據(jù)如下規(guī)則計(jì)算Bug率：

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

先不考慮這個(gè)規(guī)則本身是否有問題。我覺得，所有和代碼行數(shù)掛鉤的績效統(tǒng)計(jì)，都是沒什么意義的。因?yàn)榇a行數(shù)是可以刷的。如果某個(gè)績效需要代碼行數(shù)越少越好，那么可以使用行數(shù)少的寫法；某個(gè)績效需要代碼行數(shù)越多越好，那么可以使用行數(shù)多的寫法。

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

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

甚至再進(jìn)一步，擴(kuò)寫成：

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

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

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

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

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

為什么Bug率是有意義的？

對于一個(gè)有實(shí)際用處的項(xiàng)目代碼來說，Bug數(shù)是一個(gè)系統(tǒng)誤差，只能設(shè)法減少，但是沒有辦法變成0。

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

開發(fā)階段

如果公司有QA的話，在軟件開發(fā)階段，一般產(chǎn)品經(jīng)理會(huì)先提出需求，然后拉上開發(fā)和QA一起評(píng)測需求。QA會(huì)在需求評(píng)審會(huì)后，設(shè)計(jì)測試案例。這些測試案例是公開的，每個(gè)開發(fā)都會(huì)看到。

這些公開的測試案例，我覺得可以用來作為分母。程序員寫好了代碼，卻無法通過其中的部分測試案例。那就是程序員的水平不行。失敗的測試案例數(shù)/所有公開的測試案例數(shù)?？梢宰鳛楹饬砍绦騿T水平的參考指標(biāo)之一。好的程序員應(yīng)該盡量讓這個(gè)比值為0.

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

開發(fā)階段Bug率 = (已經(jīng)公開的測試案例數(shù) + 系數(shù) × 臨時(shí)增加的測試案例數(shù)) / 總測試案例數(shù)

說個(gè)題外話，今天我們不考慮單元測試數(shù)、單元測試覆蓋率這種問題。因?yàn)閾?jù)我所知，國內(nèi)互聯(lián)網(wǎng)公司會(huì)主動(dòng)寫單元測試的程序員太少了。有時(shí)候，一個(gè)原本要寫單元測試的優(yōu)秀程序員，進(jìn)了某些大廠以后，迫于業(yè)務(wù)和工期壓力，也逐漸放棄了。所以我們今天只考慮QA的測試案例。

線上階段

如果只看QA的測試案例，可能會(huì)出現(xiàn)面向QA編程的問題。因?yàn)槿耸呛苈斆鞯?，上有政策，下有對策。QA的一個(gè)測試API接口的案例，輸入5，輸出10.程序員直接在代碼里面判斷，如果輸入是5，直接返回10，跳過中間的所有邏輯。這樣就能100%通過QA的所有測試案例。但是這樣做對產(chǎn)品本身是沒有價(jià)值的。

市場是檢驗(yàn)代碼質(zhì)量的重要標(biāo)準(zhǔn)。程序質(zhì)量好不好，上線以后，讓用戶來評(píng)測。

你永遠(yuǎn)不知道你的用戶有多蠢，你永遠(yuǎn)猜不透用戶會(huì)怎么使用你的產(chǎn)品。

用戶反饋的Bug，也可以用來評(píng)價(jià)代碼的好壞，進(jìn)而反映出程序員的能力高低。但需要考慮下面兩個(gè)情況：

同一個(gè)功能，兩個(gè)程序員實(shí)現(xiàn)：

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

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

我們再來考慮第二種情況，A程序員實(shí)現(xiàn)X功能，B程序員實(shí)現(xiàn)Y功能：

X功能每天會(huì)被使用幾百萬次，一周就發(fā)現(xiàn)了二十多個(gè)Bug

Y功能一個(gè)月總共就被用了3次。沒有發(fā)現(xiàn)Bug

這種情況下，我們沒有辦法根據(jù)Bug數(shù)來判斷AB兩個(gè)程序員誰更好。也許B程序員去寫X功能，一天就會(huì)被發(fā)現(xiàn)上百個(gè)Bug也說不定。

因此，根據(jù)這兩種情況，我拍腦袋總結(jié)了一個(gè)經(jīng)驗(yàn)公式：

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

其中的log?是以10為底的對數(shù)。因?yàn)橐粋€(gè)功能很輕松就能使用上百上千次，而Bug數(shù)一般來說就是個(gè)位數(shù)或者兩位數(shù)。因此對使用次數(shù)求個(gè)對數(shù)，避免Bug率太小。公式中的兩次+1。一次是因?yàn)椴荒軐?求對數(shù)，另一次是分母不能為0.

對程序員開發(fā)的多個(gè)線上功能的Bug率統(tǒng)計(jì)，我們可以這樣計(jì)算：

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

其中，相同重要性的功能，他們的功能重要性系數(shù)應(yīng)該是相同的。不同重要性的功能，功能越重要，這個(gè)系數(shù)就越大。

這里，這個(gè)系數(shù)應(yīng)該用功能重要性系數(shù)?還是功能復(fù)雜性系數(shù)，我們可以討論一下。我個(gè)人是覺得用重要性比較好。一方面是代碼復(fù)雜性不好量化。第二是因?yàn)槌绦騿T的代碼質(zhì)量和業(yè)務(wù)是不能分開看的。對于重要的功能，應(yīng)該優(yōu)先做，應(yīng)該更用心。在更用心的情況下bug還那么多，不就說明能力差嗎。對于不重要的功能，最后做，可能后面時(shí)間來不及了，趕工完成有一些Bug。但是因?yàn)檫@個(gè)功能沒什么人用，對業(yè)務(wù)影響不大，有一些Bug也沒什么。

拍腦袋綜合公式

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

程序員Bug指數(shù) = 開發(fā)階段Bug率 * 開發(fā)階段系數(shù) + 程序員線上Bug率 * 線上階段系數(shù)

這個(gè)指數(shù)越高，說明程序員能力越差。

最后還是強(qiáng)調(diào)一下，以上公式是我拍腦袋想出來的，僅做參考。但我認(rèn)為它的價(jià)值應(yīng)該比千行代碼Bug率高得多。

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