1. 从画个图交差到图能说话我为什么开始较真 diagram-design说实话我刚工作的前几年画图这件事在我心里一直是辅助产出——需求讨论时在白板上随手画两笔方案评审时用绘图软件堆几个方框和箭头能让人看懂就算完成任务。直到有一次我拿着精心画了大半天的架构图去做汇报被问得哑口无言图上的服务之间为什么要走这条链路这个模块的边界到底在哪里为什么这张图把存储画在了最显眼的位置而不是链路的核心节点上那一次之后我才意识到画图这件事根本不是什么顺手的事。一张图设计得好能在一页之内把系统结构、依赖关系、关键路径、风险点讲清楚设计得不好就是一堆方框的堆砌看的人越看越糊涂。后来我把 diagram-design 当成一个正经方向来琢磨——不是指某个具体的项目而是指如何系统性地设计和输出高质量图表这件事本身。我梳理了一套从需求判断、图型选择、排版规范到版本管理的完整工作流这篇文章就是把这套经验完整梳理出来。无论你是刚入门的技术新人还是要经常做方案汇报的开发者或者负责团队文档规范的人这篇内容都值得你花十几分钟读一遍。我会尽量讲清楚每一类图应该怎么设计、为什么这样设计以及那些我在实操中反复踩过的坑。图这个东西一旦你会设计了它就不再是文档的配图而是方案的论证工具。2. 动手之前先回答四个问题图的定位与受众很多人画图失败不是因为工具用得不熟而是因为没想清楚这张图到底是干嘛的。我的习惯是在新建画布之前先在脑子里过四个问题这四个问题决定了整张图的信息取舍、抽象层级和表达方式。2.1 这张图要推动什么决策图本身不是目的它要服务于一个具体的决策场景。比如方案评审会上你要让大家确认的是新引入的消息队列放在这个位置是否合理故障复盘时你要让大家看清楚的是调用链在哪一环超时了。这两种场景下图的重点完全不同。我见过很多人在画系统架构图时恨不得把每个组件都画上去结果评审时大家盯着的其实是中间那一条主链路。这就是典型的没想清楚决策点。我自己现在的做法是在画布左上角先写一行注释标注本图服务于XX决策画完检查时看着这行字删掉与决策无关的内容。这个方法听起来简单但真的能逼着你做减法。2.2 读者是谁处于什么上下文同一套系统给研发同事看的图和给业务方看的图抽象层级可以差出好几层。给研发看的图可以把服务名、端口、数据表都标出来给业务方看的图只需要呈现用户下单之后发生了什么的角色和顺序。这里的判断标准是读者的上下文。如果读者刚刚参与过这个项目的讨论你可以画得很细如果是第一次接触这个系统的外部评审专家你需要从一张全景图开始然后再用子图展开细节。我踩过的坑是拿着给内部研发看的详细架构图去给跨部门的人讲五分钟之后所有人都开始走神。不是图错了是对象错了。2.3 信息密度应该多高信息密度过高是新手画图最常见的毛病。一个方框里塞下服务名、部署方式、技术栈、负责人、监控指标结果字号越缩越小线条越拉越密。等你把图缩放到能全览的时候上面的字根本看不清放大看清楚了又丢了全局。我的经验是一张图的信息密度以A4纸打印出来之后不缩放能看清楚为标准。超过这个密度就要考虑拆图——要么按模块拆成多张子图要么把细节挪到附录或表格里。记住一个原则图的主干信息控制在7±2个节点左右人脑一次能同时处理的信息量是有上限的你非要塞进去30个节点那就不是设计是堆砌。2.4 是示意、是准确记录还是可执行蓝图最后要搞清楚这张图的性质。示意性质的图可以牺牲部分准确性换取易读性比如流程讨论时的草图准确记录性质的图要求每个连线、每个标注都对得上实际系统比如运维架构图可执行蓝图则是连未来要落地的模块也算进去的规划图。这三者的混淆会带来很大问题。把示意图当成准确记录去指导排障你会被误导把蓝图当成现状图去评审你会发现一堆怎么和线上不一样的质疑。我建议在图的标题或图例里直接标注图的类型比如示意图现状图目标架构图让读者第一时间知道该怎么读这张图。3. 五类高频图的适用场景与设计要点不同的问题需要不同的图型来表达。我见过有人用架构图去画业务流程也有人用时序图画系统静态结构不是说完全不行而是没有用对最顺手的表达方式。这里把我工作中最高频的五类图型梳理一下每一类都说说它的适用场景、设计要点和我实操时总结的规则。3.1 架构图重点是分层和边界架构图表达的是系统有哪些部分、它们如何组织在一起常见的有分层架构图、微服务架构图、部署架构图。设计架构图的核心不是把节点画出来而是表达清楚层次和边界。我的习惯是先确定横向的分层如接入层、应用层、数据层或纵向的边界如按业务域、按团队然后再往每一层里填充节点。连线的时候尽量保持连线走正交方向横平竖直避免斜线穿过多个层否则视觉上会非常混乱。还有一个细节架构图里的节点应该用统一的形状——同一层用同一形状不同层之间用形状区分比如服务用圆角矩形、数据存储用圆柱形这比花花绿绿的颜色更本质。3.2 时序图强调顺序和交互时序图表达的是在某个业务流程中参与者之间按时间顺序发生了什么。设计时序图最忌的是把每条消息都画成一样粗、一样黑——重要的消息和普通的调用应该有视觉权重上的区分。我通常的做法是把主要业务链路画成实线把旁路操作如日志上报、异步通知画成虚线然后只给最关键的那一两条消息加颜色标注。另外时序图里的时间轴方向一定要一致从上到下不要在中间突然改变方向。画时序图前先列一遍交互步骤清单再落到图里能省下很多返工时间。3.3 流程图核心是分支和异常流程图大家都会画但很多人只画了快乐路径——正常情况下的流程异常分支一笔带过甚至直接省略。真正设计得好的流程图会把异常处理作为一等公民画出来。我在设计流程图时会专门用不同的形状区分处理步骤和判断分支并且为每一个判断节点写出明确的布尔条件是/否、成功/失败不是写成功两个字就完了而是要写清楚什么算成功。还有一个建议当流程图超过两屏时别硬画成一张长图应该拆成主流程加子流程用预定义符号或跳转节点来连接。3.4 ER图与数据模型图关键是关系和基数只要涉及数据设计ER图几乎不可避免。设计ER图的要点是实体、属性、关系三者的表达要一致关系的基数1:1、1:N、N:M必须明确标出。我见过很多ER图画得像散落的盒子实体之间的连线没有方向基数也没有标注看的人根本不知道一张订单能对应几个明细。我的建议是在设计ER图时先列一张关系清单把所有实体之间的对应关系写成文字订单与订单明细是1:N确认无误后再画图画完再对着清单检查一遍基数的标注。颜色可以按业务域分区但在表达关系语义的时候一定要靠的是线条和符号不是颜色。3.5 思维导图/概念图用于拆解而非汇报思维导图在个人梳理思路时很好用但直接拿到正式汇报场合往往会显得松散。我的看法是思维导图这类辐射状的图更适合从中心主题向外发散的思考场景比如需求拆解、方案选项对比。如果要把思维导图的内容用于正式文档我通常会把它改写成层级清晰的树状结构或列表再配合一张概念图来表达概念之间的关联。设计这类图时中心主题一定要明确一级分支控制在5个左右再往下层层展开。如果分支超过三层建议把某一支单独拎出来画详情图。4. 从草稿到成品一套可复用的绘图工作流很多人在画图工具里直接开工边画边想画到一半推翻重来。我的经验是画图应该像写代码一样先有设计再有实现。下面这套工作流我用了很多年产出效率和质量都稳定不少。4.1 先用文字把图的内容写出来在打开任何绘图工具之前我会先写一个文字版的图的脚本。比如画架构图我会列出图名订单中台现状架构图类型现状图读者中台建设评审组分层接入层网关、鉴权、应用层订单服务、库存服务、支付服务、数据层订单库、库存库、消息队列关键连线下单请求经网关到订单服务 - 订单服务调用库存服务 - 下单成功发消息需要突出的边界中台与前台系统的边界、与第三方支付的边界这个脚本就是整张图的骨架。写完之后自己先看一遍逻辑顺不顺、有没有遗漏的关键交互这时候改文字成本极低等画完了再改就是大工程。4.2 搭骨架确定版式和布局第二步是把文字脚本落到画布上。这时候先不着急美化只做一件事把节点摆到大致的位置上把连线按主干逻辑拉出来看整体的流向是否顺畅。布局的选择很重要。常见的布局有两种自上而下的层级流适合分层架构图和流程图和从左到右的水平流适合请求链路和时序类的内容。选择布局的原则是顺着人的阅读习惯让主要流向和图的方向一致。我自己的偏好是架构图用自顶向下分层链路图用从左到右。4.3 规范排版对齐、间距、统一的形状和配色骨架搭完就开始排版规范。这一步骤直接决定了图的质量下限。我给自己定了几条硬性规则节点统一左对齐或居中对齐不允许随缘摆放相邻节点间距保持一致推荐不低于节点宽度的四分之一同层节点的宽度尽量统一长文本用换行而不是拉伸矩形整张图使用的颜色不超过3种主色另有1种强调色线条走正交路径避免斜穿每条线尽量标注它的语义这些规则听起来琐碎但组合起来的效果非常明显。一张对齐良好、间隙均匀的图哪怕没有复杂的设计看起来也比随手画的图专业好几个档次。4.4 加标注和引导让读者知道先看哪里排版规范做好之后我还会做一件事在图上增加阅读引导。最简单的做法是把标题放在图的左上角把图例放在右下角然后在关键路径上用数字序号①下单 ②扣库存 ③发消息标出阅读顺序这样读者就不会在复杂的连线里迷路。如果图里存在分支或可选项我会用不同的线型表示主路径和备选路径。还有一个个人习惯在图的底部留一行说明写清这张图的版本和最近一次更新时间。这样图被转发了多少轮大家也知道它有没有过期。4.5 输出与归档PDF、图片、可编辑源文件图的输出格式取决于用途。给别人看用 PDF 或 PNG给别人继续改就要交付可编辑的源文件。我建议在每次交付成图的同时把这个图的源文件和导出的图片放在同一个目录里命名遵循日期-图名-版本的格式。这里有一个容易忽略的点很多绘图工具的导出清晰度是有限制的导出 PNG 时要注意分辨率确保放大之后文字依然清晰。为了保险起见我导出时通常选择高倍率或直接导出矢量格式如 PDF/SVG避免在文档里缩放后出现糊字。5. 图也是代码版本管理与多人协作的实践图一旦进入协作场景事情就会变得复杂。多人同时改一张图怎么保证没有冲突图改了之后怎么让看的人知道变的是什么这一章聊聊我把图当作代码来管理的实践。5.1 文本化图表让图可以 diff传统的二进制绘图文件白板类、画布类工具的默认格式很难做版本比较。后来我转向了文本化图表的方案——用描述性的文本语法来定义图的结构再通过工具渲染成图。这种方式最大的好处是图和代码一样可以被版本管理系统追踪每次修改都能看到明确的 diff。文本化图表的优点不止于此。它还能让图的编写进入复用的流程你可以把常用的节点和连线定义保存成模板片段画新图时直接引用你可以在自动化流程里批量生成图比如根据配置数据自动生成部署架构图你还可以直接在代码评审平台里看到图的变化哪些节点被加上了、哪些连线被删掉了一目了然。5.2 多人协作时的约定与流程即使有了文本化图表多人协作依然需要约定。我参与过的团队里我们定了几条最基础的规则一个人改动架构图时先认领避免两个人同时大改图必须和代码一起提交变更、一起评审不允许图单独漂移在代码仓库之外每次变更要在提交说明里写清图里改了哪些结构和为什么改定期每个版本结束检查一次图的准确性与实际系统的一致性这几条规则看起来简单但执行到位之后图的可靠性和文档一样高。很多团队的架构图之所以沦为墙纸根本原因是没人维护版本漂移之后大家发现图已经不可信了就彻底放弃。反过来把图纳入评审流程它才会真正成为团队的知识资产。6. 我踩过的坑画完没人看、一改就废的典型案例最后聊聊我在 diagram-design 这件事上踩过的坑。这些教训如果提前知道能帮你省下大把返工时间。6.1 坑一为了美观牺牲可读性结果没人看得懂我曾经在设计一张系统全景图时为了让图看起来高级用了深色渐变背景、发光的连接线、3D 效果的节点。当时觉得很炫后来给组里新人讲业务时发现对方完全无法从图中获得信息——视觉负担太重注意力全被样式吸引走了。这个坑的核心是图的第一身份是信息载体不是装饰品。从此我给自己立下规矩在正式图里样式必须服务于信息分层禁止为了好看而设计。深色背景可以用在演示现场的大屏上但用在文档里就是灾难。6.2 坑二只画现状图不画目标图方案总是推不动有一段时间我画的架构图全部是现状图每次想推进技术改造拿着现状图讲我们要改成什么样对面的人总是追问现在的流程到底是怎样的。直到我区分开现状图和目标图两套图之后沟通才顺畅起来。给业务方看两个版本的图并排展示一张是现在的流程和痛点标注一张是改造后的流程和收益标注决策的讨论立刻变得具体。这个经验同样适用于小型变更哪怕只是一个接口改造也值得画前-后两张对比图。6.3 坑三图更新不及时最后成了没人信的废图这是最痛的一个教训。某系统的架构图画好之后三个月内系统经历了两次重构图没有同步更新。等一个新同事拿着旧图排查问题时被误导了好几个小时最后发现图里的服务和线上的根本对不上。从此之后图是否过期成了我评审文档时必查的一个问题。现在的解决方案就是前面说的文本化图表加版本管理。图跟着代码走代码发生结构变化时图的修改提示会出现在评审里。哪怕偶尔忘记更新通过文件提交记录也能很快定位到图的过期时间点不需要靠记忆维护。6.4 坑四信息过载一张图试图表达所有维度还有一类图作者非常努力地把容量信息、延迟指标、负责人、告警规则、部署节点全部画进一张图里。结果图字特别小缩放到全页根本看不清每一处标注都像在喊我很重要。这种图的失败在于没有做信息的优先级管理。我现在画图时会做一个三层信息拆解第一层是主干结构放到主图里第二层是关键细节放到子图或图注里第三层是参考数据放到链接或文档里。读者默认按照这个层级去阅读既不会在主干上迷路又能在需要时找到细节。7. 最后分享几个平时画图的小习惯讲了这么多最后把我目前还在用的几个小习惯列出来。它们不复杂但真的能提高图的质量第一画图前先写一段图的目标描述就算只有两三句话也要写。这个动作能拦住大部分随手画的冲动。第二画完之后放一放至少隔一小时再回来看一眼。脱离创作状态后你自己最容易发现自己图的逻辑问题。第三把好的图存进个人素材库。遇到相似场景时先参考自己的历史方案再决定要不要结构调整。第四图的命名尽量描述性不要叫未命名图不要用final-最终版-真最终版这类命名日期加版本号就够了。关于 diagram-design 的经验我能沉淀出来的核心就一句话图的本质是被结构化的信息设计图的过程就是不断取舍信息层级的过程。你不需要成为视觉设计的专家但你需要像一个工程师一样思考——每个节点、每条连线、每层布局都应当经得起为什么放在这里的追问。
1. 从画个图交差到图能说话我为什么开始较真 diagram-design说实话我刚工作的前几年画图这件事在我心里一直是辅助产出——需求讨论时在白板上随手画两笔方案评审时用绘图软件堆几个方框和箭头能让人看懂就算完成任务。直到有一次我拿着精心画了大半天的架构图去做汇报被问得哑口无言图上的服务之间为什么要走这条链路这个模块的边界到底在哪里为什么这张图把存储画在了最显眼的位置而不是链路的核心节点上那一次之后我才意识到画图这件事根本不是什么顺手的事。一张图设计得好能在一页之内把系统结构、依赖关系、关键路径、风险点讲清楚设计得不好就是一堆方框的堆砌看的人越看越糊涂。后来我把 diagram-design 当成一个正经方向来琢磨——不是指某个具体的项目而是指如何系统性地设计和输出高质量图表这件事本身。我梳理了一套从需求判断、图型选择、排版规范到版本管理的完整工作流这篇文章就是把这套经验完整梳理出来。无论你是刚入门的技术新人还是要经常做方案汇报的开发者或者负责团队文档规范的人这篇内容都值得你花十几分钟读一遍。我会尽量讲清楚每一类图应该怎么设计、为什么这样设计以及那些我在实操中反复踩过的坑。图这个东西一旦你会设计了它就不再是文档的配图而是方案的论证工具。2. 动手之前先回答四个问题图的定位与受众很多人画图失败不是因为工具用得不熟而是因为没想清楚这张图到底是干嘛的。我的习惯是在新建画布之前先在脑子里过四个问题这四个问题决定了整张图的信息取舍、抽象层级和表达方式。2.1 这张图要推动什么决策图本身不是目的它要服务于一个具体的决策场景。比如方案评审会上你要让大家确认的是新引入的消息队列放在这个位置是否合理故障复盘时你要让大家看清楚的是调用链在哪一环超时了。这两种场景下图的重点完全不同。我见过很多人在画系统架构图时恨不得把每个组件都画上去结果评审时大家盯着的其实是中间那一条主链路。这就是典型的没想清楚决策点。我自己现在的做法是在画布左上角先写一行注释标注本图服务于XX决策画完检查时看着这行字删掉与决策无关的内容。这个方法听起来简单但真的能逼着你做减法。2.2 读者是谁处于什么上下文同一套系统给研发同事看的图和给业务方看的图抽象层级可以差出好几层。给研发看的图可以把服务名、端口、数据表都标出来给业务方看的图只需要呈现用户下单之后发生了什么的角色和顺序。这里的判断标准是读者的上下文。如果读者刚刚参与过这个项目的讨论你可以画得很细如果是第一次接触这个系统的外部评审专家你需要从一张全景图开始然后再用子图展开细节。我踩过的坑是拿着给内部研发看的详细架构图去给跨部门的人讲五分钟之后所有人都开始走神。不是图错了是对象错了。2.3 信息密度应该多高信息密度过高是新手画图最常见的毛病。一个方框里塞下服务名、部署方式、技术栈、负责人、监控指标结果字号越缩越小线条越拉越密。等你把图缩放到能全览的时候上面的字根本看不清放大看清楚了又丢了全局。我的经验是一张图的信息密度以A4纸打印出来之后不缩放能看清楚为标准。超过这个密度就要考虑拆图——要么按模块拆成多张子图要么把细节挪到附录或表格里。记住一个原则图的主干信息控制在7±2个节点左右人脑一次能同时处理的信息量是有上限的你非要塞进去30个节点那就不是设计是堆砌。2.4 是示意、是准确记录还是可执行蓝图最后要搞清楚这张图的性质。示意性质的图可以牺牲部分准确性换取易读性比如流程讨论时的草图准确记录性质的图要求每个连线、每个标注都对得上实际系统比如运维架构图可执行蓝图则是连未来要落地的模块也算进去的规划图。这三者的混淆会带来很大问题。把示意图当成准确记录去指导排障你会被误导把蓝图当成现状图去评审你会发现一堆怎么和线上不一样的质疑。我建议在图的标题或图例里直接标注图的类型比如示意图现状图目标架构图让读者第一时间知道该怎么读这张图。3. 五类高频图的适用场景与设计要点不同的问题需要不同的图型来表达。我见过有人用架构图去画业务流程也有人用时序图画系统静态结构不是说完全不行而是没有用对最顺手的表达方式。这里把我工作中最高频的五类图型梳理一下每一类都说说它的适用场景、设计要点和我实操时总结的规则。3.1 架构图重点是分层和边界架构图表达的是系统有哪些部分、它们如何组织在一起常见的有分层架构图、微服务架构图、部署架构图。设计架构图的核心不是把节点画出来而是表达清楚层次和边界。我的习惯是先确定横向的分层如接入层、应用层、数据层或纵向的边界如按业务域、按团队然后再往每一层里填充节点。连线的时候尽量保持连线走正交方向横平竖直避免斜线穿过多个层否则视觉上会非常混乱。还有一个细节架构图里的节点应该用统一的形状——同一层用同一形状不同层之间用形状区分比如服务用圆角矩形、数据存储用圆柱形这比花花绿绿的颜色更本质。3.2 时序图强调顺序和交互时序图表达的是在某个业务流程中参与者之间按时间顺序发生了什么。设计时序图最忌的是把每条消息都画成一样粗、一样黑——重要的消息和普通的调用应该有视觉权重上的区分。我通常的做法是把主要业务链路画成实线把旁路操作如日志上报、异步通知画成虚线然后只给最关键的那一两条消息加颜色标注。另外时序图里的时间轴方向一定要一致从上到下不要在中间突然改变方向。画时序图前先列一遍交互步骤清单再落到图里能省下很多返工时间。3.3 流程图核心是分支和异常流程图大家都会画但很多人只画了快乐路径——正常情况下的流程异常分支一笔带过甚至直接省略。真正设计得好的流程图会把异常处理作为一等公民画出来。我在设计流程图时会专门用不同的形状区分处理步骤和判断分支并且为每一个判断节点写出明确的布尔条件是/否、成功/失败不是写成功两个字就完了而是要写清楚什么算成功。还有一个建议当流程图超过两屏时别硬画成一张长图应该拆成主流程加子流程用预定义符号或跳转节点来连接。3.4 ER图与数据模型图关键是关系和基数只要涉及数据设计ER图几乎不可避免。设计ER图的要点是实体、属性、关系三者的表达要一致关系的基数1:1、1:N、N:M必须明确标出。我见过很多ER图画得像散落的盒子实体之间的连线没有方向基数也没有标注看的人根本不知道一张订单能对应几个明细。我的建议是在设计ER图时先列一张关系清单把所有实体之间的对应关系写成文字订单与订单明细是1:N确认无误后再画图画完再对着清单检查一遍基数的标注。颜色可以按业务域分区但在表达关系语义的时候一定要靠的是线条和符号不是颜色。3.5 思维导图/概念图用于拆解而非汇报思维导图在个人梳理思路时很好用但直接拿到正式汇报场合往往会显得松散。我的看法是思维导图这类辐射状的图更适合从中心主题向外发散的思考场景比如需求拆解、方案选项对比。如果要把思维导图的内容用于正式文档我通常会把它改写成层级清晰的树状结构或列表再配合一张概念图来表达概念之间的关联。设计这类图时中心主题一定要明确一级分支控制在5个左右再往下层层展开。如果分支超过三层建议把某一支单独拎出来画详情图。4. 从草稿到成品一套可复用的绘图工作流很多人在画图工具里直接开工边画边想画到一半推翻重来。我的经验是画图应该像写代码一样先有设计再有实现。下面这套工作流我用了很多年产出效率和质量都稳定不少。4.1 先用文字把图的内容写出来在打开任何绘图工具之前我会先写一个文字版的图的脚本。比如画架构图我会列出图名订单中台现状架构图类型现状图读者中台建设评审组分层接入层网关、鉴权、应用层订单服务、库存服务、支付服务、数据层订单库、库存库、消息队列关键连线下单请求经网关到订单服务 - 订单服务调用库存服务 - 下单成功发消息需要突出的边界中台与前台系统的边界、与第三方支付的边界这个脚本就是整张图的骨架。写完之后自己先看一遍逻辑顺不顺、有没有遗漏的关键交互这时候改文字成本极低等画完了再改就是大工程。4.2 搭骨架确定版式和布局第二步是把文字脚本落到画布上。这时候先不着急美化只做一件事把节点摆到大致的位置上把连线按主干逻辑拉出来看整体的流向是否顺畅。布局的选择很重要。常见的布局有两种自上而下的层级流适合分层架构图和流程图和从左到右的水平流适合请求链路和时序类的内容。选择布局的原则是顺着人的阅读习惯让主要流向和图的方向一致。我自己的偏好是架构图用自顶向下分层链路图用从左到右。4.3 规范排版对齐、间距、统一的形状和配色骨架搭完就开始排版规范。这一步骤直接决定了图的质量下限。我给自己定了几条硬性规则节点统一左对齐或居中对齐不允许随缘摆放相邻节点间距保持一致推荐不低于节点宽度的四分之一同层节点的宽度尽量统一长文本用换行而不是拉伸矩形整张图使用的颜色不超过3种主色另有1种强调色线条走正交路径避免斜穿每条线尽量标注它的语义这些规则听起来琐碎但组合起来的效果非常明显。一张对齐良好、间隙均匀的图哪怕没有复杂的设计看起来也比随手画的图专业好几个档次。4.4 加标注和引导让读者知道先看哪里排版规范做好之后我还会做一件事在图上增加阅读引导。最简单的做法是把标题放在图的左上角把图例放在右下角然后在关键路径上用数字序号①下单 ②扣库存 ③发消息标出阅读顺序这样读者就不会在复杂的连线里迷路。如果图里存在分支或可选项我会用不同的线型表示主路径和备选路径。还有一个个人习惯在图的底部留一行说明写清这张图的版本和最近一次更新时间。这样图被转发了多少轮大家也知道它有没有过期。4.5 输出与归档PDF、图片、可编辑源文件图的输出格式取决于用途。给别人看用 PDF 或 PNG给别人继续改就要交付可编辑的源文件。我建议在每次交付成图的同时把这个图的源文件和导出的图片放在同一个目录里命名遵循日期-图名-版本的格式。这里有一个容易忽略的点很多绘图工具的导出清晰度是有限制的导出 PNG 时要注意分辨率确保放大之后文字依然清晰。为了保险起见我导出时通常选择高倍率或直接导出矢量格式如 PDF/SVG避免在文档里缩放后出现糊字。5. 图也是代码版本管理与多人协作的实践图一旦进入协作场景事情就会变得复杂。多人同时改一张图怎么保证没有冲突图改了之后怎么让看的人知道变的是什么这一章聊聊我把图当作代码来管理的实践。5.1 文本化图表让图可以 diff传统的二进制绘图文件白板类、画布类工具的默认格式很难做版本比较。后来我转向了文本化图表的方案——用描述性的文本语法来定义图的结构再通过工具渲染成图。这种方式最大的好处是图和代码一样可以被版本管理系统追踪每次修改都能看到明确的 diff。文本化图表的优点不止于此。它还能让图的编写进入复用的流程你可以把常用的节点和连线定义保存成模板片段画新图时直接引用你可以在自动化流程里批量生成图比如根据配置数据自动生成部署架构图你还可以直接在代码评审平台里看到图的变化哪些节点被加上了、哪些连线被删掉了一目了然。5.2 多人协作时的约定与流程即使有了文本化图表多人协作依然需要约定。我参与过的团队里我们定了几条最基础的规则一个人改动架构图时先认领避免两个人同时大改图必须和代码一起提交变更、一起评审不允许图单独漂移在代码仓库之外每次变更要在提交说明里写清图里改了哪些结构和为什么改定期每个版本结束检查一次图的准确性与实际系统的一致性这几条规则看起来简单但执行到位之后图的可靠性和文档一样高。很多团队的架构图之所以沦为墙纸根本原因是没人维护版本漂移之后大家发现图已经不可信了就彻底放弃。反过来把图纳入评审流程它才会真正成为团队的知识资产。6. 我踩过的坑画完没人看、一改就废的典型案例最后聊聊我在 diagram-design 这件事上踩过的坑。这些教训如果提前知道能帮你省下大把返工时间。6.1 坑一为了美观牺牲可读性结果没人看得懂我曾经在设计一张系统全景图时为了让图看起来高级用了深色渐变背景、发光的连接线、3D 效果的节点。当时觉得很炫后来给组里新人讲业务时发现对方完全无法从图中获得信息——视觉负担太重注意力全被样式吸引走了。这个坑的核心是图的第一身份是信息载体不是装饰品。从此我给自己立下规矩在正式图里样式必须服务于信息分层禁止为了好看而设计。深色背景可以用在演示现场的大屏上但用在文档里就是灾难。6.2 坑二只画现状图不画目标图方案总是推不动有一段时间我画的架构图全部是现状图每次想推进技术改造拿着现状图讲我们要改成什么样对面的人总是追问现在的流程到底是怎样的。直到我区分开现状图和目标图两套图之后沟通才顺畅起来。给业务方看两个版本的图并排展示一张是现在的流程和痛点标注一张是改造后的流程和收益标注决策的讨论立刻变得具体。这个经验同样适用于小型变更哪怕只是一个接口改造也值得画前-后两张对比图。6.3 坑三图更新不及时最后成了没人信的废图这是最痛的一个教训。某系统的架构图画好之后三个月内系统经历了两次重构图没有同步更新。等一个新同事拿着旧图排查问题时被误导了好几个小时最后发现图里的服务和线上的根本对不上。从此之后图是否过期成了我评审文档时必查的一个问题。现在的解决方案就是前面说的文本化图表加版本管理。图跟着代码走代码发生结构变化时图的修改提示会出现在评审里。哪怕偶尔忘记更新通过文件提交记录也能很快定位到图的过期时间点不需要靠记忆维护。6.4 坑四信息过载一张图试图表达所有维度还有一类图作者非常努力地把容量信息、延迟指标、负责人、告警规则、部署节点全部画进一张图里。结果图字特别小缩放到全页根本看不清每一处标注都像在喊我很重要。这种图的失败在于没有做信息的优先级管理。我现在画图时会做一个三层信息拆解第一层是主干结构放到主图里第二层是关键细节放到子图或图注里第三层是参考数据放到链接或文档里。读者默认按照这个层级去阅读既不会在主干上迷路又能在需要时找到细节。7. 最后分享几个平时画图的小习惯讲了这么多最后把我目前还在用的几个小习惯列出来。它们不复杂但真的能提高图的质量第一画图前先写一段图的目标描述就算只有两三句话也要写。这个动作能拦住大部分随手画的冲动。第二画完之后放一放至少隔一小时再回来看一眼。脱离创作状态后你自己最容易发现自己图的逻辑问题。第三把好的图存进个人素材库。遇到相似场景时先参考自己的历史方案再决定要不要结构调整。第四图的命名尽量描述性不要叫未命名图不要用final-最终版-真最终版这类命名日期加版本号就够了。关于 diagram-design 的经验我能沉淀出来的核心就一句话图的本质是被结构化的信息设计图的过程就是不断取舍信息层级的过程。你不需要成为视觉设计的专家但你需要像一个工程师一样思考——每个节点、每条连线、每层布局都应当经得起为什么放在这里的追问。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
