[筆記]3.軟體代碼中的BUG問題的一些記錄

題記

你越瞭解你的對手——BUG，你的測試就越做的更好，軟體品質就越可靠。

雖然很難將其他組織的經驗資料應用到自己所在的組織，甚至有些資料和直覺相反，但你需要行動起來，藉助一些方法，評估自己的情況，去改進。

 

BUG不是均勻分布

如果沒有經過分析，自然的想法是BUG的分布會比較分散的，等機率的存在於整個系統。事實上經典的2-8原則這裡依然有效：

20%的類/子程式中存在80%的BUG，換言之，20%的類/子程式佔用了80%的開發成本;甚至有人統計出50%的BUG存在於5%的類中；

有資料說IBM對自己的OS/360作業系統的分析發現，只佔少數的容易出問題的子程式每千行代碼BUG高達50個，修複的代價是開發整個系統的成本的10倍(這個成本包括了客戶支援和現場維護)

 因為複雜造成BUG集中的類/子程式，則需要設計時考慮降低複雜度，已經開發的應該考慮重構方案。

 

大多數BUG的影響範圍是有限的

研究發現，85%的BUG可以在修改不超過一個類/子程式的範圍內被修正。

 

大部分BUG都很容易修正

大約85的BUG可以在幾個小時內修正；大約15%的BUG需要幾個小時到幾天；只有不到15的BUG需要更長的時間；

 

程式員錯誤理解設計引起的BUG的情況

有研究表明16%的BUG是這個原因造成的，另一個研究結果該原因帶來了19%的BUG。因此花點時間徹底瞭解設計是很值得的。

 

軟體設計編碼之外最常見的三種BUG源頭：

缺乏應用領域的知識；

頻繁變動或者矛盾的需求；

溝通和協調的失效；

 

軟體設計構件期的BUG源頭分布情況是：

95%的BUG是程式開發人員造成的，系統軟體造成的為2%，硬體原因為1%，其他軟體為2%；

 

特別的，拼字錯誤是一個很常見的BUG源

不同類型的軟體系統，拼字帶來的BUG情況差別是比較大，從4%到36%不等。

想一想人類有史以來三個最昂貴的軟體BUG——分別價值16億、9億和2.45億美元，都是因為一個不正確的字元造成的。

我自己曾經因為把user拼字為uesr帶來很大麻煩，昨天下午檢查資料庫資料時又無意中發現一個把organization拼字為organiztion的BUG。

 

業界經驗，在已經發行的大多數軟體中平均千行代碼中有1-25個BUG。

微軟的資料是自我裝載千行代碼有10-20個缺陷，已經發布的產品則下降為0.5。

國防和航天類系統則能達到每50萬行0個BUG的水平。

有報告宣稱使用TSP方式的開發小組，可以達到千行代碼0.06個BUG的水平。

 

除開特殊類型的軟體系統，一般情況下，開發高品質的軟體，比開發低品質軟體然後修正的成本要低。

 

不再調試上花時間？——這是一個很有價值，並值得努力的目標