如何減少bug

通常的做法是通過更多的單元測試 (Unit test) 和code review，使得我們在開發階段發現更多的問題，從而減少bug數。的確，開發人員經常單元測試，具有良好的測試和編程習慣，在每次check-in之前，或每次打baseline之前，項目組都有代碼cross review，同級或跨級評審，自己代碼每日評審能大大保證代碼品質，在提交給測試組之前就消除大量的bug。但往往發現更大多數的bug是我們通過 Unit test和code review所不能發現的。為什嗎？

 

1.       首先是需求的不明確，比如客戶原先對軟體的部署的需求就是和一般軟體一樣，沒啥特定需求，後來項目進行到後期部署階段發現有更多的部署需求，比如Failover，並行部署，對vista的相容性等等。這些都帶來的新的問題和代碼修改量。

 

2.       其次是需求理解的偏差，設計理解的偏差，比如一個員工對保險業務不熟悉，去開發保險業務IT系統的時候，往往開發出來的功能和實際業務需求相差很遠。對需求理解的偏差，以及對設計理解的偏差，也有部分原因是因為溝通，沒有良好的溝通，導致沒有傾聽客戶的訴求和使用者的反饋，和客戶溝通的問題導致需求偏差，軟體沒有對客戶產生價值，這種bug的比例非常高。

 

3.       再次是程式員本身能力的限制，比如代碼前期都認真經過了單元測試和功能測試，但後期發現運行效率很低，效能不好，原因在於程式員是用他們不熟悉的語言進行開發，而且對效能設計沒有經驗，開發中根本沒有效能上的考慮。如何保證一個程式員進入一個項目開發之前，已經掌握了足夠的程式設計語言知識和技能，已經掌握了足夠的業務知識？如果這些程式員經過技術和業務兩方面的培訓，可能會避免這方面的問題。

 

4.       最後是沒有一套好的研發流程，品質管理體系，和配套的支援工具。這是最大的一個問題。如何找到一個適合自身公司文化和項目情況的process？

 

總之，軟體開發和編程是一項智力活動，從獲得需求、理解需求、程式設計、程式編碼（資料結構 + 演算法）、單元測試、功能測試、提交的整個過程中，任何一步出現偏差都可能產生bug。

 

當然，測試組的嚴格測試能保證軟體的品質，但問題是如何主動防範bug？

1.       程式員的技術能力和經驗很重要，比如：代碼設計能力，良好的編程習慣，良好的資料結構和演算法，編程規範的遵守，隨時資源的釋放，避免記憶體流失，避免導致效能下降的代碼，異常處理，以及對維護、部署、可用性、效能、穩定性的全面，良好的文檔和注釋習慣等等。另外，項目採用新的架構、架構或技術(例如Spring, Castle, WCF)，都會因為程式員不熟悉而引入更多的bug和風險。

 

2.       程式員的業務積累和經驗很重要，大大有助於對需求的理解和把握。這非常關鍵。例如一個程式員做過老版本的銀行清算系統，他不僅熟悉清算商務程序，而且知道老系統存在的問題，就會主動防止這些問題，準備高效的實現新系統。

 

3.       測試組的測試活動不僅僅是找出bug，而且要通過測試來規範項目開發過程，從而提高軟體產品的品質。測試通過了，bug都改完了，項目結束了？其實測試組可以總結和分析下bug產生的原因和分布，這個bug list和分布圖交給開發組長和開發人員，可以分析發現開發人員經常哪兒引入bug，從而在以後的開發活動中避免這些問題，實現項目組的積累。其實可能80%的bug分布在20%的模組，因此從各個方面分析bug的根源，可以總結出項目組可以改進的地方。

最後，從根本上來說，作為軟體產品與服務的提供者，只有真正理解客戶的業務、順應客戶的需求才能提供令客戶滿意的產品與服務。應當以一個使用者角色的眼光去重新審視為使用者提供的技術解決方案和產品，是否是使用者所真正關心的，是否真正解決了使用者的問題。對於客戶而言，最有價值的不是你掌握哪些技術，而是你能幫他們解決哪些問題，產生哪些價值。IBM推行OnDemand隨需應變的服務， 因為在當今市場競爭日趨激烈的今天，“求變” 已經是必不可少的生存法則。這個求變的過程，需要軟體公司到技術人員的蛻變，從靈活多變的業務，到隨需應變的技術，不管客戶的業務和管理流程、需求如何變化，技術都只是業務變革的推進動力和實現工具，bug free（無缺陷）的軟體背後其實是對業務和需求的深刻理解和行業積累，先進的技術實力，完善的品質管理體系，和軟體開發流程。