軟件開發過程中，我們經常遭遇各種各樣的問題，而本文就是要講解這些問題中最棘手的12個。讀完本文後，相信讀者會對它們影響開發效率的原委有個初步的認識。
我們發現，有很多的文章、書籍都在闡述軟件的開發方法，爲什麼呢？個人以爲那是因爲提高團隊的開發效率是一場永無止境的戰爭。軟件的開發技術日新月異，開發 團隊只能不停地適應這種革新（如果這個團隊不是此項技術的領頭羊），否則只能消亡。而適應很大的程度表現在效率和時間上，因爲客戶對軟件質量的要求是越來 越高，同時卻不希望延長開發週期。
我們發現，有很多的文章、書籍都在闡述軟件的開發方法，爲什麼呢？個人以爲那是因爲提高團隊的開發效率是一場永無止境的戰爭。軟件的開發技術日新月異，開發 團隊只能不停地適應這種革新（如果這個團隊不是此項技術的領頭羊），否則只能消亡。而適應很大的程度表現在效率和時間上，因爲客戶對軟件質量的要求是越來 越高，同時卻不希望延長開發週期。
我們知道，隨着軟件外包的到來，同一個團隊的開發人員可能來自不同的國家，他們處在不同的時區，有着不同的文化背景。和其它行業的人一樣，開發人員往往喜歡把精力用在他們感興趣的任務上面，卻經常忽略了更重要的事情——開發效率。
在軟件開發這個繁雜的世界裏，作爲一個項目經理，也作爲一個開發人員，我碰到過各種各樣的有趣的問題。這篇文章就羅列出了這些問題中最棘手的12個，並提供一些處理問題的參考意見。（原文請參見我的Blog：[url]http://lauploix.blogspot.com[/url]）
1．維護的開銷是效率最大的敵人
軟件的維護需要很大的開銷，它很自然地把開發團隊帶向低效。維護的開銷往往和代碼行數成比例，尤其當代碼沒有經過很好的測試的時候，這個情況尤爲明顯。開發團隊會發現：隨着代碼行數的增加，bug的數目也會隨之增長，當然，bug產生的原因包括內部因素和外部因素。內部因素的的確確是我們的代碼的問題，而外部因素實際上並不是程序的bug，但是無論如何必須修正。
說得更詳細點，外部因素可能是你調用的代碼改變了，或者是運行環境改變了。例如，一段Java代碼在JRE1.4下面工作得很好，客戶要求它升級到JRE 1.5下也能運行。這個時候，如果不能運行，你可能會聲明原因不在程序上。但是客戶可不管那麼多，站在他的角度上，這就是你的程序的bug。
實際上，完美的程序是不存在的，在做項目計劃的時候必須考慮周全。因此，在開始編碼之前，你就應該把維護的開銷算到軟件開發週期裏去。甚至在思考怎樣編碼之 前就應該思考怎樣去測試。而且，你還得考慮怎樣讓服務器自動測試你的代碼——如果一個測試不能做到完全自動化，那麼它只能算作半個測試。只有讓測試做到完 全自動化，團隊才能在新的環境裏毫不費勁的測試自己的代碼，也可以迅速高效地對測試進行擴展。
剛剛提到的，你必須找到一種可行的方法能夠保證你的代碼能夠被自動地測試，的確如此，但這也是在單元測試中存在的一個問題，因爲單元測試不可能面面俱到。事實上，如果對測試進行分層，測試的效率可能會大大提高（關於分層測試，將在後面作具體的闡述）。
2．開發人員討厭測試，他們不按照測試的規範去做
代碼在某個環境中能正常工作，就假想它在其它環境中也能正常工作，這是軟件開發人員的通病。在現實生活中，這根本就是不可能的，可開發人員卻生活在虛擬的完美世界中，他們認爲這個世界裏萬事萬物都是完美的，不可能遭遇任何的問題。例如，一個J2EE程序在JBoss下工作正常，開發人員往往理所當然地認爲在WebSphere下也能正常工作，事實卻未必。所以，開發人員有必要在所有的目標平臺上測試代碼。否則，程序就有可能無法通過。
我相信，你一定需要一個框架，使你的程序能夠在任何平臺下工作，而且能夠把測試結果保存到數據庫中。概括地講一下過程：你寫好各種語言的測試代碼，它就可以 在各種平臺下自動測試，保存測試結果。之後，你就可以查閱測試結果了。這個結果包括各個平臺下、各個版本的代碼的測試的歷史。
據我所知，某些工具支持這些功能。例如，BuildBot 開源項目正在爲之而努力，至少在不久的將來可以實現這個目標。
3．出現bug時，分析原因比修正錯誤更耗時間
當開發人員修改好代碼，並把它提交到代碼庫裏的時候，你必須反應迅速，及時地測試他（她）提交的代碼，這樣，如果測試不通過，開發人員就還記得他（她）剛剛修正過的地方，也很容易找到bug的原因所在。
時間一長，他可能就忘了，Bug出現時不得不查看代碼歷史，比較不同版本的代碼，直到代碼原因分析出來。很有可能光找原因就白白的耗費了幾個小時，太不值得了！
4．開發人員在轉換項目過程中花費了太多的時間
通常來說，搭建一個項目的開發環境是不容易的。如果對項目沒有很好的瞭解，不具備一定的專業知識，要搭建好環境幾乎是不可能的。如果僅僅是搭建環境就花費很 長的時間，開發人員往往更希望長期呆在同一個項目環境中。比較理想的狀況是：開發人員有能力毫不費力的從一個項目轉到另一個項目，不存在技術難題，“項目 文化”已經不是個難題了。
對此，我有個建議：使用項目管理工具，比如Apache Maven。用Maven描述的項目一般很容易在Eclipse中搭建起來。對於Java項目來說，只需要要從SVN下載代碼，鍵入“maven eclipse”，刷新，它就可以工作了。所有與代碼對應的測試代碼也可以運行！哇，簡直是太神奇了！整個項目不到30秒就建好了。
很可惜，這項技術目前還只支持Java。至於其它的語言，如Python、C，等等，僅僅Maven還是不夠的。
5．隨着開發人員的增加，Bug也增加
如果方法不得當，一般來說，開發人員增加的同時，程序的bug數目也會增多；隨着程序的複雜性的增大，軟件的質量也會下降。而我們必須與之作鬥爭。那採取什麼方法呢？很簡單的理論：透明、代碼審查和自動測試。
透明能夠確保每個人都能得到代碼，決定誰去修改它，何時修改，或者是爲什麼要修改它。透明能夠確保團隊的每個人都會因爲自己的代碼質量而感到壓力，並由此而產生動力。
而代碼審查呢？開發人員對別人的代碼進行審查，不僅能夠從別人的代碼中學到東西，而且它還確保開發人員有效地發現代碼的問題，對提高代碼質量功不可沒。
至於自動測試，我們在下面進行詳解。
6．分層測試
不可否認，寫出好的測試代碼的確是個很大的挑戰。例如，代碼寫好後，對它們進行單元測試就很困難，單元測試不可能測試到程序運行的方方面面。功能性（質量保證）測試對程序測試相當有效，不過它通常運行慢，對問題發生的原因給出的信息往往很不夠。
因此，你不得不對測試進行拆分以克服這種情況。如果簡單的基礎測試都無法通過，那麼運行更大的測試顯然是無意義的。分層測試的目的就是讓測試從易到難。
——第0層：開發人員在自己本地環境中進行的單元測試。
——第1層：構建服務器上的單元測試，（幾乎每個）代碼提交之後開始。
——第2.1層：集成測試，在幾個模塊整合到一起之後進行的測試。（用真正的模塊代替掉原先的模擬模塊。例如，使用真正的XML解析器換掉原先的那個替代品）
——第2.2層：集成測試，通過入口訪問系統（接口、磁盤等等，到這兒，你可以測試訪問真正的系統）
——第3層：功能性測試，測試程序可見的部分。（用戶能夠看到的實實在在的功能，當然，這一層還不夠）
——第4層：性能測試。
——第5層：客戶體驗。（OK，這並不是一個測試層，但是這個環節的確會發現不少意料之外的bug）
這個方法的理念是同一個bug決不會再次重現。因而，對於每個你發現的bug，你都應該創建測試用例以保證它不會重現。這個測試可能是單元測試（這樣最好），也有可能是集成測試。
總之，問題發現得越早越好，這意味着我們可以更早修復它。所以如果某個問題能夠儘量的在第0層發現，我們就不要讓它等到第3層才發現。隨着測試代碼的增加，代碼質量也會越來越健壯。
7．嚴格限制使用編程語言的數目
如果你無論完成什麼任務都爲它選擇最好的工具，那麼當你的任務越來越多，你採用的工具也越來越多，這可不是什麼好事。如果你總是爲短期的目標選擇最便捷的方 法，系統的複雜性會隨之增加。所以，有時候，你不一定要選擇最好的工具。在同一個團隊裏，最好只使用一門語言，儘量不要超過兩種語言，否則單單培訓開發人 員的成本就不少。例如，Ruby on Rails就是個很好的工具，但是它涉及到不止一門語言和技術。在用它的某種技術開發網站之前，必須要考慮所有的花費。如果你們的主要活動就是開發網站，那麼這條規則對你並不適用，因爲在這種情況下，Ruby很可能變成你們項目組的主要語言了。
我的觀點是，選擇有限數目的編程語言。當然，你也必須確保這種技術對你們公司有用。例如，有必要用四種網絡服務框架嗎？沒必要，一種足矣。
8．緊跟技術的發展和革新，不過這個比較困難
我們很容易碰到這種情況，爲了實現某個功能你必須付出很大的努力，但是實際上已經有工具可以做到這點，但是我們卻不知道。如果我們關注着技術的發展，包括開 發框架的革新，方法的提出等等，就可以避免這種情況的出現。幸虧有這種關注的習慣，我發現了現在我用得幾乎所有的工具：Eclipse, Maven, Tomcat, Apache, LDAP, CruiseControl, TestNG, Python,等等。它們中大多數工具都可以爲我節省很多工作。有的項目本來需要幾個月的開發時間，結果縮短到幾周。
比較困難的就是如何去選擇工具（要花費很多時間去選擇工具），而且還得避免你的工作團隊同時使用太多的技術。有個建議，當使用某項技術還在實驗之中的時候，我們最好不要用，最好等到它已經實現了，有成熟的產品了。
另外一個挑戰就是評估、選擇新的技術。如果要對旗鼓相當、都是很有競爭力的框架進行評估，並從中選擇一兩個的話，這個難度一般也很大。
9．爲了保持效率，最好不要被頻繁地打斷
在解決複雜的問題的，開發人員一般需要7到15分鐘進入高效的狀態。如果從一個活動轉到另外一個活動（電話，電子郵件等等）就會打斷開發人員的進程。例如，如果一個團隊的開發人員每20分鐘就有個技術服務的電話騷擾他，哦，這完全是災難性的。因此，我們不應該允許用戶直接打開發人員的電話。
取而代之，我們應該建立一個工具收集問題、bug、需求等等來完成這些工作，這樣開發人員就可以專心致志地忙他的本職工作。這樣的工具很多，包括Mantis 和Jira。
另外一點，記住，開發人員並不是機器，他是人。爲什麼項目經理要求開發人員記住——存儲——他們的要求？難道他就不能把他的要求寫下來嗎？
10．定義好構架與編碼同等重要
在沒有構架的基礎上進行編碼如同在沒有燈光的夜晚駕車。你有可能達到你的目的地，但是行程很慢，也很危險。如果有構架師，他就會經常審覈原始的產品，預測可能出現的問題。缺少了構架師，系統能難有很好的框架，如果每次加進一個新功能，系統複雜度就會大大增加。
即使編碼沒問題，據我所見到的走捷徑的項目，基本上都多多少少存在些問題。這就是產品構架師應該對產品的框架有一個全局的概念的重要原因。
11．開發人員和產品使用者考慮的重點不同
開發人員總是對“有趣”的任務感興趣，而產品的使用者總是希望產品的功能對他的客戶有用。開發過程中，應該儘量地做到，至少應該使這兩個目標比較接近：讓開發人員解決比較無趣的問題時也讓他很高興。
據我所看到，Scrum就 是個不錯的軟件管理方法。它主張在一個開發過程裏，開發人員準時地提交結果，這時，開發人員的自尊心就會成爲一個強大的動力。當然，當項目經理提出某一個 用處並不大的需求時，如果開發人員很難準時提交結果，也就是說，這個功能需求在實現上困難很大，但是又沒有很大的用處，這個時候項目經理應該在提需求之前 三思，是否有必要提這個需求。當然，有時間可以研究一下，Scrum方法的確相當不錯。
12．代碼規約很高效，必須強制執行
代碼規約把開發人員從理解代碼的格式上解放出來，讓他們有更多的時間去理解代碼的核心含義。在我工作的團隊裏，我們建立了自己的規約，包括代碼存放的目錄，文件名，還有代碼本身（類的名字、方法、變量等等）。
某些SVN插件甚至可以禁止不符合代碼規約的代碼提交。呵呵，不錯！
● 將影響效率的問題消滅在萌芽狀態
大多數開發過程和方法的目的就是爲了解決效率問題。本文指出了開發過程中的幾個我觀察到的並牢記在心的問題。希望你能夠從我的經驗中學到些東西，同時，世上並沒有那種解決方案是銀彈，我建議看看Scrum，因爲它的確提高了開發中各個環節的效率。