學習流程圖原理與使用技巧

  筆者 在 W. L. Kocay   & D. L. Kreher 合著的 Graphs, Algorithms, and Optimization 一書中找到 靈感 , 遇到錯綜複雜的分支迴圈 , 只要用一定的撰寫程式風格並且遵守一定的編排準則 , 便能從看似無限的輪迴中獲得正確的出路 . 請參考該書一個典型範例 Fig 1 Fig 1. 1. 首先 , 所有的分支迴路 都會集中 向右側 . 2. 每一行一定只有一則作業項目 , 如同程式碼一般 . 就算有多行 ,      它們也是連續作業 , 可視為同一 作業項目 3. 對應到流程圖時 , 則每一方塊則代表一項作業 . 4. 作業層序由上而下 , 盡量不要回測 . Fig 2 Fig2 是 李家同 老師的書中教學範例 .  詮釋流程作業非常詳盡 . 但實務上非常繁瑣 , 不易採用 且 後續維護困難 . Fig 3. 則是本文所提倡的改良式流程圖 . 讀者一眼應該便能看出兩者本質上的優劣點 . Fig 3 @連結這個範例及程式碼

李家同教授相當重視流程圖規劃 , 並強調它與邏輯考思與撰寫程式的關聯性 . 可是當今程式設計者願意在寫程式之前 , 花盡心思先規劃一頁完善的流程圖 , 簡直少之又少 .   除非他的老闆上司強烈要求 . 若是要將優 化的 程式碼或除錯後的原始碼同步更新回原來的流程圖 , 那可是難上加難 . 為什麼大家都認為很重要但實施起來卻很困難呢 ? 作者從事撰寫程式工作非常多年 ,一直苦思這個問題,直覺認為必定有一 段失落的環節. 最後終於在 W. L. Kocay  & D. L. Kreher合著的 Graphs, Algorithms, and Optimization一書中找到靈感,歸納一些經驗與建議, 提供給後進初學者參考 , 讓他們在剛進入這個領域就能了解流程圖與程式碼之間的關聯性 , 養成將問題解析清楚後 , 將合乎邏輯的流程圖繪製出來 , 最後再由程式碼來實踐整個專案 . 需要除錯修改程式時 , 也能同步更新流程圖. 作者觀察到傳統的流程圖比較類似二維結構 , 是根據人類的理解便利性所開發設計 , ” 太過模糊 籠統 ” , ” 不是很精準 ”. 例如 Fig 1. 第一個決策不成立則進行作業 A, 再來後 A 決策判斷 ; 第 一個 決策成立 則進行 作業 B, 再來後 B 決策 判斷 . 簡單易懂 , 非常適合上司主管結論 . 但對程式開發工程師則不是這麼容易 . 決策 為偽 ”IF” 在流程圖上有清楚的作業 方塊 圖 . 決策為真 ”ELSE” 在流程圖 上卻無 . 此外我們又可用 決策 為 真 在 “IF” 上 . 讓判斷邏輯產生許多組合 . 最後 , 四個決策的結束在同一個接點往往造成問題 . 有經驗的工程師也許對這種轉合視為當然 , 但資淺者則容易誤入歧途 . 而 程式碼則是根據計算機運行規則 , 比較傾向一維結構 , 要求很嚴謹 , 一絲不苟 , 多一個逗點 , 少一個括號 都不 可以 , 一行指令 一行 指令依照次序執行 . 它是 Fig 1 諸多解決方案中的一個 . 如 Fig 2 Fig 2. Program Sequence 好的 流程圖邏輯讓你的 程式開發更順暢 程式設計最重要的能力是把作業步驟有條不紊地依序寫成 程式 . 作者參考上述書中演算法的技巧,採