影響軟件開發效率的12大殺手

　　軟件開發過程中，我們經常遭遇各種各樣的問題，而本文就是要講解這些問題中最棘手的12個。讀完本文后，相信讀者會對它們影響開發效率的原委有個初步的認識。
 
　　我們發現，有很多的文章、書籍都在闡述軟件的開發方法，為什么呢？個人以為那是因為提高 團隊的開發效率是一場永無止境的戰爭。軟件的開發技術日新月異，開發 團隊只能不停地適應這種革新（如果這個團隊不是此項技術的領頭羊），否則只能消亡。而適應很大的程度表現在效率和時間上，因為客戶對軟件質量的要求是越來 越高，同時卻不希望延長開發周期。

　　我們知道，隨著 軟件外包的到來，同一個團隊的開發人員可能來自不同的國家，他們處在不同的時區，有著不同的文化背景。和其它行業的人一樣，開發人員往往喜歡把精力用在他們感興趣的任務上面，卻經常忽略了更重要的事情——開發效率。

　　在軟件開發這個繁雜的世界里，作為一個 項目經理，也作為一個開發人員，我碰到過各種各樣的有趣的問題。這篇文章就羅列出了這些問題中最棘手的12個，并提供一些處理問題的參考意見。（原文請參見我的Blog：http://lauploix.blogspot.com）

　　1．維護的開銷是效率最大的敵人

　　軟件的維護需要很大的開銷，它很自然地把開發團隊帶向低效。維護的開銷往往和代碼行數成比例，尤其當代碼沒有經過很好的測試的時候，這個情況尤為明顯。開發團隊會發現：隨著代碼行數的增加，bug的數目也會隨之增長，當然，bug產生的原因包括內部因素和外部因素。內部因素的的確確是我們的代碼的問題，而外部因素實際上并不是程序的bug，但是無論如何必須修正。

　　說得更詳細點，外部因素可能是你調用的代碼改變了，或者是運行環境改變了。例如，一段 Java代碼在JRE1.4下面工作得很好，客戶要求它升級到JRE 1.5下也能運行。這個時候，如果不能運行，你可能會聲明原因不在程序上。但是客戶可不管那么多，站在他的角度上，這就是你的程序的bug。

　　實際上，完美的程序是不存在的，在做項目計劃的時候必須考慮周全。因此，在開始編碼之前，你就應該把維護的開銷算到軟件開發周期里去。甚至在思考怎樣編碼之 前就應該思考怎樣去測試。而且，你還得考慮怎樣讓服務器自動測試你的代碼——如果一個測試不能做到完全自動化，那么它只能算作半個測試。只有讓測試做到完 全自動化，團隊才能在新的環境里毫不費勁的測試自己的代碼，也可以迅速高效地對測試進行擴展。

　　剛剛提到的，你必須找到一種可行的方法能夠保證你的代碼能夠被自動地測試，的確如此，但這也是在單元測試中存在的一個問題，因為單元測試不可能面面俱到。事實上，如果對測試進行分層，測試的效率可能會大大提高（關于分層測試，將在后面作具體的闡述）。

　　2．開發人員討厭測試，他們不按照測試的規范去做

　　代碼在某個環境中能正常工作，就假想它在其它環境中也能正常工作，這是軟件開發人員的通病。在現實生活中，這根本就是不可能的，可開發人員卻生活在虛擬的完美世界中，他們認為這個世界里萬事萬物都是完美的，不可能遭遇任何的問題。例如，一個 J2EE程序在JBoss下工作正常，開發人員往往理所當然地認為在WebSphere下也能正常工作，事實卻未必。所以，開發人員有必要在所有的目標 平臺上測試代碼。否則，程序就有可能無法通過。

　　我相信，你一定需要一個框架，使你的程序能夠在任何平臺下工作，而且能夠把測試結果保存到數據庫中。概括地講一下過程：你寫好各種語言的測試代碼，它就可以 在各種平臺下自動測試，保存測試結果。之后，你就可以查閱測試結果了。這個結果包括各個平臺下、各個版本的代碼的測試的歷史。

　　據我所知，某些工具支持這些功能。例如，BuildBot 開源項目正在為之而努力，至少在不久的將來可以實現這個目標。

　　3．出現bug時，分析原因比修正錯誤更耗時間

　　當開發人員修改好代碼，并把它提交到代碼庫里的時候，你必須反應迅速，及時地測試他（她）提交的代碼，這樣，如果測試不通過，開發人員就還記得他（她）剛剛修正過的地方，也很容易找到bug的原因所在。

　　時間一長，他可能就忘了，Bug出現時不得不查看代碼歷史，比較不同版本的代碼，直到代碼原因分析出來。很有可能光找原因就白白的耗費了幾個小時，太不值得了！

原文轉自：http://www.anti-gravitydesign.com