軟件項目肯定離不了文檔和管理工具，如果您的項目還沒有它們，那麽請從現在開始。那麽文檔是不是越多越好呢？老話說的好，合適的才是最好的。小而精的文檔和工具會讓我們事半功倍，大而全的文檔會讓我們疲於奔命，最後迷失在文檔的海洋中。
51CTO向您推薦上壹篇系列文章：《我們如何開始對項目進行管理：需要什麽樣的人》
我們寫代碼的都知道，錯誤的註釋比沒有註釋更可怕；同樣的，沒有及時得到更新的文檔比沒有文檔更可怕，因為文檔就是項目的註釋。那麽我們是否有必要去更新那些我們根本沒有用到的文檔呢？很顯然，那是非常沒有必要的，是對資源的浪費。文檔說起來其實就是壹個工具，是壹個讓我們開發時有依據，可以追溯開發過程以及記錄開發結果的工具。我們只有用到它，它才有存在的必要。
那麽文檔過於少或者幹脆沒有文檔，不是更簡潔？我想說：不寫代碼不是更簡潔？玩笑歸玩笑，沒有文檔或者文檔太少會導致的問題大家可能也都遇到過：那就是過程不可追溯，有些非常重要的邏輯沒有記錄，需要用到時團隊成員各執壹詞，甚至需要重新找客戶確認而是客戶認為我們不夠專業；有些非常重要的設計沒有記錄，導致代碼維護困難，以至於維護人員破口大罵開發人員寫的什麽垃圾代碼做的什麽垃圾設計。有些設計非常的巧妙，非常的值得學習，然而就是因為沒有留下記錄而被初學者如我壹樣的人罵了N次。在反省自己不夠聰明時，是否也該讓寫代碼的人反省壹下為什麽沒能留下點兒記錄？
有壹種觀點是最好的設計就是代碼，意思是代碼就是設計，代碼應該非常的優秀，可讀性特別好，讓人壹看就明白，我完全同意。如果代碼寫到這種程度，那文檔就真的沒用了。那麽請自問，您是這樣嗎？如果是，沒文檔，沒問題；如果不是，請把重要的東西寫下來。那麽，哪些是重要的呢？
哪些是必須的， 哪些是Optional的。對於哪些文檔更重要些，應該由項目的具體情況而定，特別是項目的大小，邏輯的復雜程度，人員的情況等等很多因素。在我做過的項目中，我個人認為最重要的壹些文檔和工具如下所述：
1， 功能說明書（Functional Specification）------按獨立功能劃分優先級，每壹條記錄都是壹個可交付物，都是壹個功能。整個文檔就描述了整個項目的交付功能和優先級。項目中的所有人，都應該關註這個文檔：測試用它來寫測試用例；開發人員用它來決定先開發哪個功能；PM用它來查看功能的完成和驗證狀態。它通常不應該內容過多（由項目規模決定），我覺得最多兩行字就可以描述壹個獨立工作的功能，至於對這個功能的理解，應該由負責它的程序員來完成。
2， 核心流程圖。這個流程圖可能描述了用戶使用該系統的過程；也可能描述系統中數據的流轉；也可能描述表單的流轉。總之，它描述壹個過程，這個過程對用戶來說非常重要。這個圖有時候也會被其它的圖，如順序圖代替。
3， 部署文檔。該文檔描述了該系統應該如何部署，它不壹定非要是壹個word文檔，也可能僅是壹個bat文件而已。這個文檔應該描述該項目如何部署，步驟是怎麽樣的，需要哪些文件，需要哪些硬件支持，以及需要註意什麽。部署歷來都不太被重視，大家覺得只要東西做出來了，部署不就是放上去嗎？其實不然。在經歷了壹定周期的開發後，開發過程中積累的配置，對環境的要求，在真正部署的時候很多就忘了，所以部署可能會花費很多沒必要的時間，我覺得這也是微軟要做daily build的原因之壹，每天都build壹個可用的版本，當然部署就沒有問題了。我們剛開始可能不需要每天都build壹個版本，但最少要壹周或者兩周部署壹個版本吧。每次部署都整理壹個自動化的腳本或者文檔，會讓妳最後上線的時候非常的從容。
4， 測試用例。我不是壹個測試人員，測試也是我覺得壹直沒有做到位的地方。客觀的說，我覺得用例應該花很大心思去編寫，就像用戶真正的在使用軟件壹樣。項目應該在設計和開發的時候就以滿足用例為目標，而不是開發完了才想起來用例，去測試，發現問題再修改，回頭想想，這可能就是測試驅動開發產生的原因吧。我們知道用戶發現錯誤修改的成本高於我們自己發現的錯誤；同樣的，設計和開發階段就解決的問題成本也遠遠小於測試階段發現的。正是，問題發現的越早，解決起來就越容易，成本就越低。
5， Bug管理工具。這個管理工具可以是壹個excel，當然，我並不推薦這麽做，畢竟excel卻是不那麽自動化。但是，只要比excel自動化壹點點兒的信息系統就可以了，它需要可以記錄問題，可以傳截圖，這就夠了。我推薦使用bug tracker，這是個dotnet開發的開源的bug管理工具，其實也可以管理需求，是非常實用的。
以上五個是我認為最重要的，我覺得是項目開始進行管理的階段必不可少的；而下面幾個，則是大家視情況可選的。
6， 核心類圖。這個可能是可選的，因為有時候，類的關於沒那麽復雜，也就沒有必要有這個圖；相反，則需要進行記錄。
7， 數據庫設計。數據庫設計文檔可能在review的時候用到。
8， 系統間接口圖。如果產品有若幹個子系統，如web service等等，那麽我認為需要壹個描述系統間接口和交互關系的圖，這個圖應該在設計的早期就開發出來供大家使用並且隨時保持更新和關註。
有了文檔和工具，是不是就壹切OK了呢？不對，就像大而全的文檔並不能幫助我們成功壹樣，有了文檔並不代表項目就能成功，如何維護和使用這些文檔和工具是相當重要的。每個文檔都應該有人去維護，那麽誰去做這個事呢？我認為項目經理應該經常拿著功能說明書開會，它也可以被看做是WBS的初級版本，可以被標註狀態和優先級；所有人都應該熟悉流程圖，並隨時提出對流程圖進行檢驗和review；應該指定壹個人負責構建，這並不需要花費很多時間，但是需要細心和壹些完美主義精神；測試人員自然要維護好測試用例；每個人特別是開發人員，都應該有壹種覺悟，那就是壹旦想起了哪些重要的邏輯，不管是業務的邏輯還是系統的算法，都應該記錄到bug管理工具上。Bug管理工具完全可以記錄這些零散但卻重要的東西，以便將來方便查詢。
在這裏我也是根據自己的經歷簡單的談了壹些我的看法，這並不是金科玉律，我還得說，合適妳的才是最好的。
（四） 代碼規範的選擇
做開發不可避免的遇到代碼規範，從上學時就會學習到壹些規範，但是每個公司都不同，那麽我們到底要遵守哪些規範呢？我個人認為，壹個合格的程序員應該可以隨時調整自己適應任何壹種規範，這是壹種職業素養和能力。而何時該遵循何種規範，這也有壹定的原則。
1， 在現有系統（代碼）基礎上進行開發。這種情況下，我們應該盡量的去遵循原有系統的規範，不論是命名還是註釋。因為如果這時妳非要按照自己的習慣寫，那麽系統就會出現兩種完全不同風格的代碼，這對將來的維護是壹種噩夢。但是，遵循原有規範不是遷就原有錯誤。如果發現原有的規範會造成壹定的問題，就要立刻改正，不能裝傻充楞假裝看不見。
2， 新建團隊開發新的系統。新建的團隊中團隊成員可能來自不同的環境，對規範的選擇傾向壹定是不完全壹樣的，此時要怎麽做呢？這時，項目的領導者應該組織大家壹起做壹個決定，討論如何定義變量，如何給控件取名等等。在出現意見不統壹又誰都說服不了誰的情況時，項目經理應該做出明確的決定。此時選擇壹種規範遠比同時遷就兩個人要來的好，不然造成新系統中存在兩種規範，同樣是維護的噩夢。
3， 穩定團隊開發新的系統。這種情況就容易得多，團隊穩定後團隊成員漸漸的了解了互相的習慣，互相學習後就更容易達成妥協。只要註意讓新加入的成員適應就可以了。
有人可能覺得代碼規範沒什麽大不了，功能正確沒有bug不就行了？當然，如果沒有bug那肯定沒問題，然而壹個系統運行到退休還沒有bug，哪位見過呢？我做了壹些運維工作之後才漸漸了解到，不同風格的代碼讀起來就像是壹會兒在赤道，壹會兒在南極，非常的痛苦，有時甚至會造成系統很多的不壹致，大大增加了維護的工作量。我們的目標之壹不就是增加系統的可維護性嗎？