建站
咨詢
售后
建站咨詢
新聞中心
我的結論是：統(tǒng)計Bug率有意義。但是統(tǒng)計千行代碼Bug率沒有意義。
成都創(chuàng)新互聯(lián)服務項目包括黔西南州網(wǎng)站建設、黔西南州網(wǎng)站制作、黔西南州網(wǎng)頁制作以及黔西南州網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，黔西南州網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到黔西南州省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
為什么千行代碼Bug率是沒有意義的？
某公司最近出了一個方案，用來量化程序員的工作績效。叫做千行代碼Bug率。在一個統(tǒng)計周期內，程序員每增加或者修改的代碼行數(shù)與QA發(fā)現(xiàn)的Bug數(shù)，根據(jù)如下規(guī)則計算Bug率：
- 1000行代碼，1個bug，那么Bug率是100%；
- 2000行代碼，4個bug，那么Bug率是200%；
- 5000行代碼，3個Bug，那么Bug率是60%
- n行代碼，m個Bug，那么Bug率是m / n * 1000
先不考慮這個規(guī)則本身是否有問題。我覺得，所有和代碼行數(shù)掛鉤的績效統(tǒng)計，都是沒什么意義的。因為代碼行數(shù)是可以刷的。如果某個績效需要代碼行數(shù)越少越好，那么可以使用行數(shù)少的寫法；某個績效需要代碼行數(shù)越多越好，那么可以使用行數(shù)多的寫法。
例如，對于字符串賦值：a = '今天天氣竟然有40度，我要被烤化了。'，可以把它擴寫成：
a = ('今天天氣'
'竟然有40'
'度，我要'
'被烤化了。'
)甚至再進一步，擴寫成：
a = '今天天氣'
b = '竟然有40'
c = '度，我要'
d = '被烤化了。'
e = (a
+ b
+ c
+ d
)
a = e
這三種寫法的效果完全一樣。
還有些功能，原本就一行原生代碼搞定。但是為了增加行數(shù)，故意使用第三方庫。這樣第三方庫的代碼行數(shù)也就統(tǒng)計進去了。代碼總行數(shù)增加，相當于分母增大，千行代碼Bug率就降下來了。
要縮寫也簡單，在Python里面，如果使用lambda表達式，通過非常炫技反人類的寫法，你可以把常規(guī)要40行的代碼縮成1行。但是這樣的一行代碼根本沒法維護。
為什么Bug率是有意義的？
對于一個有實際用處的項目代碼來說，Bug數(shù)是一個系統(tǒng)誤差，只能設法減少，但是沒有辦法變成0。
同樣實現(xiàn)一個功能，好的程序員能提前預判到別人會怎么使用，提前處理好非法邏輯和不合理的數(shù)據(jù)流程，從而降低Bug數(shù)。而差的程序員，寫出來的代碼，別人一用就出問題。因此，用Bug率來評判程序員水平，我覺得是合理的。但是從Bug數(shù)到Bug率，這個計算方法應該要精心設計。
開發(fā)階段
如果公司有QA的話，在軟件開發(fā)階段，一般產(chǎn)品經(jīng)理會先提出需求，然后拉上開發(fā)和QA一起評測需求。QA會在需求評審會后，設計測試案例。這些測試案例是公開的，每個開發(fā)都會看到。
這些公開的測試案例，我覺得可以用來作為分母。程序員寫好了代碼，卻無法通過其中的部分測試案例。那就是程序員的水平不行。失敗的測試案例數(shù)/所有公開的測試案例數(shù)。可以作為衡量程序員水平的參考指標之一。好的程序員應該盡量讓這個比值為0.
但有時候，在測試的過程中，QA可能會臨時增加測試案例，這些案例是程序員提前不知道的。那么這些案例如果測試失敗了，也可以作為一個評判指標，用來評判程序員是否有提前預防的能力。但公平起見，可以給他乘以一個小于1的系數(shù)，降低它的權重：
開發(fā)階段Bug率 = (已經(jīng)公開的測試案例數(shù) + 系數(shù) × 臨時增加的測試案例數(shù)) / 總測試案例數(shù)
說個題外話，今天我們不考慮單元測試數(shù)、單元測試覆蓋率這種問題。因為據(jù)我所知，國內互聯(lián)網(wǎng)公司會主動寫單元測試的程序員太少了。有時候，一個原本要寫單元測試的優(yōu)秀程序員，進了某些大廠以后，迫于業(yè)務和工期壓力，也逐漸放棄了。所以我們今天只考慮QA的測試案例。
線上階段
如果只看QA的測試案例，可能會出現(xiàn)面向QA編程的問題。因為人是很聰明的，上有政策，下有對策。QA的一個測試API接口的案例，輸入5，輸出10.程序員直接在代碼里面判斷，如果輸入是5，直接返回10，跳過中間的所有邏輯。這樣就能100%通過QA的所有測試案例。但是這樣做對產(chǎn)品本身是沒有價值的。
市場是檢驗代碼質量的重要標準。程序質量好不好，上線以后，讓用戶來評測。
你永遠不知道你的用戶有多蠢，你永遠猜不透用戶會怎么使用你的產(chǎn)品。
用戶反饋的Bug，也可以用來評價代碼的好壞，進而反映出程序員的能力高低。但需要考慮下面兩個情況：
同一個功能，兩個程序員實現(xiàn)：
- A程序員寫出的功能一上線，用戶一用就報Bug
- B程序員寫出的功能上線很久了。幾十萬個用戶都正常使用，有個沙雕用戶亂操作，偶然暴露出了一個Bug。
大家憑主觀判斷都知道，B程序員應該比A程序員好。
我們再來考慮第二種情況，A程序員實現(xiàn)X功能，B程序員實現(xiàn)Y功能：
X功能每天會被使用幾百萬次，一周就發(fā)現(xiàn)了二十多個Bug
Y功能一個月總共就被用了3次。沒有發(fā)現(xiàn)Bug
這種情況下，我們沒有辦法根據(jù)Bug數(shù)來判斷AB兩個程序員誰更好。也許B程序員去寫X功能，一天就會被發(fā)現(xiàn)上百個Bug也說不定。
因此，根據(jù)這兩種情況，我拍腦袋總結了一個經(jīng)驗公式：
某功能線上Bug率 = Bug數(shù) / (log(功能使用次數(shù) + 1) + 1)
其中的log?是以10為底的對數(shù)。因為一個功能很輕松就能使用上百上千次，而Bug數(shù)一般來說就是個位數(shù)或者兩位數(shù)。因此對使用次數(shù)求個對數(shù)，避免Bug率太小。公式中的兩次+1。一次是因為不能對0求對數(shù)，另一次是分母不能為0.
對程序員開發(fā)的多個線上功能的Bug率統(tǒng)計，我們可以這樣計算：
程序員線上Bug率 = A功能線上Bug率 * 功能重要性系數(shù) + B功能線上Bug率 * 功能重要性系數(shù) + ……
其中，相同重要性的功能，他們的功能重要性系數(shù)應該是相同的。不同重要性的功能，功能越重要，這個系數(shù)就越大。
這里，這個系數(shù)應該用功能重要性系數(shù)?還是功能復雜性系數(shù)，我們可以討論一下。我個人是覺得用重要性比較好。一方面是代碼復雜性不好量化。第二是因為程序員的代碼質量和業(yè)務是不能分開看的。對于重要的功能，應該優(yōu)先做，應該更用心。在更用心的情況下bug還那么多，不就說明能力差嗎。對于不重要的功能，最后做，可能后面時間來不及了，趕工完成有一些Bug。但是因為這個功能沒什么人用，對業(yè)務影響不大，有一些Bug也沒什么。
拍腦袋綜合公式
綜合開發(fā)階段與線上階段，我們可以得出一個綜合公式。由于一般來說，某某率的值范圍應該是0-100%，這兩個公式合在一起以后，結果很可能大于1.因此我們改個名字，叫做程序員Bug指數(shù)：
程序員Bug指數(shù) = 開發(fā)階段Bug率 * 開發(fā)階段系數(shù) + 程序員線上Bug率 * 線上階段系數(shù)
這個指數(shù)越高，說明程序員能力越差。
最后還是強調一下，以上公式是我拍腦袋想出來的，僅做參考。但我認為它的價值應該比千行代碼Bug率高得多。
最后，歡迎大家留言討論，你們公司是怎么評估程序員能力水平和代碼質量的呢？
文章題目：統(tǒng)計千行代碼Bug率，有沒有意義？
本文鏈接：http://www.5511xx.com/article/cogjscd.html
