「UML 是瀑布式的東西，敏捷不需要」「畫圖浪費時間不如直接寫 code」——這些都是誤解。
先講結論
UML 的價值不是圖本身，是畫圖時逼你想清楚的那些問題。你不需要畫完美符合規範的圖，但你需要知道什麼問題用什麼圖最容易想通。14 種 UML 圖裡，你真正常用的只有 5 種。
結構圖 vs 行為圖
結構圖（靜態）：東西長什麼樣、零件之間什麼關係。
行為圖（動態）：這些零件怎麼互動、什麼條件下做什麼事。
搞清楚你要回答哪種問題，就知道該畫哪種圖。
最實用的 5 種圖
1. Sequence Diagram（最常用）
回答：一個操作從頭到尾，各元件怎麼互動？
什麼時候畫：跨多個服務的操作、debug 時追蹤 request 路徑、code review 解釋複雜呼叫鏈。
思維價值：逼你想每一步的 request/response 是什麼、哪裡可能 timeout、哪裡需要錯誤處理。
2. Class Diagram（最基本）
回答：程式碼結構是什麼？物件間什麼關係？
┌──────────────┐ ┌──────────────┐
│ User │ │ Order │
├──────────────┤ ├──────────────┤
│ - id: number │ 1──N│ - status: enum│
│ - email │ │ - total │
│ + login() │ │ + submit() │
└──────────────┘ └──────────────┘
什麼時候畫：設計 domain model、理解新 codebase 的核心物件、重構前看清現有結構。
思維價值：是「擁有」(has-a)、「是一種」(is-a)、還是「使用」(uses)？畫出來你會發現很多模糊的設計決策。
3. State Diagram（最容易忽略但最有用）
回答：一個物件有哪些狀態？怎麼轉換？
stateDiagram-v2 [*] --> Draft Draft --> Submitted : 使用者提交 Submitted --> Approved : 主管核准 Submitted --> Rejected : 主管退回 Rejected --> Draft : 使用者修改 Approved --> InProgress : 開始執行 InProgress --> Completed : 完成 InProgress --> Cancelled : 取消
什麼時候畫：任何有「狀態」的核心物件（訂單、工單、申請表）、code 裡出現大量 if (status === 'xxx') 的時候。
思維價值：每個狀態可以往哪走？不可以往哪走？什麼條件觸發轉換？——這正是最常出 bug 的地方。
4. Use Case Diagram（最適合溝通）
回答：系統有哪些使用者角色？每個角色能做什麼？
什麼時候畫：專案初期定義範圍、權限設計（RBAC）、跟非技術人員溝通。
5. Activity Diagram（流程圖進化版）
回答：業務流程的步驟、分支和並行。
什麼時候畫：複雜業務流程（審批、結帳、退貨）、有並行操作的場景、文字說不清的流程。
你不需要畫的圖
UML 有 14 種圖，但以下你幾乎不會用到：Object Diagram（debug 用 console.log 更直接）、Package Diagram（看資料夾結構就好）、Communication Diagram（Sequence Diagram 能表達同樣的事）、Timing Diagram（除非你做嵌入式）。
原則：只在文字或 code 說不清楚的時候才畫圖。
工具推薦
- Mermaid：文字語法生成圖、嵌入 Markdown，日常用這個就夠了
- draw.io：拖拉式、免費，需要美觀正式文件時用
- Excalidraw：手繪風格、即時協作，白板討論用
延伸閱讀
你上次畫圖是什麼時候？如果想不起來，你可能一直在用「寫 code 來思考」——簡單問題沒差，複雜問題需要先視覺化。不然等你寫完發現架構不對，改的成本可比畫圖貴多了。