Mermaid 讓「圖即程式碼」站穩腳跟：時序圖成了 Markdown 裡的文字

UML 是軟體界試圖將設計圖標準化的一大嘗試：OMG 於 1997 年接納它，ISO 則在 2005 年採用。它最終被自身的重量壓垮——UML 2.2 的文件超過 1,000 頁，這套標準也與笨重的 CASE 工具及繁瑣的前置作業綁在一起，因此到了 2020 年代，支持者與批評者都同意它基本上已經死了。

有一項產物比它活得久：時序圖，一張簡單描繪元件之間訊息流動的地圖。留下來的人畫得出來，但工具讓這件事很痛苦——BitHawk 的開發者 jessems 發現，在 Lucidchart 裡拖曳圖形既慢又脆弱，日後任何變更都會毀掉版面配置。

解法是 Mermaid，一個 JavaScript 函式庫，讓你以純文字宣告圖表：參與者、箭頭與訊息寫在 Markdown 程式碼圍籬裡，由 Markdown 工具鏈負責算圖。作者原本預期用程式碼寫程式碼會覺得不對勁，試了之後卻發現它快速、輕鬆又漂亮；他開始把時序圖嵌進使用者故事的實作計畫裡，用熱重載預覽，再匯出成圖片貼進 HTML 欄位。

它之所以站得住腳，是因為圖表成了普通的程式碼產物。它與所記錄的故事並存，能在程式碼審查中 diff，更新時只需改一行而不必重畫，而且只要 Markdown 能顯示的地方它就能顯示——Hacker News 討論串的留言者指出，GitHub Markdown 開箱即支援 Mermaid。Mermaid 的創辦人將其定位為：以非正式的簡潔，取代 Rational Rose 時代工具那種僵硬的複雜。

讓圖表成為程式碼產物：在 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 匯出成圖片。