首先，為什麼需要系統設計文件?

的確，在某些開發周期短，人數少或是功能較單純的情境底下，可能有個單純的spec或是口頭溝通清楚就可以了。

但是，當今天討論到團隊合作，可能就沒有那麼單純了。

一個功能可能會被拆解成各個片段，分散下去給不同人執行。並且，系統的架構和可擴展性也變得重要。

怎麼說呢?

想像系統就是一個大拼圖，每一片拼圖都是我們自行設計的。

假設今天我們需要在加入一片新的拼圖，在不知道原本拼圖的形狀和完成的樣子的情況下，根本是不可能的任務。那麼再想想看，加設今天每個人都隨心所欲，按照自己的意思添加拼圖，這拼圖會變成什麼樣子!

所以，當討論到多人協作的時候，各種規則和文件就變得異常重要。

什麼是系統設計文件?

系統設計文件因應它的使用情境，可以有非常多種不同的解釋，這裡討論的文件定義如下:

存在目的:

1. 統一理解和溝通: 系統設計文件有助於團隊之間達成一致，確保開發者、設計者、PM、QA和其他相關人員對系統的功能、結構、技術等有統一的理解。避免了期望不一致所導致的種種問題。
2. 提高開發效率: 系統設計文件可以幫助提前規劃和考慮潛在的問題。且通過詳細的設計和技術選型，開發人員可以有清晰的路線圖，知道如何開始和推進開發，避免了反覆寫Code改Code的風險。

目標對象:

1. 前端開發人員
2. 後端開發人員
3. PM
4. QA
5. UI/UX設計師

使用情境:

1. 需求分析後的設計階段
2. 開發過程中
3. 測試和驗收階段
4. 任何需要針對此功能進行討論的階段

用活動圖製作系統設計文件:

針對前端的情境，包含大量的使用者互動，個人滿推薦使用UML中的活動圖來進行製作。

下面快速科普一下活動圖中的圖形們。

1. 活動 ( Activity ):

   表示一組Action。比如加入購物車這樣一個活動，會包含多個Action。
   

2. 行動 ( Action ):

   表示要執行的具體事件。比如使用者點擊畫面，呼叫某API等。
   

3. 流程控制 ( Control Flow ):

   表示行動的執行順序。
   

4. 物件流 ( Object Flow ):

   表示物件如何從一個行動移動到另一個行動。
   

5. 起始點 ( Initial Node ):

   表示行動的起始點。
   

6. 結束點 ( Activity Final Node ):

   表示所有行動的結束。
   

7. 物件節點 ( Object Node ):

   表示和行動相連的物件。
   

8. 邏輯判斷 ( Decision Node ):

   表示一個檢查點，依據條件選擇不同路徑。比如判斷資料筆數是否為0，true就加載資料，false就不做動。其實就是if判斷
   

9. 合併節點 ( Merge Node ):

   把從邏輯判斷分開的分支進行合併。
   

10. 分岔節點 ( Fork Node ):

    表示將一個行動拆分成多個。其實可以理解成switch case。
    

11. 組合節點 ( Join Node ):

    把從分岔節點拆開的路徑合併。
    

12. 泳道和區域 ( Swimlane and Partition ):

    提供一個將圖表依照不同角色進行分區的方式。更好的組織圖表。
    

下一篇文章我們會模擬一個需求，並使用上述規範繪製系統文件。