iT邦幫忙

2021 iThome 鐵人賽

DAY 30
0
自我挑戰組

後端工程師與圖的修練系列 第 31

後記

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

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

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

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

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


上一篇
Mind Map 與 Roadmap
系列文
後端工程師與圖的修練31

1 則留言

我要留言

立即登入留言