
1. 從diagram-design這個標題能讀出什么第一次看到diagram-design這個標題我的直覺是這不是一個具體工具的名字而是一類工作的統(tǒng)稱——圍繞圖做設計。圖可以是流程圖、架構圖、時序圖、狀態(tài)機圖、思維導圖、數據流圖甚至是手繪風格的概念草圖。標題里沒有限定領域也沒有指定工具這恰恰說明它指向的是一個通用能力把抽象的邏輯關系、系統(tǒng)結構、業(yè)務流程用可視化的方式表達清楚。很多人第一次接觸畫圖這件事會覺得它是個體力活——拖拖拽拽、對齊連線、調調顏色就完事了。但真正做過復雜系統(tǒng)設計的人都知道圖的質量直接決定了溝通效率。一張好的架構圖能讓新人在五分鐘內理解系統(tǒng)邊界一張糟糕的圖能讓團隊開三小時的會還在爭論這個箭頭到底代表什么。所以diagram-design這個標題背后真正要解決的不是怎么畫而是怎么把復雜信息壓縮成一張能被正確理解的圖。這篇文章適合三類人看第一類是需要頻繁輸出技術圖但總覺得畫出來不夠清晰的工程師第二類是要給非技術角色講清楚系統(tǒng)邏輯的產品或項目人員第三類是對可視化表達有興趣、想建立一套自己畫圖方法論的人。我會從設計原則、工具選型、實操流程、常見坑幾個角度展開盡量把為什么這樣畫講透而不是只給一堆模板。2. 畫圖之前先想清楚圖到底為誰服務2.1 圖的三種讀者決定了三種畫法我踩過最大的一個坑就是曾經用同一張架構圖去應付三個不同的場合給領導匯報、給開發(fā)講解、給運維交接。結果三個場合的人都不滿意。領導覺得太細開發(fā)覺得太粗運維覺得缺關鍵信息。后來我才明白圖不是客觀真理它是針對特定讀者的信息壓縮包。讀者不同壓縮策略就完全不同。給決策者看的圖核心是邊界和關系。他們不關心你用了什么消息隊列、分幾個分片他們關心的是這個系統(tǒng)跟哪些外部系統(tǒng)有交互、數據從哪來到哪去、出問題的時候影響面有多大。所以這類圖要克制細節(jié)用大色塊區(qū)分模塊用粗箭頭表示主數據流把次要的調用關系弱化甚至省略。給開發(fā)者看的圖核心是接口和時序。他們需要知道模塊之間通過什么協(xié)議通信、調用順序是什么、異常分支怎么處理。這類圖適合用時序圖或帶標注的流程圖把關鍵參數、超時設置、重試策略都標出來。我習慣在時序圖旁邊加一個異常路徑的小圖專門畫失敗重試和降級邏輯這個習慣幫我省了很多口頭解釋。給運維看的圖核心是部署和依賴。他們關心的是服務部署在哪些節(jié)點、依賴哪些中間件、監(jiān)控指標從哪采集、故障時先看哪個面板。這類圖適合用部署圖或網絡拓撲圖把 IP 段、端口、健康檢查路徑都標清楚。一個實用的判斷方法畫圖之前先問自己這張圖給誰看他看完之后要做什么決定。如果答不上來說明你還沒想清楚先別打開畫圖工具。2.2 一張圖只講一件事新手最容易犯的錯是想在一張圖里塞下所有信息。我見過一張系統(tǒng)全景圖上面同時畫了業(yè)務流程圖、數據流、部署拓撲、監(jiān)控告警密密麻麻像電路板。作者很得意覺得信息量大但讀者根本找不到入口。我的經驗是一張圖只回答一個問題。如果一個問題需要多個視角才能說清就拆成多張圖然后用一張索引圖把它們串起來。比如描述一個訂單系統(tǒng)我會拆成四張訂單狀態(tài)流轉圖回答訂單有哪些狀態(tài)、怎么流轉、下單時序圖回答一次下單經過哪些服務、部署拓撲圖回答這些服務部署在哪、數據模型圖回答訂單數據怎么存。每張圖都簡單但合起來信息完整。拆圖的好處不只是清晰還在于可維護。系統(tǒng)改了某個流程我只需要更新對應的那一張圖不用動其他三張。如果全塞在一張圖里改一處就要重新調整全局布局成本極高。2.3 先定圖例再畫內容這個習慣我是從一位做數據可視化的前輩那里學來的。他的做法是任何一張正式圖先在角落畫一個圖例區(qū)定義清楚每種形狀、每種顏色、每種線型代表什么。比如實線代表同步調用、虛線代表異步消息、紅色代表失敗路徑、藍色代表正常路徑。聽起來很基礎但實際工作中大量圖是沒有圖例的。結果就是讀者靠猜這個虛線框是可選模塊還是外部系統(tǒng)這個菱形是判斷還是數據存儲一旦讀者開始猜圖的溝通價值就大打折扣。圖例還有一個隱藏好處它逼你在畫之前統(tǒng)一語義。很多時候我們畫到一半才發(fā)現(xiàn)前面用圓形表示服務后面又用矩形表示服務風格不一致。如果先定圖例這種問題在動筆前就解決了。3. 工具選型別在工具上糾結太久3.1 三類工具的適用邊界關于畫圖工具我的態(tài)度很明確工具不重要重要的是你能不能快速改。因為圖幾乎一定要改需求變了要改、系統(tǒng)演進要改、讀者反饋要改。如果一個工具改起來很痛苦你就不愿意改圖就會慢慢過期最后沒人看。我把常見工具分成三類。第一類是代碼生成類用文本描述圖工具渲染成圖片。這類工具的最大優(yōu)勢是版本可控、diff 清晰、改起來快。適合架構圖、時序圖、狀態(tài)機圖這類結構性強、需要頻繁迭代的圖。缺點是樣式調整不夠靈活想要精細的視覺設計比較費勁。第二類是拖拽繪制類就是傳統(tǒng)的畫圖軟件。優(yōu)勢是自由度高想怎么擺就怎么擺適合概念草圖、需要精細排版的匯報圖。缺點是改起來麻煩而且不同人畫出來的風格很難統(tǒng)一。第三類是白板協(xié)作類適合頭腦風暴階段的快速草圖。優(yōu)勢是多人實時協(xié)作適合討論。缺點是正式輸出時通常需要重新整理因為白板上的圖往往比較隨意。我的實際組合是討論階段用白板類工具快速畫草圖確定結構后用代碼生成類工具產出正式圖只有需要對外匯報、對視覺要求高的場合才用拖拽類工具精修。這樣既保證了迭代速度又保證了正式輸出的質量。3.2 為什么我優(yōu)先推薦代碼生成類很多人覺得用代碼畫圖很反直覺——畫圖不是應該所見即所得嗎但我用了幾年之后越來越傾向于代碼生成。原因有三個。第一改起來真的快。系統(tǒng)加了一個服務我只需要在文本里加一行重新渲染就完事了不用手動調整周圍所有元素的位置。拖拽工具里加一個節(jié)點往往要重新對齊一整片區(qū)域。第二版本管理友好。文本文件可以進代碼倉庫每次改動都有記錄誰在什么時候改了什么一目了然。圖片文件做不到這一點你只能看到圖變了但不知道變了哪里。第三強制你關注結構而非樣式。用代碼畫圖時你描述的是A 調用 BB 依賴 C而不是A 這個框放在 B 左邊顏色調成淺藍。這種約束反而讓你更專注于邏輯本身畫出來的圖通常更清晰。當然代碼生成類工具也有短板。比如復雜的嵌套布局、非標準的視覺元素實現(xiàn)起來比較別扭。所以我的建議是結構性的圖用代碼生成視覺性的圖用拖拽工具不要強求一個工具解決所有問題。3.3 一個容易被忽略的選型維度協(xié)作成本選工具時大家通常看功能但我認為協(xié)作成本更關鍵。所謂協(xié)作成本就是別人要改你這張圖需要付出多少學習成本。如果團隊里只有你一個人會用某個冷門工具那這張圖就成了你的私有資產你一休假就沒人能改。反過來如果工具足夠普及、語法足夠簡單團隊里其他人能快速上手圖的維護就不再依賴單個人。所以我在團隊里推工具時會優(yōu)先選語法簡單、文檔齊全、上手快的。哪怕功能少一點只要大家都能改就比功能強大但只有一個人會用要好。這個原則在人員流動頻繁的團隊里尤其重要。4. 一套可復用的畫圖流程4.1 第一步用一句話寫下圖的主題聽起來很傻但這一步能過濾掉大量無效工作。如果我不能用一句話說清這張圖要表達什么那說明我還沒想清楚畫出來大概率是廢圖。這句話的格式我習慣用這張圖展示 X 在 Y 條件下的 Z。比如這張圖展示訂單服務在正常下單場景下的調用時序、這張圖展示系統(tǒng)與外部支付渠道的邊界關系。有了這句話后面所有內容都要服務于它不相關的信息一律砍掉。4.2 第二步列出所有元素先不畫關系確定主題后我會先把圖里要出現(xiàn)的所有元素列出來——有哪些服務、哪些數據存儲、哪些外部系統(tǒng)、哪些角色。這一步只列清單不畫連線。列清單的好處是防止遺漏。畫圖時很容易畫著畫著發(fā)現(xiàn)哎這個服務忘了然后臨時插入導致布局混亂。先列全再統(tǒng)一布局效率高很多。列完之后我會做一次篩選哪些元素是核心哪些是次要。核心元素放在視覺中心次要元素放在邊緣。這個主次關系直接決定了讀者第一眼看哪里。4.3 第三步先畫主干再補分支布局時我遵循主干優(yōu)先原則。先把最主要的幾條關系畫出來比如主調用鏈、主數據流確保主干清晰。然后再補異常分支、次要依賴、監(jiān)控采集這些輔助信息。這樣做的原因是讀者的注意力是有限的如果主干和分支混在一起畫讀者很難分辨哪些是重點。先畫主干相當于給讀者一條閱讀路徑他順著主干看下去再根據需要看分支。我見過很多圖的問題就在于沒有主干——所有連線看起來同等重要讀者不知道從哪看起。這種圖通常是因為作者沒有區(qū)分主次把所有關系都平鋪了。4.4 第四步加標注但只加必要的標注是圖的注釋能大幅提升信息密度但加多了會變成噪音。我的原則是只標注讀者會問的問題。比如時序圖里我會標注關鍵的超時時間、重試次數、冪等鍵。因為這些是讀者看的時候一定會問的這個調用失敗了怎么辦會不會重復下單提前標出來就不用口頭解釋了。但像這個服務用什么語言寫的這個數據庫是什么版本這類信息除非跟圖要表達的主題直接相關否則不加。加了只會讓圖變亂。4.5 第五步找人試讀收集看不懂的點圖畫完之后我會找一個沒參與設計的人試讀讓他說出他理解的內容然后對比我想表達的內容。差異點就是需要修改的地方。這一步非常關鍵但很多人省略了。因為作者對自己的圖太熟悉了會自動腦補缺失的信息看不出問題。只有沒背景的人才能暴露真正的歧義。試讀時我通常問三個問題這張圖在講什么你覺得哪個部分是核心有沒有你看不懂的地方根據回答調整通常改兩三版就能達到自解釋的程度。5. 那些年我踩過的畫圖坑5.1 坑一追求好看犧牲清晰剛工作那會兒我特別在意圖的顏值——配色要高級、陰影要柔和、圓角要統(tǒng)一。結果花了兩小時調樣式圖是好看了但邏輯一團糟。后來被一位前輩點醒圖的第一目標是讓人看懂不是讓人夸好看?,F(xiàn)在我畫圖樣式一律從簡黑白灰為主最多用兩三種顏色區(qū)分模塊形狀只用矩形和圓角矩形連線只用直線和折線。把省下來的時間花在邏輯梳理上圖的溝通效果反而更好。當然對外匯報的圖可以適當美化但前提是邏輯已經清晰。美化是錦上添花不是雪中送炭。5.2 坑二連線交叉太多讀者迷路連線交叉是畫圖里最影響可讀性的問題之一。我早期的圖經常像蜘蛛網線到處飛讀者要順著線找半天才能找到目標。減少交叉的方法有幾個。一是調整元素順序把有調用關系的元素放在相鄰位置。二是用跳線符號表示線交叉但不連接。三是把復雜關系拆成多張圖不要硬塞在一張里。還有一個技巧是分層把不同層級的東西畫在不同水平線上上層調用下層這樣連線大多是垂直的交叉自然就少了。5.3 坑三圖更新不及時變成歷史文物這是最隱蔽也最致命的坑。系統(tǒng)一直在演進但圖沒人更新半年后圖上的服務已經下線了新加的服務沒畫上去。這時候圖不僅沒用還會誤導人。我的應對方法是把圖納入變更流程。每次系統(tǒng)有架構級改動必須同步更新對應的圖跟代碼一起提交。這樣圖就跟著系統(tǒng)一起演進不會過期。另外我會在圖里標注最后更新時間和對應版本。讀者看到時間比較久就知道要謹慎參考主動去確認最新情況。5.4 坑四一個人悶頭畫不跟讀者確認我曾經花了一整天畫了一張自認為很完美的架構圖拿去匯報時被領導問這個模塊跟那個模塊是什么關系我才發(fā)現(xiàn)我默認大家都知道的關系領導并不知道。后來我養(yǎng)成了一個習慣畫圖前先跟主要讀者確認你希望這張圖回答什么問題。有時候讀者要的跟我以為的完全不一樣。提前對齊比畫完再返工劃算得多。6. 讓圖自解釋的幾個細節(jié)技巧6.1 用命名傳遞信息元素命名不要用服務A模塊B這種無意義代號直接用能表達職責的名字比如訂單創(chuàng)建服務庫存扣減服務。讀者看到名字就知道它是干什么的不用額外解釋。如果名字太長可以用縮寫但要在圖例里說明。比如OMS代表訂單管理服務第一次出現(xiàn)時標注全稱。6.2 用方向表達語義箭頭方向要統(tǒng)一語義。我習慣用箭頭指向被調用方表示調用關系箭頭指向數據流向方表示數據流。同一張圖里不要混用兩種語義否則讀者會混淆。如果一張圖里既有調用又有數據流我會用不同線型區(qū)分實線表示調用虛線表示數據流。并在圖例里寫清楚。6.3 用分組表達邊界系統(tǒng)邊界、團隊邊界、部署邊界都可以用分組框表達。分組框能幫讀者快速理解哪些東西是一伙的。分組不要嵌套太深兩層就夠了。三層以上的嵌套會讓圖變得難以閱讀這時候應該考慮拆圖。6.4 用留白引導視線留白不是浪費空間而是引導讀者視線的工具。核心元素周圍留出足夠空白讀者自然會先看那里。如果所有元素都擠在一起讀者會感到壓迫不知道從哪看起。我畫圖時會在核心模塊周圍留出至少一個元素寬度的空白邊緣的次要元素可以緊湊一些。這種疏密對比能有效突出重點。7. 從畫圖到設計圖的思維轉變7.1 圖是設計工具不是記錄工具很多人把畫圖當成記錄已經想好的東西但我的體會是畫圖本身就是設計過程。當你試圖把邏輯畫出來時很多之前沒想清楚的問題會暴露出來——這個分支怎么處理這個循環(huán)會不會死鎖這個依賴是不是多余所以我現(xiàn)在畫圖往往在系統(tǒng)還沒完全定型時就開始畫。畫的過程就是推演的過程畫完圖設計也清晰了。圖不是設計的產物而是設計的一部分。7.2 圖是溝通契約不是個人表達一張被團隊接受的圖實際上是一份溝通契約——大家約定用這張圖作為討論的基礎。這意味著圖不能太個人化要符合團隊的共同理解。比如團隊習慣用某種顏色表示某種含義你就不要為了好看改成別的顏色。團隊習慣某種布局方式你就盡量沿用。圖的個性應該體現(xiàn)在邏輯的清晰度上而不是視覺的標新立異上。7.3 圖是活的資產需要持續(xù)投入最后一點體會圖不是畫完就完事的它需要持續(xù)維護。一個團隊如果能把核心圖維護好新人的上手成本會大幅降低跨團隊溝通的效率也會提升。所以我會建議團隊指定圖負責人專門負責核心圖的更新和審查。這個投入看起來是額外的但長期看回報很高。一張維護良好的架構圖能省下無數次口頭解釋和會議討論。8. 我個人的幾個實操習慣最后分享幾個我一直在用的小習慣都是踩坑之后總結出來的。第一個習慣畫圖前先在紙上畫草圖。紙上的自由度最高改起來最快適合快速試錯。確定結構后再用工具正式畫效率比直接在工具里改高很多。第二個習慣給圖起一個描述性的文件名。比如訂單服務-正常下單時序-2024版而不是圖1新建文件。文件名本身就是一種文檔方便日后查找。第三個習慣重要圖導出兩種格式一種矢量圖用于放大查看一種位圖用于快速預覽。矢量圖在縮放時不會模糊適合正式場合位圖加載快適合日常溝通。第四個習慣定期回顧舊圖。每隔一段時間翻翻之前畫的圖看看哪些已經過期、哪些還能用。這個過程也能幫你發(fā)現(xiàn)自己設計思路的演進挺有意思的。畫圖這件事說到底是一種把復雜變簡單的能力。工具會變、樣式會變但讓讀者快速正確理解這個目標不會變。把精力花在邏輯梳理和讀者視角上比花在工具技巧上回報高得多。