後记

这是铁人赛的最後一篇文章，我想在这个结尾分享为什麽我会写这个主题，这是因为几个月前的某一天我正在与跨部门的同事沟通 API 串接事宜，我看到他边讨论边只用了一个看似不太适合的图表绘制方式在纪录，於是我就告诉他使用了泳道图这篇的使用方式，之後我也看到其他同事在绘制流程、讨论纪录、整理上都用了不太适合的绘制方式，因此萌生了要探询图表绘制方式的念头。

过去的日子里的确有很多我完全没有听过的图法，像是 SysML, Object Role Modeling, Property Graph Diagram…etc，这些主题的建构都是来自同一个关键字【工程师、图表】找到这些分类，而且也是使用心智图的方式在归纳图表类型，好让我知道这个图表到底用途是什麽。

至於研究的方针，就必须得从每一篇文章整理出来，我的手法在写了几次之後，渐渐有一个理解【图法】知识的流程框架，就是先问 【图法定义】 ，这也是我大多开头就会写 XXX 是什麽； 再来是这个图法有哪一些制图元素，然後再问如何制图、制图哲学。

透过归纳出这套理解框架，我在一些资源非常凌乱也碰到文献乱写的状况，得以透过这个固定的知识框架让我厘清哪篇文章才不是假新闻，最有趣的错误内容混淆最多的主题就是 ER, EER Diagram，这让我深信定义理解某一个领域，使用【定义必备问题】是相当重要的，这在我修分析导论的时候特别有感，我发现很多的内容都必须都去问开区间、闭区间、多一点、少一点，少一个，多一个，先做後做，交换会怎样，尤其是边界情形…etc 等，但这个【必备问题】必须得靠每个人自己去摸索，从领域的问题框架下手，有一种帮助瞎子摸象的方法，瞎子可以固定要从某些部位开始摸，他就会了解一个大象每一个细节的不同之处。

再来是针对每一个文章，我尽量都会把 References 注记在文字上，帮助我了解这段话是从哪边来的，图片是从哪边参考整理而来的，我知道在这系列的文章中我仅是整理 References 的知识，甚少分享个人的看法，也许有机会在某届的铁人赛还有机会再次相见!