1.1.文檔的重要性
很多小夥伴在需求、開發、測試階段不注重文檔，認爲這耽誤時間、畫蛇添足。實際上文檔對於軟件行業是十分重要的。軟件的定義：軟件是包括程序、數據及其相關文檔的完整集合。
從這個定義中我們能夠體會到文檔的重要性。很多小夥伴常說要對線上數據保持敬畏，對線上程序保持敬畏，同樣的，我們也要對文檔保持敬畏，千萬不能輕視他。
往小裏說，文檔代表了傳承與積澱。我們在抱怨前輩沒有留下足夠的文檔、前輩文檔不規範時，有沒有想過通過自己的努力給後來者留下寶貴的積澱呢？贈人玫瑰，手留餘香，寫文檔的過程也是思考的過程，將不明確的明確，將不清晰的清晰，將有爭議的定論。
文人讀書是道，武人練武是道，開發者在工作中也要追尋自己的道，把能做到的做好。爲軟件行業的規範化貢獻自己的一份力量。
1.1.1.敏捷與文檔
敏捷開發與文檔是否衝突？CRM團隊一週一版本，需求零碎化，是否還需要寫文檔？這裏我們做下探討。
敏捷宣言：
個體和互動 高於 流程和工具；
工作的軟件 高於 詳盡的文檔；
客戶合作 高於 合同談判；
響應變化 高於 遵循計劃；
敏捷宣言中的要義十分值得我們去理解，但是我們這裏不做探討。重點看下第二點，這也是一些小夥伴疑惑的地方。
實際上，敏捷想要表達的是，軟件本身就能提供很多的信息，比如註釋，包結構等，具備專業知識的同學一看就能一目瞭然。我們需要的是“剛好足夠”的文檔，一些細節的信息不一定需要通過文字圖形等表達，代碼自然能說明一切。
小夥伴們對於這一點的理解比較容易矯枉過正，對於“剛好足夠”的理解過於簡單。這也是值的我們深思的一點，我們的文檔需要體現什麼？然後纔是去思考如何體現。
1.1.2.趕工與文檔
項目週期短，我只有兩天時間，晚上還要加班，要不要寫文檔？
換位思考一下，項目中的其他小夥伴能不能根據需求文檔和你的代碼註釋十分清晰的理解需求的背景、實現方式、交互流程等。只要有必要，都需要寫。
實際上，趕工是項目管理中即會增加資源消耗，也會增加風險的一種行爲。有文檔的指引能夠幫助我們減少風險，同樣也能減少由於返工、修復問題等消耗的資源。正所謂磨刀不誤砍柴工，提供“剛好足夠”的文檔，有利於提高我們的開發質量。
1.2.文檔的類型
在軟件開發週期中，我們可能會接觸到很多文檔，例如：需求規格說明書、概要設計、詳細設計、數據庫設計、測試計劃、測試說明、測試報告、部署方案、實施報告等。
每種文檔的關注點不同，在敏捷開發中，實際上我們可能會對其中的某些文檔進行合併、刪減，由於我們接下來主要討論的是概要設計，其他的我們也不展開討論。這裏借用一篇網上博文，可以窺探到這些文檔的功能與常用結構。
https://www.jianshu.com/p/a7984927cfb9
1.3.概要設計的常用結構
在軟件開發過程中，我們發現《概要設計》通常比較能滿足“剛好足夠”這個條件。
遇事不決先TODO，遇事不決總分總，遇事不決套模板。當我們不清楚設計文檔應該怎麼寫時，我們可以先來了解設計問題可以怎麼寫。
概要設計文檔中可以包含這些模塊：
【目的】【背景】可以表明文檔編寫意圖，指定預期的讀者；可以幫助我們瞭解需求的背景。
【術語及縮略語】可以給文中提到的名詞下定義，這裏不光是指一些比較專業的名詞，例如：覈銷。也可以是一些通用名詞，在特定的場景下的特定意思，例如：逾期，在特定的文檔中可以特指用戶在最晚繳費日前未繳費。
【參考資料】列出有關的資料。
【總體結構】
【系統架構】
【基本處理流程】
【關鍵邏輯多方案】在概要設計中可以對關鍵邏輯設計多個方案，經過評審後確定一個方案，其他方案可以不刪，體現思考過程、取捨過程。
【尚未解決的問題】
【接口設計】可以包括內部接口定義和外部接口依賴。
【數據庫設計】
【非功能設計】
概要設計文檔可以靈活的對這些涉及到的內容進行取捨，增對一些場景甚至可以增加條目，如【歷史數據處理】、【數據遷移方案】等。千萬不能像寫八股文一樣，也千萬不要寫成審查清單，這樣文檔的可讀性反而下降了。
1.4.常用的圖表
在上面提到的【系統架構】、【基本處理流程】等多處，我們可以利用圖形來表達我們的思想。在作圖時我們不能太隨意，儘量遵守各種圖形的一般表示方法，這樣別人也更好理解。當然也可以從美觀角度進行優化。
1.4.1.用例圖
用例圖主要用來描述角色以及角色與用例之間的連接關係。說明的是誰要使用系統，以及他們使用該系統可以做些什麼。用例圖包括這些元素：
關於每個元素的含義及用法，可以參考：
https://www.cnblogs.com/xiaolongbao-lzh/p/4590897.html
1.4.2.流程圖
流程圖主要用於展示過程步驟，大家對這個瞭解的也比較多。實際上流程圖在需求文檔中用的比較多，請善待願意在需求文檔中畫流程圖的產品，因爲他們認真思考過。
開發同事也可以用流程圖表示邏輯過程、邏輯步驟等。
1.4.3.泳道圖
泳道圖也叫活動圖，其實就是在流程圖的基礎上，增加了兩個維度。流程圖關注流程，泳道圖關注流程、階段、對象。
三維的圖形比較容易混亂，我們可以對其中一個維度進行降維。如捨棄階段，或者捨棄對象。
這樣可以比較清晰的表達思想。
1.4.4.ER圖
ER圖是實體-聯繫圖，提供了表示實體類型（長方形）、屬性（橢圓形）和聯繫（菱形）的方法。
關係有三種：1:1，1:N，M:N。
一個例子：
1.4.5.序列圖
序列圖主要用來更直觀的表現各個對象交互的時間順序，將體現的重點放在以時間爲參照，各個對象發送、接收消息，處理消息，返回消息的時間流程順序，也稱爲時序圖。
有這些要素：
需要注意的是消息、異步消息的區別，異步消息想表達的是不關心返回值。
1.4.6.類圖
類圖在概要設計中畫的比較少，核心邏輯、設計模式可以通過類圖更清晰的表現。
一個例子：
1.4.7.架構圖
我對這一塊一知半解，其實並不懂，其他類型的圖表有較爲清晰的表達方式，架構圖的表達方式比較靈活，用不同的軟件畫也有比較大的差異。期待了解的小夥伴能夠進行指導。
一個例子：
