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