這篇文章不是我自己寫的，是從51CTO博客那邊轉過來的，覺得挺不錯的，又怕以後網址失效了，所以決定轉過來，讓大家也學習學習。
轉載時請務必以超鏈接形式標明文章 原始出處 、作者信息和本聲明。否則將追究法律責任。http://yaocoder.blog.51cto.com/2668309/789687
大型項目往往需要比較多的人員參與，如果輕視管理協調，工具的規範，代碼規範，版本發佈規範......那麼項目一定會逐步陷入失控的境地。
下面是我經歷過的而且認爲的一個比較理想的項目規範：
>開發模式
敏捷開發，選擇敏捷，是因爲我認爲敏捷的核心理念之中，“溝通”正好可以解決項目由於參與人員太多的協調問題，對於項目通常有需求討論會，設計評審會，節點總結和計劃會，相關人員都必須參與，這樣大家都會在瞭解目標的情況下去完成工作，避免因交流不暢帶來的偏離目標的情況。“迭代”大項目不可能一蹴而就，應該先搭好框架，然後逐漸豐富需求和功能；
>組合模式
結對編程（不是傳統意義上的結對）請參見我之前的文章《結對編程其實可以變變？》http://yaocoder.blog.51cto.com/2668309/773045
>工具的規範：
項目管理工具：JIRA（類似於禪道的項目管理工具）但是我感覺他更好用，功能也更齊全；
知識庫：WIKI（使用的是trac中的wiki功能），想想維基百科的用處吧，這相當於針對當前項目的一個知識庫，在這裏大家可以自己完善有關項目的知識，技術，小技巧，分享給大家，每個人都有權編輯訪問；
源碼控制：SVN，很難想象還有不引入源碼控制的項目；
自動構建：hudson，對於一個大項目光構建時間也得大半天，你還要手工構建嗎？
>項目佈局
參照開源項目的項目佈局；![]()
>代碼的規範
單元測試：C++選用Google Test（簡單易用），java選用JUnit；
代碼規範：C++選用的Google C++代碼規範，Java採用標準規範；
註釋規範：採用doxygen,方便你生成文檔；
日誌規範：程序的運行日誌在定位錯誤方面的作用之大我想大家都明白，用log4X（c，c++，java）；
代碼評審：如果你的代碼裏含有破窗口，你必須得修好，不會讓你搞砸整個代碼的；
>測試跟進：
需要質量管理部門隨着迭代開發也進行迭代的測試和迴歸測試