軟件開發(fā)過程中，我們經(jīng)常遭遇各種各樣的問題，而本文就是要講解這些問題中最棘手的12個(gè)。讀完本文后，相信讀者會對它們影響開發(fā)效率的原委有個(gè)初步的認(rèn)識。
我們發(fā)現(xiàn)，有很多的文章、書籍都在闡述軟件的開發(fā)方法，為什么呢？個(gè)人以為那是因?yàn)樘岣邎F(tuán)隊(duì)的開發(fā)效率是一場永無止境的戰(zhàn)爭。軟件的開發(fā)技術(shù)日新月異，開發(fā) 團(tuán)隊(duì)只能不停地適應(yīng)這種革新（如果這個(gè)團(tuán)隊(duì)不是此項(xiàng)技術(shù)的領(lǐng)頭羊），否則只能消亡。而適應(yīng)很大的程度表現(xiàn)在效率和時(shí)間上，因?yàn)榭蛻魧浖|(zhì)量的要求是越來 越高，同時(shí)卻不希望延長開發(fā)周期。
我們知道，隨著軟件外包的到來，同一個(gè)團(tuán)隊(duì)的開發(fā)人員可能來自不同的國家，他們處在不同的時(shí)區(qū)，有著不同的文化背景。和其它行業(yè)的人一樣，開發(fā)人員往往喜歡把精力用在他們感興趣的任務(wù)上面，卻經(jīng)常忽略了更重要的事情——開發(fā)效率。
在軟件開發(fā)這個(gè)繁雜的世界里，作為一個(gè)項(xiàng)目經(jīng)理，也作為一個(gè)開發(fā)人員，我碰到過各種各樣的有趣的問題。這篇文章就羅列出了這些問題中最棘手的12個(gè)，并提供一些處理問題的參考意見。（原文請參見我的Blog：http://lauploix.blogspot.com）
1．維護(hù)的開銷是效率的敵人
軟件的維護(hù)需要很大的開銷，它很自然地把開發(fā)團(tuán)隊(duì)帶向低效。維護(hù)的開銷往往和代碼行數(shù)成比例，尤其當(dāng)代碼沒有經(jīng)過很好的測試的時(shí)候，這個(gè)情況尤為明顯。開發(fā)團(tuán)隊(duì)會發(fā)現(xiàn)：隨著代碼行數(shù)的增加，bug的數(shù)目也會隨之增長，當(dāng)然，bug產(chǎn)生的原因包括內(nèi)部因素和外部因素。內(nèi)部因素的的確確是我們的代碼的問題，而外部因素實(shí)際上并不是程序的bug，但是無論如何必須修正。
說得更詳細(xì)點(diǎn)，外部因素可能是你調(diào)用的代碼改變了，或者是運(yùn)行環(huán)境改變了。例如，一段Java代碼在JRE1.4下面工作得很好，客戶要求它升級到JRE 1.5下也能運(yùn)行。這個(gè)時(shí)候，如果不能運(yùn)行，你可能會聲明原因不在程序上。但是客戶可不管那么多，站在他的角度上，這就是你的程序的bug。
實(shí)際上，完美的程序是不存在的，在做項(xiàng)目計(jì)劃的時(shí)候必須考慮周全。因此，在開始編碼之前，你就應(yīng)該把維護(hù)的開銷算到軟件開發(fā)周期里去。甚至在思考怎樣編碼之 前就應(yīng)該思考怎樣去測試。而且，你還得考慮怎樣讓服務(wù)器自動(dòng)測試你的代碼——如果一個(gè)測試不能做到完全自動(dòng)化，那么它只能算作半個(gè)測試。只有讓測試做到完 全自動(dòng)化，團(tuán)隊(duì)才能在新的環(huán)境里毫不費(fèi)勁的測試自己的代碼，也可以迅速高效地對測試進(jìn)行擴(kuò)展。
剛剛提到的，你必須找到一種可行的方法能夠保證你的代碼能夠被自動(dòng)地測試，的確如此，但這也是在單元測試中存在的一個(gè)問題，因?yàn)閱卧獪y試不可能面面俱到。事實(shí)上，如果對測試進(jìn)行分層，測試的效率可能會大大提高（關(guān)于分層測試，將在后面作具體的闡述）。
2．開發(fā)人員討厭測試，他們不按照測試的規(guī)范去做
代碼在某個(gè)環(huán)境中能正常工作，就假想它在其它環(huán)境中也能正常工作，這是軟件開發(fā)人員的通病。在現(xiàn)實(shí)生活中，這根本就是不可能的，可開發(fā)人員卻生活在虛擬的完美世界中，他們認(rèn)為這個(gè)世界里萬事萬物都是完美的，不可能遭遇任何的問題。例如，一個(gè)J2EE程序在JBoss下工作正常，開發(fā)人員往往理所當(dāng)然地認(rèn)為在WebSphere下也能正常工作，事實(shí)卻未必。所以，開發(fā)人員有必要在所有的目標(biāo)平臺上測試代碼。否則，程序就有可能無法通過。
我相信，你一定需要一個(gè)框架，使你的程序能夠在任何平臺下工作，而且能夠把測試結(jié)果保存到數(shù)據(jù)庫中。概括地講一下過程：你寫好各種語言的測試代碼，它就可以 在各種平臺下自動(dòng)測試，保存測試結(jié)果。之后，你就可以查閱測試結(jié)果了。這個(gè)結(jié)果包括各個(gè)平臺下、各個(gè)版本的代碼的測試的歷史。
據(jù)我所知，某些工具支持這些功能。例如，BuildBot 開源項(xiàng)目正在為之而努力，至少在不久的將來可以實(shí)現(xiàn)這個(gè)目標(biāo)。
3．出現(xiàn)bug時(shí)，分析原因比修正錯(cuò)誤更耗時(shí)間
當(dāng)開發(fā)人員修改好代碼，并把它提交到代碼庫里的時(shí)候，你必須反應(yīng)迅速，及時(shí)地測試他（她）提交的代碼，這樣，如果測試不通過，開發(fā)人員就還記得他（她）剛剛修正過的地方，也很容易找到bug的原因所在。
時(shí)間一長，他可能就忘了，Bug出現(xiàn)時(shí)不得不查看代碼歷史，比較不同版本的代碼，直到代碼原因分析出來。很有可能光找原因就白白的耗費(fèi)了幾個(gè)小時(shí)，太不值得了！
我們發(fā)現(xiàn)，有很多的文章、書籍都在闡述軟件的開發(fā)方法，為什么呢？個(gè)人以為那是因?yàn)樘岣邎F(tuán)隊(duì)的開發(fā)效率是一場永無止境的戰(zhàn)爭。軟件的開發(fā)技術(shù)日新月異，開發(fā) 團(tuán)隊(duì)只能不停地適應(yīng)這種革新（如果這個(gè)團(tuán)隊(duì)不是此項(xiàng)技術(shù)的領(lǐng)頭羊），否則只能消亡。而適應(yīng)很大的程度表現(xiàn)在效率和時(shí)間上，因?yàn)榭蛻魧浖|(zhì)量的要求是越來 越高，同時(shí)卻不希望延長開發(fā)周期。
我們知道，隨著軟件外包的到來，同一個(gè)團(tuán)隊(duì)的開發(fā)人員可能來自不同的國家，他們處在不同的時(shí)區(qū)，有著不同的文化背景。和其它行業(yè)的人一樣，開發(fā)人員往往喜歡把精力用在他們感興趣的任務(wù)上面，卻經(jīng)常忽略了更重要的事情——開發(fā)效率。
在軟件開發(fā)這個(gè)繁雜的世界里，作為一個(gè)項(xiàng)目經(jīng)理，也作為一個(gè)開發(fā)人員，我碰到過各種各樣的有趣的問題。這篇文章就羅列出了這些問題中最棘手的12個(gè)，并提供一些處理問題的參考意見。（原文請參見我的Blog：http://lauploix.blogspot.com）
1．維護(hù)的開銷是效率的敵人
軟件的維護(hù)需要很大的開銷，它很自然地把開發(fā)團(tuán)隊(duì)帶向低效。維護(hù)的開銷往往和代碼行數(shù)成比例，尤其當(dāng)代碼沒有經(jīng)過很好的測試的時(shí)候，這個(gè)情況尤為明顯。開發(fā)團(tuán)隊(duì)會發(fā)現(xiàn)：隨著代碼行數(shù)的增加，bug的數(shù)目也會隨之增長，當(dāng)然，bug產(chǎn)生的原因包括內(nèi)部因素和外部因素。內(nèi)部因素的的確確是我們的代碼的問題，而外部因素實(shí)際上并不是程序的bug，但是無論如何必須修正。
說得更詳細(xì)點(diǎn)，外部因素可能是你調(diào)用的代碼改變了，或者是運(yùn)行環(huán)境改變了。例如，一段Java代碼在JRE1.4下面工作得很好，客戶要求它升級到JRE 1.5下也能運(yùn)行。這個(gè)時(shí)候，如果不能運(yùn)行，你可能會聲明原因不在程序上。但是客戶可不管那么多，站在他的角度上，這就是你的程序的bug。
實(shí)際上，完美的程序是不存在的，在做項(xiàng)目計(jì)劃的時(shí)候必須考慮周全。因此，在開始編碼之前，你就應(yīng)該把維護(hù)的開銷算到軟件開發(fā)周期里去。甚至在思考怎樣編碼之 前就應(yīng)該思考怎樣去測試。而且，你還得考慮怎樣讓服務(wù)器自動(dòng)測試你的代碼——如果一個(gè)測試不能做到完全自動(dòng)化，那么它只能算作半個(gè)測試。只有讓測試做到完 全自動(dòng)化，團(tuán)隊(duì)才能在新的環(huán)境里毫不費(fèi)勁的測試自己的代碼，也可以迅速高效地對測試進(jìn)行擴(kuò)展。
剛剛提到的，你必須找到一種可行的方法能夠保證你的代碼能夠被自動(dòng)地測試，的確如此，但這也是在單元測試中存在的一個(gè)問題，因?yàn)閱卧獪y試不可能面面俱到。事實(shí)上，如果對測試進(jìn)行分層，測試的效率可能會大大提高（關(guān)于分層測試，將在后面作具體的闡述）。
2．開發(fā)人員討厭測試，他們不按照測試的規(guī)范去做
代碼在某個(gè)環(huán)境中能正常工作，就假想它在其它環(huán)境中也能正常工作，這是軟件開發(fā)人員的通病。在現(xiàn)實(shí)生活中，這根本就是不可能的，可開發(fā)人員卻生活在虛擬的完美世界中，他們認(rèn)為這個(gè)世界里萬事萬物都是完美的，不可能遭遇任何的問題。例如，一個(gè)J2EE程序在JBoss下工作正常，開發(fā)人員往往理所當(dāng)然地認(rèn)為在WebSphere下也能正常工作，事實(shí)卻未必。所以，開發(fā)人員有必要在所有的目標(biāo)平臺上測試代碼。否則，程序就有可能無法通過。
我相信，你一定需要一個(gè)框架，使你的程序能夠在任何平臺下工作，而且能夠把測試結(jié)果保存到數(shù)據(jù)庫中。概括地講一下過程：你寫好各種語言的測試代碼，它就可以 在各種平臺下自動(dòng)測試，保存測試結(jié)果。之后，你就可以查閱測試結(jié)果了。這個(gè)結(jié)果包括各個(gè)平臺下、各個(gè)版本的代碼的測試的歷史。
據(jù)我所知，某些工具支持這些功能。例如，BuildBot 開源項(xiàng)目正在為之而努力，至少在不久的將來可以實(shí)現(xiàn)這個(gè)目標(biāo)。
3．出現(xiàn)bug時(shí)，分析原因比修正錯(cuò)誤更耗時(shí)間
當(dāng)開發(fā)人員修改好代碼，并把它提交到代碼庫里的時(shí)候，你必須反應(yīng)迅速，及時(shí)地測試他（她）提交的代碼，這樣，如果測試不通過，開發(fā)人員就還記得他（她）剛剛修正過的地方，也很容易找到bug的原因所在。
時(shí)間一長，他可能就忘了，Bug出現(xiàn)時(shí)不得不查看代碼歷史，比較不同版本的代碼，直到代碼原因分析出來。很有可能光找原因就白白的耗費(fèi)了幾個(gè)小時(shí)，太不值得了！