動機有了, 工具選了, 是時候思考想要的目標有幾多. 在思考時要將目標分為幾個類別, 並設定先後次序, 好讓自己不會在漫長的開發過程中迷失了.

思辯
在這階段可以先不想電腦硬體及網絡設備, 因為這些都是金錢可以解決的問題. 要多花時間去細心思考的是如何將日常工作的流程在電腦內重現. 為此, 我有段時間真的自我閉關, 甚至學周伯通以自言自語來跟自己思辯, 只為解決一些在類比世界沒有但卻會在電腦世界發生的邏輯問題. 再一次, 香煙真是好伴侶... (香港政府忠告市民: 吸煙危害健康).

另一個需思考再思考的就是整個系統背後的 Database Schema. Schema 是什麼呢? 它就是讓資料庫管理軟件知道如何儲存你所輸入的資訊, 其關聯性及屬性. 如果以建築大廈作例子, 那 Schema 就是你系統中的建築藍圖. 即是當你設計一個 Schema 時, 你要想像及考慮到整個工作流程及如何達到目標, 換句話說這是 "商業邏輯"!

Point of No Return
再用建築大廈來說明思考在設計 Database Schema 的重要, 因為 Database Schema 是沒有 Trial & Error 的機會, 而 P.N.R. 就在落實 Schema 前的那一刻. 想像一下你在設計一座住宅大廈的時候, 你會為未來的目標住客設計出適合他們生活習慣或品味的間隔, 睡房和廁所的數目, 廚房的位置, 客廳大小, 甚至樓高, 每方尺承重等等不同的屬性. 當藍圖落實後, 工程師及工人就可以開始根據你的藍圖來動工. 突然市場氣氛轉變, 然後老闆跟你說: "啊, 我們要將這大廈轉變為辦公大樓!"

於是你叫停工序, 打開藍圖一一審視可修改之處 (在這裡"關聯式資料庳"再一次跟大廈結構很相似; 就是環環相扣, 是真真正正的 "牽一髮而動全身"). 但是你發現, 如果你修改A, 就必須改B, 而修改B, 就要把C也改掉. 如此類推直到修改最核心的部份為止. 然而當你修改最核心的部份, 就變成整個架構都要修改! 緊記的是, 當你的完成度越高, 要修改的東西就越多.

在分析後你可能發現, 打掉重來可能是邏輯上最合理的辦法, 但往往因為經濟政治等問題而有所不能. 到最後你只能作一些小修小補, 甚至不惜潛建來達到目的. 這樣的成品出來之後不是失敗缺乏效益, 就是成了四不像.

祖師爺
上圖是 Luca Pacioli (1445-1517) 的肖像. 在文藝復興時期這樣的肖像油畫對被繪者來說, 可說是一種非常高的榮譽. Pacioli 被譽為會計之父, 雖然他並非複式簿記的發明人, 但是他是第一個梳理複式簿記的流程, 規則並全面以阿拉伯數字論述其數學思想及出版的人, 因為其關於複式簿記的部份被獨立成書並暢銷歐洲各國, 促使歐洲揮別難於計算的羅馬數字, 擁抱我們現在日常所見的阿拉伯數字. 所以更被現代某些人說他是這個日漸資料化世界的奠基人!

說說題外話, 在 Wikipedia 上的 Database Schema 題目有十一種不同語言版本, 亞洲的有韓文(非常簡短)及日文, 但是沒有中文. 為何會這樣的呢?

http://bickyacc.blogspot.com/2013/09/blog-post_4622.html