通常的做法是通過更多的
單元測(cè)試 （Unit
test） 和code review，使得我們?cè)陂_發(fā)階段發(fā)現(xiàn)更多的問題，從而減少bug數(shù)。的確，開發(fā)人員經(jīng)常單元測(cè)試，具有良好的測(cè)試和編程習(xí)慣，在每次check-in之前，或每次打baseline之前，項(xiàng)目組都有代碼cross review，同級(jí)或跨級(jí)評(píng)審，自己代碼每日評(píng)審能大大保證代碼質(zhì)量，在提交給測(cè)試組之前就消除大量的bug。但往往發(fā)現(xiàn)更大多數(shù)的bug是我們通過 Unit test和code review所不能發(fā)現(xiàn)的。為什么？
1、首先是需求的不明確，比如客戶原先對(duì)軟件的部署的需求就是和一般軟件一樣，沒啥特定需求，后來項(xiàng)目進(jìn)行到后期部署階段發(fā)現(xiàn)有更多的部署需求，比如Failover，并行部署，對(duì)vista的兼容性等等。這些都帶來的新的問題和代碼修改量。
2、其次是需求理解的偏差，設(shè)計(jì)理解的偏差，比如一個(gè)員工對(duì)保險(xiǎn)業(yè)務(wù)不熟悉，去開發(fā)保險(xiǎn)業(yè)務(wù)IT系統(tǒng)的時(shí)候，往往開發(fā)出來的功能和實(shí)際業(yè)務(wù)需求相差很遠(yuǎn)。對(duì)需求理解的偏差，以及對(duì)設(shè)計(jì)理解的偏差，也有部分原因是因?yàn)闇贤?，沒有良好的溝通，導(dǎo)致沒有傾聽客戶的訴求和用戶的反饋，和客戶溝通的問題導(dǎo)致需求偏差，軟件沒有對(duì)客戶產(chǎn)生價(jià)值，這種bug的比例非常高。
3、再次是程序員本身能力的限制，比如代碼前期都認(rèn)真經(jīng)過了單元測(cè)試和功能測(cè)試，但后期發(fā)現(xiàn)運(yùn)行效率很低，性能不好，原因在于程序員是用他們不熟悉的語言進(jìn)行開發(fā)，而且對(duì)性能設(shè)計(jì)沒有經(jīng)驗(yàn)，開發(fā)中根本沒有性能上的考慮。如何保證一個(gè)程序員進(jìn)入一個(gè)項(xiàng)目開發(fā)之前，已經(jīng)掌握了足夠的編程語言知識(shí)和技能，已經(jīng)掌握了足夠的業(yè)務(wù)知識(shí)？如果這些程序員經(jīng)過技術(shù)和業(yè)務(wù)兩方面的培訓(xùn)，可能會(huì)避免這方面的問題。
4、最后是沒有一套好的研發(fā)流程，質(zhì)量管理體系，和配套的支持工具。這是最大的一個(gè)問題。如何找到一個(gè)適合自身公司文化和項(xiàng)目情況的process？
總之，軟件開發(fā)和編程是一項(xiàng)智力活動(dòng)，從獲得需求、理解需求、程序設(shè)計(jì)、程序編碼（數(shù)據(jù)結(jié)構(gòu) + 算法）、單元測(cè)試、功能測(cè)試、提交的整個(gè)過程中，任何一步出現(xiàn)偏差都可能產(chǎn)生bug。
當(dāng)然，測(cè)試組的嚴(yán)格測(cè)試能保證軟件的質(zhì)量，但問題是如何主動(dòng)防范bug？
1、程序員的技術(shù)能力和經(jīng)驗(yàn)很重要，比如：代碼設(shè)計(jì)能力，良好的編程習(xí)慣，良好的數(shù)據(jù)結(jié)構(gòu)和算法，編程規(guī)范的遵守，隨時(shí)資源的釋放，避免內(nèi)存泄漏，避免導(dǎo)致性能下降的代碼，異常處理，以及對(duì)維護(hù)、部署、可用性、性能、穩(wěn)定性的全面，良好的文檔和注釋習(xí)慣等等。另外，項(xiàng)目采用新的架構(gòu)、框架或技術(shù)（例如Spring， Castle， WCF），都會(huì)因?yàn)槌绦騿T不熟悉而引入更多的bug和風(fēng)險(xiǎn)。
2、程序員的業(yè)務(wù)積累和經(jīng)驗(yàn)很重要，大大有助于對(duì)需求的理解和把握。這非常關(guān)鍵。例如一個(gè)程序員做過老版本的銀行清算系統(tǒng)，他不僅熟悉清算業(yè)務(wù)流程，而且知道老系統(tǒng)存在的問題，就會(huì)主動(dòng)防止這些問題，準(zhǔn)備高效的實(shí)現(xiàn)新系統(tǒng)。
3、測(cè)試組的測(cè)試活動(dòng)不僅僅是找出bug，而且要通過測(cè)試來規(guī)范項(xiàng)目開發(fā)過程，從而提高軟件產(chǎn)品的質(zhì)量。測(cè)試通過了，bug都改完了，項(xiàng)目結(jié)束了？其實(shí)測(cè)試組可以總結(jié)和分析下bug產(chǎn)生的原因和分布，這個(gè)bug list和分布圖交給開發(fā)組長和開發(fā)人員，可以分析發(fā)現(xiàn)開發(fā)人員經(jīng)常哪兒引入bug，從而在以后的開發(fā)活動(dòng)中避免這些問題，實(shí)現(xiàn)項(xiàng)目組的積累。其實(shí)可能80%的bug分布在20%的模塊，因此從各個(gè)方面分析bug的根源，可以總結(jié)出項(xiàng)目組可以改進(jìn)的地方。
最后，從根本上來說，作為軟件產(chǎn)品與服務(wù)的提供者，只有真正理解客戶的業(yè)務(wù)、順應(yīng)客戶的需求才能提供令客戶滿意的產(chǎn)品與服務(wù)。應(yīng)當(dāng)以一個(gè)用戶角色的眼光去重新審視為用戶提供的技術(shù)解決方案和產(chǎn)品，是否是用戶所真正關(guān)心的，是否真正解決了用戶的問題。對(duì)于客戶而言，最有價(jià)值的不是你掌握哪些技術(shù)，而是你能幫他們解決哪些問題，產(chǎn)生哪些價(jià)值。IBM推行OnDemand隨需應(yīng)變的服務(wù)， 因?yàn)樵诋?dāng)今市場(chǎng)競(jìng)爭(zhēng)日趨激烈的今天，“求變” 已經(jīng)是必不可少的生存法則。這個(gè)求變的過程，需要軟件公司到技術(shù)人員的蛻變，從靈活多變的業(yè)務(wù)，到隨需應(yīng)變的技術(shù)，不管客戶的業(yè)務(wù)和管理流程、需求如何變化，技術(shù)都只是業(yè)務(wù)變革的推進(jìn)動(dòng)力和實(shí)現(xiàn)工具，bug free（無缺陷）的軟件背后其實(shí)是對(duì)業(yè)務(wù)和需求的深刻理解和行業(yè)積累，先進(jìn)的技術(shù)實(shí)力，完善的質(zhì)量管理體系，和軟件開發(fā)流程。