整理把文檔寫好的一些guide line，這些都是我工作過程中一些筆記，希望對大家有用。。。
---------------------------------------------------------------------------------------
寫文檔之前把目錄結構定下來
在寫文檔之前，通常已知道文檔應該需要包含哪些內容，所以應先把目錄結構寫好，並給到Review人員或者上級Leader進行Review，沒有問題之後纔開始文檔的編寫，好處是顯而易見的，比較資深的Review人員或者Leader可以通過目錄結構可以發現文檔錯誤和遺漏，發現錯誤的時間是在執行者寫文檔之前，而不是寫完整個文檔之後才發現，有時，目錄結構甚至由Leader來制定，或者在Leader的協助下制定，這樣做的目的是，最後出來的文檔，接近Leader想要的東西。
寫文檔的時間
什麼時候開始寫文檔？
最好的方式是，寫文檔貫穿整個工作週期，邊執行任務邊寫文檔，在文檔中記錄下工作步驟和分析過程，如果當工作完成並得到結論之後纔開始寫文檔，通常就變成了爲了文檔而文檔，寫作動力下降，影響質量，同時，文檔還可以起到監督工作的作用，避免工作發生了遺漏。
文檔的格式
首先是要有目錄索引（當然1,2頁的文檔可能不需要:))，同時頁眉或者頁頭要有頁碼，有些人容易把頁碼漏掉，如果別人不看電子版(領導都喜歡紙版)，打印出來再看的話，沒有頁碼會跟目錄對不上號：）
除了目錄外就是文檔的概述和正文等，下面將分別討論。
文檔的概述部分
文檔的源由 -- 寫出爲什麼要寫這個文檔，例如一份單元測試計劃,可以這麼寫源由, 每個程序員在完成自已的模塊編碼工作之後,都要對自已的模碼進行單元測試後才能將代碼提交到代碼倉庫,這份文檔用於制定單元測試的計劃，源由特別有助於新員工更容易地理解和學習開發流程和文檔的作用。
文檔的目的 -- 描述這份文檔描述些什麼內容, 解決了什麼問題等。
面向的讀者 -- 寫出你的文檔面向的是什麼樣的讀者，以及文檔中的章節是如何爲這些不同的讀者進行組織的，例如一份報告，主管通常希望能看到更多的分析細節，以方便考證最終的結論是否可靠，工作步驟是否有誤等，而工作時間非常寶貴的經理則只希望能夠在文檔中得到結論而並不關心分析的細節，因此要在這裏進行說明，他們應怎麼閱讀你的文檔，就可以以最短的時間得到他們想要的東西。
參考資料 -- 某些結論，可能是在某本書籍或某一篇文獻上得到的，你應該把它寫在文檔上，以便於讀者能追蹤到更多相關的內容。如果資料是在網上的，例如某一個URL上，你應該把內容下載下來，因此網址可能會過時無效。
文檔的正文編寫
文檔的正文怎麼寫, 一個簡單的理解就是把你想告訴別人的東西寫下來。
常常犯的一個錯誤是，只寫結論，而缺乏結論所經歷的分析過程。文檔的讀者通常開始猜測作者是如何得到這些結論，更糟糕的時，如果文檔交給另一個工程師Review, 這個負責Review的工程師需要（有意或無意地）將執行了與作者類擬的分析工作，才能確定文檔中的結論是正確的還是有誤，浪費了人力。
因此，分析過程和結論一樣重要，例如，按這樣的邏輯來組織文檔的內容：
1. 需求是什麼
2. 要實現這個需求共有多少種解決方案
3. 如何驗證這些方案是可行的
4. 比較每種解決方案有哪些優缺點
5. 選擇最後的解決方案，並說明爲什麼選擇該方案而丟棄其它方案
總之，讀者,有時是你的Leader需要從你的文檔中不僅僅是得到結論，還有得到你的思路。
附錄
可以摘錄一些與文檔相關的資料放在這裏，或者把一些速查表彙總在這裏以方便讀者查詢。
鳴謝
如果你的工作在執行的過程中，得到了一些同事的幫助才得以順利地進行，花費了他們寶貴的工作時間，那麼，在文檔的最後，應該感謝他們。