當然要啦。

畫FLOW CHART可教編寫員(Programmer)清晰知道自己如何完成程式,達到客戶要求,如按字搜尋用戶瀏覽記錄、個人資料、等等。

FLOW CHART,流線圖,顯示一個電腦程式的完整流程,包括起始,判斷過程,結果,和所需數字。FLOW CHART 背後,就是工程師的心血設計和解難草圖。

http://www.rff.com/software_development.png

西方編寫員都會先畫好,再鍵戰。香港編寫員則不然,(寫APPS的、WEB APP的)大多數身於「限米煮限飯」的蚊型公司,被上司得閒催你,快手完成,逐漸培育成一個壞習慣:聽了上司要求,就直接埋頭做,按多少頁,做多少頁。結果做出來的,不是新增少少要求就砍掉重練,就是錯漏百出,掃多幾頁就死機。我們往往總是不斷收到要求,不斷開發,不斷完成,鮮有一個安靜的時空去重新解構,轉化一連串的要求為一個個設計模組(Module),以及運行的次序,邏輯:即是俗語說的「個App點樣行」。沒有 FLOW CHART,就是不斷忙碌改動,對開發者、管理層、客戶,三方面,徒增無謂壓力,更令自己朝不保夕,以一個謊圓一個謊。

以一個謊圓一個謊,不會求到他人的Ungoogoo,只是不斷顯露自己思維邏輯不清,神經錯亂。避免以上慘劇,則要先草繪,再規劃,後動工。草繪,就是畫出 FLOW CHART,根據一列要求去訂出一個個運行次序,如先輸入電話號碼,再檢查連線。若用Wi-Fi 上線,則登入系統,下載音樂。然後,再根據運行次序中的過程、步驟,化為一個個共用的模組(Module),然後再訂出模組(Module)內呼叫函數(Function / Method)的 FLOW CHART。經過一再核對後,就規劃開發流程,根據先後輕重,優先完成重點模組,定下試驗時間(Milestone)和行程表(Schedule Plan),然後動工。以上良方,教開發者清晰知道自己分工和先後次序,依時完成。管理層、客戶、都可以依時檢閱雛形(Prototypes),提供意見。即使中間有偏差,都不會相差太大。

當然, 大學時期所學的 Class Diagram、Sequence Diagram、Use Case Diagram 都可以協助開發者,設計一個良好、耐用、易改良的較件,唯人在江湖,節奏急促,往往只能借極少時間去完成設計。由於 FLOW CHART 直觀易明,編寫員可直 Code 之,所以被不少同行使用。不過,FLOW CHART 本身可任所有人士採用,只是你想完成一件複雜的事。如果你思維不太清晰,不知道哪個細節會出錯,就不妨先繪出一個個 FLOW CHART 出來,供自己和他人去一起討論、檢討、改良。