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