二 面向用戶，纔是關鍵
回首自己兩年多的編程生涯，我感覺除了知識水平的侷限，制約程序員個人發展的一個重要因素，恰恰是“技術至上”。
記得當初給唐山國土資源局開發DigitalLand OA的時候，軟件設計說明書中赫然寫着“本系統採用先進的B/S架構，可大大降低系統的部署成本...使用面向對象的方法開發，對於系統的可維護性和可擴展性...”。
然而，我們捫心自問，OO和B/S對於用戶來說，真的有那麼大的吸引力嗎？還是隻是我們刻意的炒作呢？
給唐山國土資源局作系統實施的時候，我發現很多規劃處的用戶寧可使用中地公司用MapGIS開發的規劃軟件，而不是我們的系統，令我十分困惑。無論是軟件的功能，數據的完整性還是軟件的總體技術水平，我們的系統是絕對不輸MapGIS的，客戶有什麼理由“棄明投暗”呢？規劃處的王處長是這麼說的：
“也許你們系統的技術水平確實比MapGIS高，可是我們還是覺得MapGIS用得順手，你們的系統操作太複雜了...你和我們說的什麼OO，什麼S，什麼數據完整性，我們也不明白，我們用系統，只要好用就行了。”
最後的結果是，我們被迫對系統的界面和操作方式做了若干的改動，系統才勉強得以實施。可是在唐山，包括吉林、東莞和河南項城，還是有N多的用戶對MapGIS的規劃系統和開思的繪圖功能念念不忘，令我們大感困惑——我們，中國技術水平最強的GIS公司（無論是資金，還是人員，我都絕對不是吹牛），競爭對手居然是兩個名不見經傳的公司，真是匪夷所思！
也許這兩個軟件的數據完整性，安全性等方面的確存在一些瑕疵，但瑕不掩玉，系統的操作方式和方便性，確實值得我們學習。例如圖形的外延功能，一座房屋，需要畫出沿房屋輪廓外延2米的圖形，在我們的系統中，需要進行一些複雜的操作才能實現，而在MapGIS中，只需選中房屋的面層，進行一次操作就能完成。
坦率的說，那次的事情對我的觸動很大，剛剛畢業的時候，我總是覺得好的設計，良好的編碼，數據的完整性和系統的安全性，是一個軟件成功的關鍵，這件事情之後，我覺得只有滿足客戶的要求，纔是一個軟件最重要的目標。還是用數據庫設計來舉例吧，我們都知道，數據庫的設計，要求滿足範式，以消除數據的冗餘和不一致性，可是是否完全滿足數據庫範式的系統，纔是好的系統呢？或者說，好的應用系統，是否要滿足所有的數據庫範式呢？答案是否定的。兩年的編程生活告訴我，一個得以順利實施的應用系統，其數據庫設計常常是在一定程度上違反數據庫範式的；而完全依照數據庫範式設計的應用系統，很多恰恰不能順利實施。
難道數據庫範式是沒有意義的嗎？難得大學中所學的數據庫原理課程，都是老學究的空想？
當然也不能走這個極端，一個良好的數據庫設計，常常是以數據庫範式爲基礎，依照系統具體情況，做出適當的讓步。
例如：
方案A：
table:employee
=============================================
name gender nativeplace position
---------------------------------------------
Doe,John 1 1 4
Doe,Jane 0 2 5
blue 1 3 6
table:gender
==================
genderid gender
------------------
0 F
1 M
table:nativeplace
=====================
cityid cityname
---------------------
1 Boston
2 New York
3 Tianjin
table:position
=====================
positionid position
---------------------
4 Saleman
5 CFO
6 SDE
方案B
table:employee
=============================================
name gender nativeplace position
---------------------------------------------
Doe,John M Boston Saleman
Doe,Jane F New York CFO
blue M Tianjin SDE
table:gender
==================
genderid gender
------------------
0 F
1 M
table:nativeplace
=====================
cityid cityname
---------------------
1 Boston
2 New York
3 Tianjin
table:position
=====================
positionid position
---------------------
4 Saleman
5 CFO
6 SDE
以上，就是一個HR系統中僱員表的兩個設計方案。
方案A依照數據庫範式進行設計，將籍貫，職位，性別等信息抽取出來，建立字典表，通過主鍵和僱員表連接。可是你有沒有想過這麼做有什麼缺點嗎？我們的例子中涉及到的字典字段是三個，那麼，如果有十個呢？三十個呢？也許你覺得這根本不可能發生，可是shit may happen！如果依照這個方案設計數據庫，當你需要檢索一個僱員的相關信息時，也許會這麼做:
select emp.name,gender.gender,city.cityname,position.position
from employee as emp,gender as gender,nativeplace as city,position as position
where emp.gender = gender.genderid and emp.nativeplace = city.cityid and emp.position = position.positionid
哇～是不是比較複雜呢？閉上眼睛，想象一下，一共三十個字典表...額滴神啊~
這種方案不只實現複雜，在實際運行的時候，還可能造成系統服務器的巨大開銷。
okay，我們再來看看第二種方案，那邊的兄弟說了，你這個東東好像不符合數據庫3NF哦，這個...不錯，不過請聽我慢慢道來。
我們設計字典表的目的是什麼？爲了防止數據的不一致，否則employee的position字段中，SDE也是軟件開發工程師，或者你也可以寫全稱software developing engineer，明明是一個含義，統計的時候卻會有兩條記錄。可是，維護數據的唯一性，是不是隻能通過插入外鍵呢。我們換一個方法，我們在程序的窗體上放一個combobox，將dropdownstyle設置爲dropdownlist，在窗體加載的時候，對combobox中的內容進行動態綁定，這樣不是也能控制客戶輸入有效的數據嗎？區別只是在插入數據和更改數據的時候，是傳入combobox的SelectedIndex還是SelectedValue的問題。至於取得一個僱員的信息:
select * from employee
爽吧？呵呵，不只是寫着過癮，運行速度也絕對比方案A快很多。且對於數據的查看次數大大多於插入和更改的次數的情況，尤爲有效。
並不是所有的客戶都知道OO，B/S，數據庫範式是什麼東東，系統的界面漂亮，功能好用，運行速度快捷，確實客戶可以切實感受到的。