1. 從“diagram-design”這個標題里我讀出了什么第一次看到“diagram-design”這個標題時我腦子里蹦出來的不是某個具體工具而是一類非常典型的工作場景手里有一堆零散的信息——流程節(jié)點、系統(tǒng)模塊、數(shù)據(jù)流向、組織關(guān)系——需要把它們變成一張別人一眼能看懂的圖。這件事聽起來簡單做起來卻處處是坑。我見過太多人把圖畫成了“只有自己能看懂的蜘蛛網(wǎng)”也見過不少團隊因為一張架構(gòu)圖的理解偏差在評審會上吵了半個小時?！癲iagram-design”這個標題本身沒有附帶正文、關(guān)鍵詞和摘要信息量極少。但恰恰是這種極簡的標題反而給了我們最大的解讀空間。從字面拆解“diagram”指向的是圖表、示意圖、流程圖、架構(gòu)圖這類可視化產(chǎn)物“design”則強調(diào)這不是隨手涂鴉而是有意圖、有規(guī)范、有取舍的設計行為。兩者合在一起核心命題就清晰了如何把復雜信息轉(zhuǎn)化為結(jié)構(gòu)清晰、語義準確、視覺舒適的專業(yè)圖表。這篇文章適合誰看如果你是剛?cè)胄械拈_發(fā)者需要畫系統(tǒng)架構(gòu)圖和技術(shù)流程圖如果你是產(chǎn)品經(jīng)理要輸出業(yè)務流程圖和狀態(tài)機圖如果你是技術(shù)寫作者想在文檔里嵌入清晰的示意圖——那這篇內(nèi)容就是為你準備的。我不會只講某個工具的按鈕在哪里而是把“為什么這樣畫”“什么情況下該換一種畫法”“哪些細節(jié)最容易被忽略”這些真正決定圖表質(zhì)量的東西講透。在展開之前先明確一個基本認知圖表設計本質(zhì)上是一種信息壓縮與再表達。你腦子里的系統(tǒng)可能有幾十個模塊、上百條調(diào)用關(guān)系但一張圖能承載的信息量是有限的。設計的核心不是“把所有東西都畫上去”而是“決定什么該畫、什么該省略、用什么視覺語言來表達”。這個判斷力才是區(qū)分新手和老手的關(guān)鍵。2. 圖表設計之前先想清楚這三件事2.1 圖表的讀者是誰決定了圖的抽象層級我踩過最大的一個坑就是拿著一張大而全的系統(tǒng)架構(gòu)圖去給不同的人講。給運維講的時候他們關(guān)心的是部署單元和網(wǎng)絡分區(qū)給開發(fā)講的時候他們關(guān)心的是模塊依賴和接口邊界給管理層講的時候他們只想知道數(shù)據(jù)從哪來到哪去、有幾個關(guān)鍵節(jié)點。同一套系統(tǒng)三種讀者需要的其實是三張不同的圖。所以在動手畫之前第一個要問自己的問題不是“用什么工具”而是“這張圖給誰看”。讀者決定了抽象層級。給高層看的圖一個方框可能代表整個服務集群給一線開發(fā)看的圖同一個方框可能要拆成五六個子模塊。這不是偷懶而是信息密度的合理匹配。把細節(jié)塞給不需要細節(jié)的人只會造成認知過載把過于抽象的東西給需要落地的人又會導致理解偏差。我的經(jīng)驗做法是先確定讀者的技術(shù)背景和關(guān)注點再決定圖中出現(xiàn)的最小粒度單元。如果讀者是跨部門協(xié)作方圖里最好只出現(xiàn)他們能理解的業(yè)務概念技術(shù)實現(xiàn)細節(jié)一律下沉到另一張圖里。這個原則說起來簡單但實際工作中我見過太多人為了“省事”只維護一張圖結(jié)果誰看都覺得別扭。2.2 圖表要回答的核心問題是什么每一張圖都應該有一個明確的“使命”。它可能是回答“這個請求從進入到返回經(jīng)過了哪些環(huán)節(jié)”也可能是回答“這幾個服務之間的依賴關(guān)系是什么”還可能是回答“這個狀態(tài)機有哪些狀態(tài)、怎么流轉(zhuǎn)”。如果一張圖試圖同時回答三個問題那它大概率一個都回答不好。我習慣在畫圖之前用一句話寫下這張圖的“中心命題”。比如“這張圖要說明訂單從創(chuàng)建到完成經(jīng)過的五個狀態(tài)以及觸發(fā)流轉(zhuǎn)的事件。”有了這句話后面所有的取舍都有了依據(jù)——與狀態(tài)流轉(zhuǎn)無關(guān)的字段、與事件無關(guān)的定時任務統(tǒng)統(tǒng)不畫。這句話也是后續(xù)評審時的“錨點”如果有人提出“這里是不是該加個東西”你可以回到中心命題來判斷而不是被牽著鼻子走。這個習慣幫我省下了大量返工時間。以前我經(jīng)常畫到一半發(fā)現(xiàn)“好像還缺個東西”然后不斷往里塞最后圖變得臃腫不堪。現(xiàn)在有了中心命題畫之前就知道邊界在哪里效率高了很多。2.3 選擇什么類型的圖比選擇什么工具更重要很多人一上來就糾結(jié)用哪個工具——是畫流程圖、時序圖還是架構(gòu)圖其實工具是最后一步先確定圖的類型才是關(guān)鍵。不同類型的圖有各自的語義規(guī)范用錯了類型讀者會產(chǎn)生誤解。舉個常見的例子有人想表達“服務A調(diào)用服務B然后B調(diào)用C”結(jié)果畫了一個流程圖用方框表示服務、箭頭表示調(diào)用。這看起來沒問題但流程圖的本意是表達“步驟的順序”而這里想表達的是“組件之間的依賴關(guān)系”。如果讀者按流程圖的語義去理解會以為A、B、C是三個步驟而不是三個可以獨立部署的服務。這種情況下用組件圖或依賴關(guān)系圖會更準確。下面這張表是我總結(jié)的常見圖表類型與適用場景的對照可以作為選型參考圖表類型核心語義典型場景常見誤用流程圖步驟順序與分支條件業(yè)務流程、審批流用來表達組件依賴時序圖對象間的消息交互順序接口調(diào)用鏈、協(xié)議交互用來表達靜態(tài)結(jié)構(gòu)狀態(tài)機圖狀態(tài)與觸發(fā)事件訂單狀態(tài)、連接狀態(tài)用來表達數(shù)據(jù)流組件圖模塊/服務的依賴關(guān)系系統(tǒng)架構(gòu)、微服務拓撲用來表達調(diào)用時序數(shù)據(jù)流圖數(shù)據(jù)在系統(tǒng)中的流轉(zhuǎn)數(shù)據(jù)處理管道用來表達控制流選對了類型圖就已經(jīng)成功了一半。剩下的才是布局、配色、標注這些視覺層面的工作。3. 布局與視覺編碼讓圖自己會說話3.1 布局的底層邏輯減少線條交叉順應閱讀方向一張圖好不好看第一眼取決于布局。而布局的核心目標只有一個讓讀者的視線沿著信息流自然移動不需要來回跳躍。我見過很多圖內(nèi)容都對但線條交叉得像一團亂麻讀者看兩眼就放棄了。減少線條交叉的最有效方法是分層布局。把圖中的元素按照某種維度分成若干層每層水平或垂直排列層與層之間的連線盡量走直線。比如畫一個請求處理流程可以按“接入層—邏輯層—存儲層”分三層每層內(nèi)部的元素橫向排列跨層的調(diào)用用垂直箭頭連接。這樣線條基本不會交叉讀者也能快速理解層級關(guān)系。另一個實用技巧是順應閱讀方向。中文讀者的閱讀習慣是從左到右、從上到下所以主流程最好也按這個方向排列。如果流程有回退或循環(huán)盡量把回退線畫在圖的邊緣不要穿過主體區(qū)域。我見過有人把重試邏輯的箭頭直接橫穿整個圖結(jié)果讀者第一眼看到的是那條橫線而不是主流程。提示布局完成后把圖縮小到50%看一眼。如果縮小后還能看出大致的結(jié)構(gòu)和流向說明布局是成功的如果縮小后變成一團模糊的色塊說明元素太密或線條太亂需要重新調(diào)整。3.2 視覺編碼顏色、形狀、線型各自承擔什么語義圖表設計里有一個容易被忽視的原則每一種視覺元素都應該有明確的語義不能為了好看而隨意使用。顏色、形狀、線型、粗細這些都是“視覺編碼”用好了能讓圖的信息密度翻倍用亂了反而增加理解成本。先說顏色。我的習慣是主流程用中性色灰、藍灰強調(diào)或異常路徑用高飽和色橙、紅。比如一張架構(gòu)圖里正常的數(shù)據(jù)流用深灰色箭頭異步消息用虛線加淺藍色錯誤重試路徑用橙色。這樣讀者一眼就能區(qū)分主次。最忌諱的是每個模塊用不同顏色看起來花花綠綠實際上顏色沒有傳遞任何額外信息反而分散了注意力。形狀也有約定俗成的語義。矩形通常表示處理單元或模塊圓角矩形表示服務或組件菱形表示判斷圓柱體表示存儲平行四邊形表示數(shù)據(jù)輸入輸出。這些約定不是強制的但遵循它們能降低讀者的學習成本。如果你非要用圓形表示數(shù)據(jù)庫讀者就得額外花時間去記你的“自定義圖例”得不償失。線型方面實線通常表示同步調(diào)用或主流程虛線表示異步消息或可選路徑點線表示依賴或引用關(guān)系。箭頭的方向也要統(tǒng)一要么全部從左到右要么全部從上到下不要混用。我見過一張圖里有的箭頭從左到右、有的從右到左讀者得反復確認方向體驗很差。3.3 標注與圖例別讓讀者去猜標注是圖表設計中最容易被偷懶的部分。很多人覺得“圖都畫出來了意思不是很明顯嗎”但讀者的背景知識和你不一樣你覺得顯而易見的關(guān)聯(lián)他們可能完全看不出來。我的做法是任何有歧義的地方都必須標注任何非標準的視覺元素都必須有圖例。比如兩個模塊之間有一條虛線箭頭如果不在圖例里說明“虛線表示異步消息”讀者可能會理解為“可選依賴”或“弱關(guān)聯(lián)”。再比如某個模塊用了特殊的顏色如果不在圖例里說明“橙色表示已廢棄”讀者可能會以為是強調(diào)。標注的文字要簡短但信息要完整。我見過有人在箭頭上寫“調(diào)用”這等于沒寫——誰調(diào)用誰調(diào)用的什么接口更好的寫法是“HTTP POST /order”這樣讀者不用去翻文檔就能理解這條線的含義。當然標注也不能太長否則會擠占圖形空間。我的經(jīng)驗是標注控制在15個字以內(nèi)超出部分放到圖下方的說明文字里。還有一個細節(jié)圖例的位置要固定。我習慣把圖例放在圖的右下角或左下角不要每張圖換一個位置。這樣讀者形成習慣后找圖例的速度會快很多。4. 工具選型不同場景下的最優(yōu)解4.1 代碼化繪圖工具適合需要版本管理的場景如果你的圖表需要頻繁修改、需要和代碼一起做版本管理、需要多人協(xié)作評審那代碼化繪圖工具是首選。這類工具的核心優(yōu)勢是圖表的定義是純文本可以像代碼一樣 diff、merge、review。我常用的方案是用文本描述語言來定義圖表然后渲染成圖片。這樣做的好處是每次修改都能在版本控制里看到具體改了哪一行評審的時候一目了然。相比之下用圖形界面工具畫的圖每次修改都是二進制文件的變更根本看不出改了什么。代碼化繪圖的另一個優(yōu)勢是一致性。你可以定義一套樣式模板所有圖都套用同一套配色、字體、間距出來的圖風格統(tǒng)一放在文檔里很協(xié)調(diào)。圖形界面工具雖然也能復制樣式但很容易在拖拽過程中產(chǎn)生細微偏差。不過這類工具也有明顯的短板學習曲線陡峭布局調(diào)整不直觀。你沒法用鼠標拖拽一個元素到想要的位置只能通過調(diào)整代碼里的順序和參數(shù)來間接控制布局。對于簡單的圖這反而比拖拽更慢。所以我的建議是結(jié)構(gòu)復雜、需要長期維護的圖用代碼化工具一次性、結(jié)構(gòu)簡單的圖用圖形界面工具。4.2 圖形界面工具快速出圖與精細調(diào)整的平衡圖形界面工具的最大優(yōu)勢是所見即所得。你可以直接拖拽元素、調(diào)整大小、對齊分布對于需要精細控制布局的圖這種直觀性是代碼化工具無法替代的。我通常用圖形界面工具來處理兩類需求一是演示用的示意圖需要快速出圖對版本管理要求不高二是布局要求極高的圖比如需要嚴格對齊的矩陣式架構(gòu)圖用代碼調(diào)整對齊參數(shù)反而更麻煩。選擇圖形界面工具時我會關(guān)注幾個點是否支持對齊輔助線、是否支持樣式復用、是否支持導出多種格式。對齊輔助線能大幅減少手動調(diào)整的時間樣式復用能保證同一文檔里的多張圖風格一致導出格式則決定了圖能不能方便地嵌入到不同平臺。注意圖形界面工具畫的圖一定要定期導出為圖片或PDF存檔。我吃過虧——有一次工具升級后文件格式不兼容之前畫的圖打不開了只能憑記憶重畫。從那以后我養(yǎng)成了“畫完就導出”的習慣。4.3 什么時候該放棄工具直接手繪這聽起來有點反直覺但確實有些場景下手繪比任何工具都高效。比如在白板討論或快速原型階段你需要的是快速表達想法、即時修改而不是產(chǎn)出最終交付物。這時候拿筆直接畫比打開工具、拖拽元素、調(diào)整樣式快得多。手繪的另一個優(yōu)勢是降低心理門檻。用工具畫圖時人會不自覺地追求“畫得好看”反而在布局上糾結(jié)太久。手繪的時候大家都知道這是草圖關(guān)注點自然回到內(nèi)容本身。我經(jīng)常在需求討論會上直接用白板畫草圖把關(guān)鍵節(jié)點和關(guān)系理清楚會后再用工具出正式圖。這樣效率最高。手繪還有一個隱藏好處方便標注和批注。討論過程中任何人都可以直接在圖上圈畫、寫字這些批注本身就是重要的討論記錄。用工具畫圖的話批注和修改反而成了額外的操作負擔。5. 那些年我踩過的圖表設計坑5.1 信息過載什么都想畫結(jié)果什么都看不清這是我早期最常犯的錯誤。畫一張系統(tǒng)架構(gòu)圖恨不得把每個服務的每個接口都標上去結(jié)果圖大得像海報打印出來字小得看不清。更糟糕的是因為信息太多讀者反而抓不住重點看完之后腦子里一團漿糊。后來我學乖了給自己定了一條硬規(guī)矩一張圖只講一件事。如果系統(tǒng)架構(gòu)需要講三件事那就畫三張圖每張圖聚焦一個維度。比如第一張圖講部署拓撲第二張圖講服務依賴第三張圖講數(shù)據(jù)流向。三張圖放在一起讀者可以按需查看比一張大雜燴清晰得多。這條規(guī)矩還有一個附帶好處每張圖的維護成本降低了。系統(tǒng)變更時只需要更新受影響的那張圖不用動輒修改一張巨型圖。長期來看這反而更省時間。5.2 語義模糊箭頭到底代表什么箭頭是圖表里最常用的元素也是最容易產(chǎn)生歧義的。我見過一張圖里箭頭同時表示“調(diào)用”“依賴”“數(shù)據(jù)流向”“控制流”四種含義讀者根本分不清哪條線是什么意思。解決這個問題的辦法很簡單在圖的開始處明確聲明箭頭的語義并且全圖統(tǒng)一。如果一張圖里確實需要表達多種關(guān)系那就用不同的線型或顏色來區(qū)分并在圖例里說明。比如實線箭頭表示同步調(diào)用虛線箭頭表示異步消息帶空心三角的箭頭表示依賴。這樣讀者一看圖例就明白了。還有一個細節(jié)箭頭的方向要明確。如果A調(diào)用B箭頭應該從A指向B而不是反過來。我見過有人把箭頭畫成雙向的說是“表示互相調(diào)用”但讀者會誤以為A和B之間存在循環(huán)依賴。如果確實是雙向調(diào)用最好畫兩條單向箭頭分別標注調(diào)用的接口這樣更清晰。5.3 布局陷阱為什么你的圖總是“差一點”布局是圖表設計里最考驗耐心的地方。我經(jīng)常遇到的情況是內(nèi)容都畫完了但整體看起來就是“差一點”要么是某個模塊位置尷尬要么是線條繞得太遠。這種時候很多人會選擇“就這樣吧”但正是這些細節(jié)決定了圖表的專業(yè)度。我的經(jīng)驗是布局問題往往不是調(diào)整元素位置能解決的而是需要重新思考分組和層級。比如一個模塊位置尷尬可能是因為它和周圍的模塊不屬于同一層級應該單獨提出來放在另一個區(qū)域。再比如線條繞得太遠可能是因為兩個應該相鄰的模塊被其他元素隔開了需要調(diào)整整體排列順序。遇到布局問題時我會先把所有元素的位置關(guān)系在紙上畫一遍找到最自然的排列方式再回到工具里調(diào)整。這個“紙上談兵”的步驟看起來多余但實際上能省下大量在工具里反復拖拽的時間。5.4 配色翻車那些辣眼睛的配色方案配色是圖表設計里最主觀、也最容易翻車的部分。我見過太多“辣眼睛”的配色熒光綠配亮紫、深紅配深藍、五顏六色堆在一起……這些配色不僅難看更重要的是影響了信息的傳達。我的配色原則很簡單主色不超過三種背景用中性色強調(diào)色只用在關(guān)鍵元素上。具體來說主流程用深灰色或深藍色次要元素用淺灰色異?；蛑攸c用橙色或紅色。這樣整張圖看起來干凈讀者的注意力也能集中在真正重要的地方。還有一個實用技巧用同一色系的不同深淺來表示層級。比如頂層模塊用深藍第二層用中藍第三層用淺藍。這樣讀者不用看圖例就能感知到層級關(guān)系信息傳達效率更高。提示如果你對配色沒有把握可以找一套成熟的配色方案直接套用。很多設計系統(tǒng)都公開了他們的配色規(guī)范這些方案經(jīng)過大量驗證比你自己調(diào)出來的顏色更靠譜。6. 從草圖到交付一個完整的圖表設計流程6.1 需求澄清先搞清楚“為什么需要這張圖”接到畫圖需求時我做的第一件事不是打開工具而是和需求方聊十分鐘。聊的內(nèi)容包括這張圖給誰看、要回答什么問題、用在什么場景文檔、演示、評審、有沒有格式或尺寸要求。這十分鐘的投入能省下后面幾個小時的返工。我遇到過好幾次這樣的情況需求方說“畫個架構(gòu)圖”聊完之后發(fā)現(xiàn)他們其實想要的是“數(shù)據(jù)流向圖”因為他們的關(guān)注點是數(shù)據(jù)在系統(tǒng)里怎么流轉(zhuǎn)而不是模塊怎么部署。如果直接開畫畫出來的架構(gòu)圖再漂亮也滿足不了需求。所以我的建議是在動手之前用一句話寫下這張圖的目標然后和需求方確認。這句話就是后續(xù)所有決策的依據(jù)。如果需求方說“對就是這個意思”那就可以放心開畫如果對方猶豫了說明需求還沒澄清繼續(xù)聊。6.2 草圖迭代用最粗糙的方式快速驗證結(jié)構(gòu)確認需求后我不會直接打開工具畫正式圖而是先用紙筆或白板畫草圖。草圖不需要好看只需要把關(guān)鍵元素和關(guān)系畫出來驗證結(jié)構(gòu)是否合理。這個階段的目標是快速試錯。我可能會畫三四個版本每個版本嘗試不同的布局和分組方式然后對比哪個版本最清晰。草圖階段修改成本極低畫錯了擦掉重來就行。如果直接上工具畫改起來就麻煩多了。草圖還有一個好處方便和他人討論。拿著草圖去問同事“你覺得這個流程清楚嗎”對方能直接在圖圈畫、提意見。如果拿的是正式圖對方可能會因為“圖已經(jīng)畫好了”而不好意思提大改的意見。6.3 正式繪制把草圖翻譯成規(guī)范圖表草圖確認后才進入正式繪制階段。這個階段的核心工作是把草圖的結(jié)構(gòu)翻譯成規(guī)范的圖表語言選擇合適的圖表類型、應用統(tǒng)一的視覺編碼、添加必要的標注和圖例。正式繪制時我會特別注意幾個細節(jié)對齊、間距、字體大小。對齊是最基本的專業(yè)度體現(xiàn)元素沒有對齊會顯得很隨意。間距要均勻相關(guān)元素靠近、不相關(guān)元素拉開這樣讀者能通過空間距離感知到分組關(guān)系。字體大小要統(tǒng)一標題、標注、正文用不同字號區(qū)分層級但同一層級的字號必須一致。繪制完成后我會把圖導出為圖片然后在不同設備上查看效果。在電腦上看沒問題不代表在手機上也清晰。如果圖需要嵌入文檔還要確認導出格式和分辨率是否滿足要求。6.4 評審與修改如何收集有效反饋圖繪制完成后我會找兩三個人評審。評審時我不會問“你覺得怎么樣”而是問具體的問題“你能看出主流程是什么嗎”“這個箭頭你覺得是什么意思”“有沒有哪里讓你困惑”。這樣能收集到具體的、可操作的反饋而不是“挺好的”這種無效評價。收集到反饋后我會判斷哪些是真正的問題、哪些是個人偏好。如果是多人同時指出同一個地方有問題那大概率是真問題必須改。如果只有一個人提出且理由不充分可以先記錄等后續(xù)驗證。修改完成后最好再讓提意見的人確認一下確保問題確實解決了。7. 讓圖表經(jīng)得起時間考驗的維護策略7.1 圖表即代碼把圖納入版本管理如果你的圖表需要長期維護我強烈建議把圖納入版本管理。具體做法是用代碼化工具定義圖表把源文件放在代碼倉庫里和代碼一起提交、一起評審。這樣每次修改都有記錄誰改的、改了什么、為什么改一目了然。這樣做還有一個好處圖表和代碼可以同步更新。比如某個服務的接口變了代碼提交時順便更新對應的時序圖評審時一起看。避免出現(xiàn)“代碼已經(jīng)改了三個月圖還是老的”這種情況。對于必須用圖形界面工具畫的圖至少要把導出的圖片和源文件一起存檔并在文件名里標注版本號和日期。我見過太多人用“架構(gòu)圖_final_v2_真的最終版”這種命名方式過兩個月自己都分不清哪個是最新的。7.2 定期審查什么時候該更新圖表圖表不是畫完就一勞永逸的。系統(tǒng)在演進圖表如果不更新就會從“資產(chǎn)”變成“負債”——讀者看了過時的圖反而會產(chǎn)生錯誤的理解。我的做法是把圖表更新納入常規(guī)的迭代流程。每次系統(tǒng)有重大變更時同步檢查相關(guān)圖表是否需要更新。如果變更不大可以攢著一起改如果變更影響到了圖的核心結(jié)構(gòu)那就立即更新。另外我會每隔一段時間比如一個季度把核心圖表拿出來過一遍看看有沒有過時的地方。這個審查不需要很正式就是自己看一遍發(fā)現(xiàn)明顯不對的地方就改掉。7.3 廢棄圖表的處理別讓舊圖誤導人當一張圖徹底過時、不再維護時一定要明確標記為“已廢棄”而不是留在那里不管。我見過太多文檔里同時存在新舊兩張圖讀者不知道哪張是當前的反而造成了混亂。我的做法是在廢棄的圖上加一個明顯的“已廢棄”水印或標注并注明替代它的新圖在哪里。如果可能的話直接從文檔里刪除舊圖只保留最新的。如果舊圖有歷史參考價值就把它移到單獨的“歷史存檔”區(qū)域和當前文檔分開。這個習慣看起來是小事但實際上能避免很多溝通成本。讀者看到“已廢棄”的標記就不會再參考那張圖也不會來問你“這張圖是不是最新的”。8. 一些零散但實用的經(jīng)驗畫了這么多年的圖有一些零散的經(jīng)驗不成體系但每次都能派上用場。關(guān)于字體圖表里的字體不要超過兩種一種用于標題一種用于正文。中文字體推薦用黑體或思源黑體筆畫清晰縮小后也能看清。避免用宋體筆畫太細縮小后容易糊。關(guān)于留白圖里的留白不是浪費空間而是給讀者呼吸的余地。元素之間留出足夠的間距圖看起來會更舒服。我見過有人把元素排得密密麻麻恨不得一點空隙都不留結(jié)果讀者看兩眼就累了。關(guān)于導出格式如果圖要嵌入文檔優(yōu)先導出為矢量格式如SVG或PDF這樣放大不會模糊。如果必須用位圖分辨率至少設為300dpi否則打印出來會很糊。關(guān)于命名圖表的文件名要能說明內(nèi)容不要用“圖1”“圖2”這種無意義的命名。我習慣用“系統(tǒng)架構(gòu)_部署拓撲_20240115”這樣的格式包含內(nèi)容、類型和日期方便檢索和版本管理。關(guān)于協(xié)作如果多人協(xié)作畫圖一定要先統(tǒng)一視覺規(guī)范——配色、字體、線型、標注風格。否則每個人按自己的習慣畫拼在一起會很不協(xié)調(diào)。我通常會在項目開始時建一個“樣式模板”所有人基于模板畫圖保證風格一致。最后分享一個我個人的小習慣每次畫完一張圖我會把它打印出來貼在工位上過兩天再看一眼。隔一段時間再看往往能發(fā)現(xiàn)當時沒注意到的問題——可能是某個標注不夠清楚可能是某個布局不夠合理。這個“冷卻期”審查法幫我改進了不少圖。圖表設計這件事說到底是一種溝通能力。工具和技巧都是輔助核心是你能不能站在讀者的角度把復雜的信息用最清晰的方式表達出來。這個能力需要反復練習每畫一張圖都是一次提升的機會。