2016-08-09 22:04:09
流程圖(FlowChart)
這個圖就需要動點腦子瞭，梳理流程本身還好說，把事情給還原出來，關鍵是流程優化也要靠它。流程圖根據表現形式，可以分成普通流程圖（好吧，我承認這個術語是我自己造的……人傢也不知道怎麼叫嘛）以及泳道圖。依據使用場景，則可分成業務流程圖、數據流程圖、頁面流程圖……
具體的，我之前也寫過一篇拙文，如果有興趣的話，也可以繼續去拍拍磚。
架構圖：
現在我畫得最多的，而且覺得需要好好學習的，就是架構圖。但是這個圖很神奇，沒有對錯，沒有辦法去評估，甚至還沒找到一定的繪圖標準。請教一些技術架構的牛人，得到的就是這種圖要體現系統最高層次的劃分以及各部分的依賴關系以及系統與外部的關系。自己看瞭網上的一些架構圖，發現也確實沒有一定的規則。所以隻能慢慢感悟瞭。
但是我個人真的有個強迫癥：這世界上怎麼會存在講不清道不明的技能和知識呢？隻要存在，一定有潛在的規則和方法（甚至可以分解成具體步驟的），隻是還沒有被很好總結出來而已。
架構圖舉例：
因為架構圖能夠既清晰表達層次劃分、大的模塊的分類，又能夠很好表達他們之間的錯綜復雜的關系（其實更多就是依賴、引用、數據流向等關系），所以經常被演繹成“生態圖”，比如移動互聯網生態圖：
關系圖：
這樣的圖你大概在網上經常見吧？
不得不承認，這樣的表達，確實比成段的問題要清楚多瞭不是，如果你搜“關系圖”的話，出現最多的就是這種應用場景瞭。此外就是在計算機領域的“實體關系圖”－也即E-R圖，也是我學習內容之一。但是因為關系圖的關系本身概念更加廣闊，所以不管任何關系，其實都是可以叫做關系圖的。
如果架構圖再進行簡化，到一個個實體之間的關系層面，則可視為關系圖。而通常說的概念圖，從狹義的層面，也是一種關系圖，從廣義的層面，則無所不包瞭，哪怕你隨手勾勒一個簡筆畫，用來描述你想要的產品，也是一種概念圖瞭。
說到底，掌握畫圖的核心：在於表達關系。其實我們可以不拘泥於這些圖的分類，你隻要有基本的圖形、線條、合適的工具，那麼就可以開始瞭。
此外，講故事，也可以在畫圖之外，有助於我們理解，比如當時我的一個牛掰同事Justin，就是這樣給我們普及瞭下網站基礎架構知識：
Apache：服務器。APACHE好比是飯店的服務員, 你告訴他給我上個八抓魚, 他就給你弄個八抓魚.你說: 我要熊心豹子膽!他說:”對不起, 您要的菜不存在”服務員還能根據特定的菜來做跳轉.例如,規定, 凡是要熊心豹子膽的, 就給他上盤老鼠藥.這服務員很厲害他能把所有用戶點的菜, 都記錄下來能根據菜量和品種的不同, 找到特定的廚師.能把不受歡迎的顧客拒之門外.Java：廚師。JAVA是對請求做出相應處理, 取出數據, 加工數據, 返回結果。服務員說要紅燒豬蹄. 那麼廚師就從向配菜員要豬蹄, 然後炒巴炒巴就做好瞭, 交給服務員.隻要有材料, 廚師幾乎是什麼都能做. 但是廚師是有快慢好壞之分的.有的又快又好, 有的又慢又爛。這樣可以理解其他的開發語言，都有類似的屬性。數據庫：數據庫就是一個配菜員加一個大冰箱。是存儲數據, 各種數據處理工具的一個東東，廚師（java）說要個20個10斤重的白蘿卜, 配菜員就從冰箱裡找出來,再給廚師.緩存：把經常要用到的配菜和原料在廚師旁邊留一些備用，免得每次都要去數據庫要數據。有些是一直要放到廚師身邊，叫做本地緩存，但是廚師身邊的空間是有限的，所以還需要遠程緩存，這樣即使多走一些路，也不至於每次都要麻煩配菜師取菜。這樣，再配合他提供的網站技術架構圖，非常形象不是嗎？
3. 驗證
當你梳理瞭術語，並能夠能通順地講、可視化他們之間的關系的時候，其實我覺得你應該已經入門瞭。
但是你的理解是否是對的？或者你在過程中，一定也會遇到疑惑和理解障礙。
將這些問題，記錄下來，然後再重新進行一些針對性的精讀，效果比一開始精讀的好太多瞭。因為：
你帶著問題去讀，一定會有更多思考，變被動的接收成為與作者的交互你有瞭一定的知和理解基礎到這個階段，如果還遇到一些無法解答的問題，那麼詢問更為資深的人物獲得幫助，另外，也不必對他們的回答全盤接受。當你已經有瞭一些基礎，你也會發現，或者這些“專傢”給出的答案，也僅僅是一種可能性、一種場景而已。或者是他自己的很好的經驗，但是是否能夠被你所用，則要具體情況具體分析瞭。