//代碼質量一直以來是大家關注的問題。
//以下爲摘抄別人的文章，覺得不錯，回去要好好總結考慮一下。
最近致力於產品質量的保障和提升工作，首先希望解決的就是代碼質量問題。不受約束的程序代碼，就像是一個潘多拉寶盒，打開以後讓人驚喜連連，當然，目前我所體會到的是驚遠遠大於喜。
要想提升代碼質量，首先需要確立質量意識。
質量、功能和進度，一個軟件項目/產品的三根支柱，但在現實項目中，當質量和其它兩項產生衝突時，質量往往是被犧牲的對象。團隊對於質量的態度主要停留在
口頭重視上，似乎還沒有上升到團隊意識的高度，也缺乏必要的保障手段。但沒有質量的功能，從它面世第一天就開始永無止境的修補，並最終走向被重寫的命運，
沒有質量的進度，只能是一個虛僞的承諾，因爲接踵而至的，是一輪又一輪的 附加開銷，有效進度被大大拖延。
要想培養團隊的質量意識，需要培訓。
要讓每一個代碼貢獻人員，明白什麼是好，什麼是差，以及如何從差變好。我們準備使用四種形式的不定期會議來進行團隊培訓。
1、知識性培訓
。
爲團隊選定一個教材範圍，教材可以是書籍、文章，制定閱讀計劃。完成一個階段的閱讀後，指定某些團隊成員組織培訓材料，交流讀書心得。這是理論教育。
2、代碼交流會。
有人稱它爲團隊江湖中的“華山論劍”。團隊成員可以自告奮勇，拿出自己寫的好的或者差的代碼進行公開講解，以分享自己的經驗或者請求其他人提供改善的意見。必須注意，要明確表態，這個會議的結論不與員工考評掛鉤，以創造良好、開放的交流氛圍。
3、個人發佈會。
在一個模塊開發完畢，且完成單元測試，準備提交測試部門之前，由模塊負責人主持召開內部發佈會，邀請其他組感興趣的同事參加。這個會議的功效是多樣的：
保障模塊發佈質量，爲了不在發佈會上出醜，負責人會更加謹慎的對自己的作品進行測試。
可以加強團隊成員之間的聯繫。
有利於成員形成對產品的整體認識，減少盲人摸象的感覺，提升團隊歸屬感。
提高發布人的協調組織和公衆表達能力。
4、問題分析會。
問題分析會有一定的針對性和警示作用，氣氛相對嚴肅。尋找代碼中出現頻度較高，或者影響較大，或者有典型意義的質量問題，進行深入的分析。
有了培訓，還需要量化代碼質量的改善情況，這方面計劃採納如下手段：
1、統一工具。
以CVS客戶端爲例，團隊中有三種使用模式：Eclipse，Eclipse+CVSNT，CVSNT。已經出現過多次因爲在不同環境下拷貝文件而造成的版本混亂或者衝突。團隊中的工具和使用模式，有必要進行統一，並給予best practice方面的培訓。
2、採用更好的項目構建平臺。
準備採用Maven替換現有的ant。這個已經做了比較細緻的調研和對比，有機會我在後續的文章中進行詳述。Maven相比ant的最大優勢，在與
Maven是從管理的角度看問題，而ant的主要長處在與將重複性工作自動化。所以，我說，maven是一個平臺，一套規範，而ant只是一個工具罷了。
3、採納Sonar代碼質量管理平臺
簡單的說，Sonar繼承了FindingBugs，PMD，CheckStyle等很多知名的開源靜態代碼分析工具和自動測試工具，可以生成詳細的代碼分析質量報告，並通過web界面展示出來。
我們希望通過Sonar平臺來關注主要的質量指標的變化情況，如：重複代碼量、註釋比例、代碼複雜度、測試覆蓋度等。這方面的使用心得，有機會我在後續的文章中進行詳述。
4、堅持代碼評審。
代碼評審，這是最常規的質量控制手段，我就不多說了。
看起來很好，但我知道實施起來任重道遠。質量問題，需要做持續的改善。