寫 APPS 都要畫FLOW CHART？（larrylo）

當然要啦。

畫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 出來，供自己和他人去一起討論、檢討、改良。

作者：larrylo（本文章由聚言時報授權提供）