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

為什么千行代碼Bug率是沒(méi)有意義的？

某公司最近出了一個(gè)方案，用來(lái)量化程序員的工作績(jī)效。叫做千行代碼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ī)則本身是否有問(wèn)題。我覺(jué)得，所有和代碼行數(shù)掛鉤的績(jī)效統(tǒng)計(jì)，都是沒(méi)什么意義的。因?yàn)榇a行數(shù)是可以刷的。如果某個(gè)績(jī)效需要代碼行數(shù)越少越好，那么可以使用行數(shù)少的寫(xiě)法；某個(gè)績(jī)效需要代碼行數(shù)越多越好，那么可以使用行數(shù)多的寫(xiě)法。

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

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

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

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

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

這三種寫(xiě)法的效果完全一樣。

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

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

為什么Bug率是有意義的？

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

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

開(kāi)發(fā)階段

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

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

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

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

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

線上階段

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

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

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

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

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

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

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

我們?cè)賮?lái)考慮第二種情況，A程序員實(shí)現(xiàn)X功能，B程序員實(shí)現(xiàn)Y功能：

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

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

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

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

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

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

對(duì)程序員開(kāi)發(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è)人是覺(jué)得用重要性比較好。一方面是代碼復(fù)雜性不好量化。第二是因?yàn)槌绦騿T的代碼質(zhì)量和業(yè)務(wù)是不能分開(kāi)看的。對(duì)于重要的功能，應(yīng)該優(yōu)先做，應(yīng)該更用心。在更用心的情況下bug還那么多，不就說(shuō)明能力差嗎。對(duì)于不重要的功能，最后做，可能后面時(shí)間來(lái)不及了，趕工完成有一些Bug。但是因?yàn)檫@個(gè)功能沒(méi)什么人用，對(duì)業(yè)務(wù)影響不大，有一些Bug也沒(méi)什么。

拍腦袋綜合公式

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

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

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

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

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