解法
UML是软件行业对设计图标准化的宏大尝试:OMG在1997年采纳,ISO在2005年采纳。但它在自身重量下崩溃了——UML 2.2的文档超过1000页,标准又和笨重的CASE工具、繁重的前期工作绑在一起,所以到2020年代,支持者和反对者都公认它基本已死。
但有一个东西活了下来:序列图,一种简单描述组件间消息流动的图。它能存活下来,但工具让人痛苦——BitHawk的开发者jessems发现,在Lucidchart里拖拽形状又慢又脆,任何未来改动都会破坏布局。
转机是Mermaid,一个JavaScript库,你把图声明为纯文本:参与者和箭头消息写进Markdown代码围栏里,Markdown工具链来渲染。作者尝试时原以为代码套代码会很别扭,结果发现快捷、无痛而且漂亮;他开始把序列图嵌入用户故事的实现计划中,用热重载预览,导出为图片贴进HTML字段。
它之所以能立住,是因为图变成了普通的代码制品。它和它文档化的故事并排,在代码审查中能diff,一个一行改动就能更新,而不是重画,并且能在任何支持Markdown的地方渲染——GitHub的Markdown原生支持Mermaid,Hacker News评论区也指出来了。Mermaid创始人把它定位为非正式的简单,取代了Rational Rose时代工具的僵化复杂。
What it achieved
把图变成代码制品:在Markdown里用文本打字,让渲染器来画
为什么有效
打字比拖拽快,所以写图的成本从画布会话降到文档旁边几行字。
文本可以像代码一样版本化并diff,所以图片更新是审查里的一行改动,而不是脆弱的重画。
Markdown渲染器无处不在,所以图能在团队已经阅读和评论文档的地方显示。
UML死于堆复杂度;Mermaid只保留有用的部分,去掉了工具成本。
可以借鉴什么
一个标准通过降低人们已经工作的地方的成本而存活:获胜的图是这样的一种,你可以在文档里打字,并在审查时diff。
后续
这篇帖子在2023年7月24日于Hacker News获得207分和111条评论。评论者指出GitHub Markdown原生渲染Mermaid,将其与PlantUML、d2和Graphviz比较,并推荐像Docusaurus这样的Markdown生态系统,一条安装命令就能渲染。作者在BitHawk保留了这套工作流,实现计划写进Markdown文件,其中序列图就嵌在里面;当记录需要HTML时,用mermaid-cli导出为图片。
从这里,追溯依据