上个季度我接手一个遗留系统的文档重构翻出十几张流程图画图的人早就离职了。有意思的是这十几张图里光开始/结束这一个符号就出现了四种画法圆角矩形、椭圆、正圆还有一张直接在矩形里写了个开始。更别提判断框了有的用菱形有的用矩形加一个问号还有的用六边形。结果就是我花了两天时间搞清楚这些图到底在说什么比读代码还慢。这件事之后我把程序流程图规范这件事重新捋了一遍。程序流程图看着是最没有门槛的文档形式中小学信息技术课就教过但它恰恰是最容易失控的——因为每个人心里都有一套我觉得这样更清楚的画法谁也没有把它当回事。本文要讲的就是怎么把这套图从各画各的变成团队里能直接对齐的资产符号语义怎么定布局有没有硬约定框里写什么字一张图画到多细就该拆以及怎么用工具把这些规则钉死让它不靠人的自觉。内容适合三类人要交付流程图给评审或甲方的开发、写需求文档的产品、以及需要评审别人流程图的测试和技术负责人。哪怕你只画过学校作业那种练习图看完也能直接照着改。1. 流程图被打回的真正原因语义不确定而不是画得丑1.1 判断框的是/否从来没人较真我参加过不下二十次流程图评审最容易吵起来的从来不是这个框太大或者颜色不好看而是同一个判断框出来的两条线没人说得清哪条走的是正常路径。画图的人心里门儿清看的人要顺着线一路追过去,追到某个处理框才发现哦原来这条是异常分支。这就是流程图最大的问题它是给人读的但它的作者往往只对自己可读。判断框有两个甚至三个出口出口上的标注写了是/否可是是对应的是校验通过还是校验失败这个语义在图的层面是不确定的只能靠文字补。评审被打回十次里有六次是因为这个。真正规范的流程图判断框的出口标注必须是自解释的。比如一个判断框写token 是否过期那么两个出口就不该标是/否而应该直接标已过期和未过期。看着啰嗦但读图的人不用回头去看判断条件就能理解走向一页图能省下三分钟。1.2 三种最典型的退回意见我把这两年收到的流程图评审意见归了归类出现频率最高的就三条。第一条是缺少终止条件。尤其是带循环的流程图里画了一个判断框往上回指但没有一个明确的出口说明循环什么时候结束。读图的人会怀疑这是不是一个死循环。第二条是分支不闭合。一个判断框出去两条线最后汇聚到两个不同的处理框然后就断在那里了没有汇回主干。图看起来没画完实际上画的人心里有数只是懒得画那根汇合的线。第三条是符号混用。同一个图里输入和输出用了两种不同的框处理框有时候是矩形有时候是圆角矩形。这种问题在评审时最容易被提因为它是纯形式问题谁都能指出改起来又很麻烦。1.3 规范到底要管哪四件事很多人一听流程图规范就以为是背符号表其实符号只是其中一层。一套能落地的规范至少要覆盖四层层次管什么出问题的典型表现符号层每个形状代表什么语义判断框用矩形、起止用椭圆布局层线条走向、分支方向、回环方式线条交叉成蜘蛛网、主干歪斜文字层框内写什么、怎么写处理框里塞整段伪代码粒度层画到多细、怎么拆页一张图画了八十个框这四层里符号层是标准能管的有国家标准可依布局层和文字层一半靠标准、一半靠团队约定粒度层基本没有标准全靠经验。后面的章节我就按这四层往下讲。2. 符号层那几个天天在用、却天天用错的形状2.1 基础符号到底有几个规范的依据是 GB/T 1526对应国际标准 ISO 5807里面定义的符号其实比大家日常用的多得多包括处理、判断、起止、输入输出、文档、预定义处理、人工输入、人工操作、存储、连接符、页间连接符等十几种。日常程序流程图用得到的核心就六七个我用一张表说清楚。符号形状名称准确语义圆角矩形或圆起止符流程的开始、结束或引出一个外部流程矩形处理一段计算、赋值、状态变更只有一个入口一个出口菱形判断根据条件在多条路径中择一一个入口多个出口平行四边形数据/输入输出读取或写出数据不改变数据本身双竖线矩形预定义处理调用一个已定义的子流程或函数图内不再展开底部带波浪的矩形文档输出或输入一份文档形式的载体小圆圈连接符同一张图内连线的断开与续接小圆圈加页标页间连接符跨页或跨图的连接这里有两个特别容易被忽略的点一是预定义处理和处理的区别前者的存在是为了把复杂度藏起来代表这里有个已经定义好的东西我不展开二是连接符和页间连接符不是一回事前者在同一页内跳后者跨页跳混用会让读者不知道该翻哪一页。2.2 起止符不是必须的但主流程必须有新手最容易犯的一个错是给每个子流程都画一对起止符。一个大的流程图里如果每个分支都从头开始、到尾结束读者会以为这是几条独立的流程。正确的做法是一张图或者一套图的最外层只有一个入口和一个出口用起止符标。内部的子流程、被调用的函数用预定义处理框表示不单独配起止符。这背后的逻辑很简单起止符代表的是这个流程与外界的分界子流程并没有与外界直接交互它只是被父流程调起来的一段逻辑。如果一张图里真的存在多个合法的入口比如一个事件驱动的处理流程可能被定时器触发也可能被消息触发那就用不同的起止符分别引出但要在起止符里写清楚触发源。这一点在可靠性、IoT 这类多触发源的场景里特别常见别偷懒只写一个开始。2.3 判断框的出口数量是有讲究的标准里判断框是一个入口多个出口没说上限。但工程实践里一个判断框超过三个出口图就开始难读了。我的经验是超过三个出口就拆成两层判断或者换成一个分支表表述。两个出口最舒服三个出口勉强能看五个出口基本等于灾难。还有一个反过来的坑把该用判断的地方用处理框。比如累加计数并判断是否达到阈值很多人会画成一个处理框然后在旁边的注释里写达到阈值则退出。这是典型的偷懒判断被藏进了处理框里。判断必须显式地用菱形表达因为它是流程走向的分叉点藏起来就等于把图的骨架藏起来了。有一条经验我一直在用只要这个框会导致后续流程走向不同就必须是菱形哪怕它同时也做了别的计算。宁可多画一个框也别把分叉藏起来。2.4 那些看着对其实是野路子的画法最后列几个我见过但不符合规范的画法供对照。用矩形表示输入输出靠文字区分——不行输入输出有专用符号就是为了让读者一眼看出数据边界在哪。用实心圆点表示连接符——不规范连接符就是小圆圈实心点是有些绘图工具的默认连接点标记不是符号。用不同颜色区分主干和分支——颜色可以作为辅助但不能作为唯一区分手段因为黑白打印、色弱读者都会丢失信息。主干靠位置和线宽区分更可靠。判断框用六边形或带斜角的矩形——这是有些 BPMN 工具的做法但在程序流程图语境下不是标准符号换成菱形。3. 布局层主干单线、分支右行、回环收口的约定3.1 走向和主干线布局这条线标准给的建议很简短自上而下、从左到右。就这么八个字但落地的时候要拆成一堆细则。核心约定是主干单线——整个流程的主路径应当是一条从上往下的竖直主线尽量不左右横跳。这听起来像洁癖但它直接决定了读图的效率。人眼读图是先扫竖线再扫横线如果主干本身是弯的读者就得一段段拼接认知负担立刻上去。主干线上的框要等宽对齐也就是说处理框的左边界尽量对齐成一条竖线。判断框可以稍微宽一点因为菱形里要写字。但不要让框忽宽忽窄那会让读者以为框的大小有含义实际上没有。3.2 线条交叉要尽量避免不只是丑很多人觉得线条交叉只是不够美观其实它直接影响正确性。两条线交叉的时候交叉点如果没有明确的跨线标记读者会怀疑这里是不是一个连接点。而流程图里的连接是靠线段端点不是靠交叉所以交叉本身没有任何语义——但读者不一定知道。减少交叉的常用手段有两个一是把分支画成向右展开的梳子形状主干竖着分支从右侧水平伸出分支内部再纵向排列二是对回环用连接符打断不画实体长线。特别是跨越大半个画面的回环线一律用连接符这是最有性价比的一条布局规则。3.3 分支展开与汇聚的对称性一个判断框出去两条分支规范的画法是两条线对称展开一条向左一条向右或者干脆都先向下再水平分开处理完之后再对称汇回主干。这种对称的叉子形状读者一眼就懂。反过来如果一条分支直接往下走另一条分支拐了好几道弯才回到主干读者就会误以为那条弯的分支是异常路径或者额外处理。走向的不对称会被读成语义的不对称——这是流程图里一个很有意思的心理现象也是很多人画图时不自觉传达出去的暗示信息。如果你确实想传达这条是常规路径那条是例外路径这个含义那就应当刻意让常规路径走主干例外路径走侧支并明确标注而不是靠弯弯绕绕来暗示。3.4 回环和跳转能不画实体线就不画循环是目前最考验布局的结构。一个循环在流程图上就是向上回指的箭头这条箭头骑着主干线往上走会穿过中间好几层框把图搅乱。我的做法是短距离回环回跳到相邻的上一两个框直接画实体线从右侧绕上去长距离回环一律拆成两个连接符一个标在跳出的位置一个标在跳回的位置图面上就只剩两个小圆圈加一行标注。代价是读者要跳一下但换来的是整页的清爽。还有一个更彻底的方案如果循环体内部逻辑复杂直接把它抽成一个子流程主图上只留一个预定义处理框加一条回指线。这也是后面讲粒度分层时会用到的技巧。4. 文字层框里写什么才不叫伪代码4.1 处理框必须是动词开头的可执行描述处理框的文字我给自己定的规矩是主语默认省略开头是动词描述一个完整动作。比如计算订单总价、写入用户记录、初始化连接池。长度控制在十几个字以内超出就说明这个框该拆了。最常见的错误是把处理框写成一段代码或者一段伪代码。比如框里写for i in list: sum i这已经越过了流程图的表达边界。流程图是表达做什么的不是表达怎么写的。真要表达实现细节那应该直接看代码而不是在图上画。还有一种错误是写空话比如处理数据、业务逻辑。这种框放在图里没有信息量评审时一定会被问具体是什么。尽量写成校验手机号格式、合并两条物流记录这种一看就懂的动作。4.2 判断框的条件要是能回答是非的短句判断框的文字规范和处理框不同它要写成一个可以被回答是/否或哪一类的问题。比如库存是否充足、用户等级是哪一档。这里有两种风格一种是以是否结尾一种是以是哪一档这种枚举式。我个人的偏好是判断框里写陈述式条件出口上写结果。比如框里写重试次数 3出口分别标是继续重试和否进入失败处理。如果条件本身比较长比如涉及两个变量的比较就拆成两个连续的判断框别在一个框里塞复合条件。复合条件里最坑的是与/或混用。判断框里写余额充足 或 已开通免密出口的两条分支会让读者反复确认这到底是或还是且。解决办法就是拆框一个框判断一个变量复合逻辑用连续的菱形表达。4.3 输入输出框要标明数据来源输入输出框里写什么写数据的名字加上来源或去向比如读取用户信息(来自用户表)、输出对账文件(至对象存储)。很多图里只写获取数据、返回结果读者根本不知道数据从哪来、到哪去。这一点在跨系统流程里尤其重要。如果一个流程图横跨三个系统那么每一个输入输出框都应该是系统边界的一部分写清楚是哪个系统在读写。这些框连起来其实就是一张数据流图能帮读者快速看清系统的交互面。4.4 术语一致性靠一张表来兜底流程图被吐槽看不懂有相当一部分是术语不统一造成的。同一个东西有的框里叫订单有的框里叫交易单有的框里叫单子。读者会以为是三个不同的实体。解决办法很朴素但有效画图之前先列一张术语表规定每个核心概念在图里的固定叫法。这张表不用长通常十个词以内就够。它带来的收益是复利式的——越大的系统、越多的图收益越高。一个小技巧把术语表直接贴在流程图所在文档的开头评审的人看到就能对上号省去很多来回确认。5. 粒度与分层一张图装不下的时候怎么拆5.1 先定一个单页容量的心理阈值粒度这件事没有标准答案但有一个可操作的经验值一张 A4 横版、正常字号下主流程的框控制在 15 到 20 个以内。超过这个数读者就要开始跳读得在脑子里存状态才能跟上。超过这个量的图八成不是逻辑变复杂了而是把不该在这一层展开的东西画进来了。比如一个订单流程如果把所有异常分支、所有日志记录、所有参数校验都平铺在一张图上很快就爆了。正确做法是分层。5.2 概览图、子流程、叶级图的三层结构我一般把流程图分成三层。第一层是概览图五到九个框只画主路径和主要异常出口。它回答的问题是这个流程大致做了什么。给谁看给不熟悉这个系统的人看给评审会上第一眼的人看。第二层是子流程图每个概览图里的预定义处理框对应一张子图展开详细步骤。它回答的是这个环节具体怎么走。第三层是叶级图只在真的需要精确对齐逻辑时才画比如复杂的并发处理或者状态机。到了这一层很多团队会干脆改用状态机图或者时序图因为流程图表达并发是它的短板。这三层之间的连接靠页间连接符每张子图顶部标清楚这是哪张图的哪个框展开的底部标清楚退回哪一层。这看起来是很繁琐的仪式感但它是让一套图能被人接手的唯一办法。5.3 流程图和代码的边界在哪里还有一个常被问的问题流程图画到什么程度就该停直接去看代码我的答案取决于图的用途。如果是给非技术人员看停在业务动作这一层把技术细节交给文档或者注释如果是给开发对齐接口和并发逻辑那要画到函数调用级别再细就没必要了因为再细的图维护成本会超过它带来的价值。这里有一条底线流程图一旦画到和代码一一对应它就开始过时。代码改一行图就对不上了而没有人会记得同步改图。所以流程图的粒度应当停在变化频率低的那一层把易变的部分留给代码和注释。6. 把规范钉进工具链模板、文本化画图与评审清单6.1 用模板固化符号和样式规范写在文档里永远有人不看。最有效的落地方式是把规范变成绘图工具里的模板。以 draw.io现在叫 diagrams.net为例可以把符号表做成一个自定义图形库团队每个人都导入同一个库画出来的符号自然一致。样式也要固化统一的框体字号、统一的线宽、统一的箭头样式、统一的主干对齐网格。特别是对齐到网格这个设置打开它以后主干线自然就是直的了省掉大量手动对齐。Visio 里同样可以做模板stencil原理一样。6.2 文本化流程图PlantUML 和 Mermaid 的取舍图形工具的优点是灵活缺点是没法版本管理。两个版本的图存在 Git 里diff 出来是二进制乱码根本没法评审。这就是文本化流程图的价值所在用代码描述图图的变更就变成了文本 diff可以走正常的代码评审流程。常用的两种文本化方案我列个对比。维度PlantUML 活动图Mermaid 流程图语义模型偏向活动图分支合并语义清晰偏向通用流程图灵活符号规范性默认样式接近标准默认样式偏现代需要配置布局控制自动布局人工干预有限自动布局导向前端文档适用场景后端流程、接口时序配合文档内嵌、README 展示我个人的用法是需要放在代码仓库里长期维护、需要走评审的图用 PlantUML 活动图需要嵌在说明文档里快速展示的用 Mermaid。两者都能生成图片但源文件是文本这点最关键。一个 PlantUML 活动图的基本骨架长这样startuml start :接收请求; if (参数是否合法?) then (合法) :查询用户; if (用户是否存在?) then (存在) :生成订单; else (不存在) :返回未注册; stop endif else (不合法) :返回参数错误; stop endif :返回订单号; stop enduml注意这里判断框的出口标注写的是合法/不合法、存在/不存在而不是是/否这就是前面说的自解释原则在文本化工具里同样适用。6.3 用版本管理和评审流程管住图的变更把流程图源文件.puml 或 .drawio 的 XML放进 Git和代码放一个仓库或者一个文档仓库然后在合并请求里一起评审。这样做的最大好处是流程图不再是一个画完就扔的附件而是有历史、有归属的资产。我们的做法是凡是与核心业务逻辑相关的流程图源文件必须进仓评审时和代码一起看。图改了但代码没改或者代码改了但图没改评审人一眼就能看出来。这条规则执行了半年我们仓库里过期的流程图比例从一半以上降到了个位数。6.4 我审图时用的那份清单最后把我自己审流程图时对照的清单放出来一共八条按顺序看序号检查项判断标准1入口出口是否唯一整图只有一个起止对按触发源区分2判断框出口是否自解释出口标注写结果不写是/否3分支是否都汇回主干每条分叉最终有汇聚点或明确终点4循环是否有出口每个回环都要有跳出条件5符号是否统一同类语义用同一种框6文字是否是动作描述处理框动词开头无伪代码7线条交叉是否可接受交叉处无歧义长回环用连接符8粒度是否单页可读主流程 15 到 20 框以内清单不长但每次评审按这个顺序过一遍绝大多数形式问题在开口之前就被筛掉了。我个人在实际操作中的体会是流程图规范最难的从来不是记住那些符号而是忍住多画一点更保险的冲动。图越满重点越糊。真正被团队反复引用的流程图往往就是那些框少、线直、判断框出口写得明明白白的图看起来朴素但谁都能在三分钟内读懂。规范不是为了让图更漂亮而是为了让读图的人少花一点时间——这一点想通了剩下的细节自然就愿意抠了。