? 我個人比較傾向于敏捷的方式，不贊同大而全的文檔，因為那樣的文檔書寫起來浪費時間，維護起來更浪費時間，更可怕的是沒有持續更新導致文檔與實際項目偏差很大的文檔。所以我認為文檔就是應該少而精，必須確保文檔的持續更新才有價值，具體的細節讓代碼去說，當然代碼本身要寫的可讀性高。

??? 今天和項目管理人員討論了一下，我覺得分為如下幾種情況：

1. 正規立項的項目：那個當然要安裝立項你當時承諾的給文檔。我建議是
? 1）如果有需求分析階段，那必須要出一個文檔來記錄這段時間的工作；
? 2）架構設計文檔是必須的，因為在代碼中是很難直觀看到整體的系統設計；
? 3）概要設計、詳細設計什么的我都不知道是想干什么，如果是說代碼的具體實現，那就到代碼中去看，沒必要維護這個文檔；
? 4）測試文檔：這個比較尷尬，這個應該是測試人員編寫的，但是我們現在的情況是自己測試，那么有測試就要有記錄，把測試的預期、測試的結果、測試的結論要寫清楚就行了，格式可以不限；
? 5）數據庫設計文檔：我個人認為這個寫文檔完全沒意義，在架構設計中把數據庫表結構的關聯關系說明即可，工程目錄下的db目錄里面必須有當前版本的建表語句，這樣就足夠了。
? 6）這個開發完的系統每次發布必須要有基線，release的版本要入庫。

2. common下的公共模塊或小系統：因為系統比較簡單，所以可以簡化一下。我建議是
? 1）要有簡單的架構設計說明
? 2）要有簡單的功能說明
? 3）要有使用說明，這個可以用測試類來代替，在使用說明上寫一下看哪些測試類就可以了
? 4）這個開發完的模塊需要有基線，并且要入庫。
? 其中這三個說明都直接寫在一個readme文件中就可以了，該文件放在工程的doc目錄下，可以方便的查閱。

3. example下的示例系統：這個就是個簡單的例子，沒有完整的系統功能，所以文檔方面同common要求即可，readme放在工程的doc目錄下。這個系統只需有基線，不用入庫走那么麻煩的流程。

??? 以上系統都必須有changelog的說明文檔，這個是能隨包發布的，也可以非常清晰的看到歷史改動以及版本變遷。寫changelog我認為是一個非常好的習慣，不管有沒有release note的管理。

本文轉自passover 51CTO博客，原文鏈接：http://blog.51cto.com/passover/566377，如需轉載請自行聯系原作者

總結

以上是生活随笔為你收集整理的项目文档管理的一些想法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。