這是鐵人賽的最後一篇文章，我想在這個結尾分享為什麼我會寫這個主題，這是因為幾個月前的某一天我正在與跨部門的同事溝通 API 串接事宜，我看到他邊討論邊只用了一個看似不太適合的圖表繪製方式在紀錄，於是我就告訴他使用了泳道圖這篇的使用方式，之後我也看到其他同事在繪製流程、討論紀錄、整理上都用了不太適合的繪製方式，因此萌生了要探詢圖表繪製方式的念頭。

過去的日子裡的確有很多我完全沒有聽過的圖法，像是 SysML, Object Role Modeling, Property Graph Diagram…etc，這些主題的建構都是來自同一個關鍵字【工程師、圖表】找到這些分類，而且也是使用心智圖的方式在歸納圖表類型，好讓我知道這個圖表到底用途是什麼。

至於研究的方針，就必須得從每一篇文章整理出來，我的手法在寫了幾次之後，漸漸有一個理解【圖法】知識的流程框架，就是先問 【圖法定義】 ，這也是我大多開頭就會寫 XXX 是什麼； 再來是這個圖法有哪一些製圖元素，然後再問如何製圖、製圖哲學。

透過歸納出這套理解框架，我在一些資源非常凌亂也碰到文獻亂寫的狀況，得以透過這個固定的知識框架讓我釐清哪篇文章才不是假新聞，最有趣的錯誤內容混淆最多的主題就是 ER, EER Diagram，這讓我深信定義理解某一個領域，使用【定義必備問題】是相當重要的，這在我修分析導論的時候特別有感，我發現很多的內容都必須都去問開區間、閉區間、多一點、少一點，少一個，多一個，先做後做，交換會怎樣，尤其是邊界情形…etc 等，但這個【必備問題】必須得靠每個人自己去摸索，從領域的問題框架下手，有一種幫助瞎子摸象的方法，瞎子可以固定要從某些部位開始摸，他就會了解一個大象每一個細節的不同之處。

再來是針對每一個文章，我盡量都會把 References 註記在文字上，幫助我了解這段話是從哪邊來的，圖片是從哪邊參考整理而來的，我知道在這系列的文章中我僅是整理 References 的知識，甚少分享個人的看法，也許有機會在某屆的鐵人賽還有機會再次相見!