也可以用你這個項目做例子。這個項目把所有科目的成績都放在同一張表上,我不看後面的,可以猜測程序實現是指定某個字段是什麽意義的,要“數學卷一成績”,就在代碼中寫SX1,絕大多數人都會這麽做。這是一種需求下的設計,那麽我給你變動一下需求(需求變動是現實中很常見的事),現在學校需要增減一些科目,你可以在腦中想象一下,原先的設計方案,需要改動的地方有哪些?好,你說現在這個客戶未來是不會變動科目的,那麽,如果你是賺外快給多所學校做同樣功能的程序呢?每個學校都會不同的科目設置,你針對這個學校是這樣寫,針對那個學校是那樣寫,到時外快賺多了,有一百來個學校,你這些版本不同的程序都維護得過來嗎?這其實仍然是需求,是你自己方面的需求,你絕對不會願意分別維護這許多大同小異的程序,必定會想當初如果寫個適應性強的版本就好了,在代碼不硬編碼“數學卷一成績”對應SX1,而是另外做一張對應表,衹要在外面修改這張表,就滿足不可知的變動,而呈現出來的界面,是統一的,行爲也是統一的。這麽一來,你的程序實現手段會來個大顛覆,幾乎把原先的系統推倒重來。所謂實踐經驗,是你有沒有碰過這類看似小變動,實質要傷筋動骨的問題,給人寫任何程序,都預防了出現這種情形,那樣才不會搞到自己。這樣的釘子,一定要碰過才知道別人這般告誡的價值,很多學生是聽不進去的,他們覺得現在實現了要求的功能,就是可以的,故從來沒有培養寫程序要應付未來變動可能性的意識。
再說了,原來那表,把總分和分卷分都獨立成字段,彼此地位一樣,但對計算機來説,總分是可以臨時計算出來的,設計獨立字段沒有必要,屬於冗餘數據,分卷分變動,代碼中就得附帶修改總分字段的尾巴,原作者那樣設計表結構,是爲了寫Grid界面時方便,但其實是無形中增加了代碼另外的複雜性,比如要特意設置這個字段是衹讀的、位數也要加大一級等等。如果是我做,我可以在Grid控件任意添加表沒有的欄,不需要在物理表上有這樣的字段。所以,一看到這樣的數據表結構,就知道他的設計思路是什麽,有什麽問題,也能預計它會在什麽時候、什麽地方出現問題。
你不要以爲用向導替你做Grid控件自動設置好字段欄目之類很得意,像這個表設計,SX=SX1+SX2,那是硬編碼,代碼中人腦記住SX對應,一個科是一行,有多少科就多少行,向導不會替你生成哪個字段加哪個字段填到哪個字段,後面要擦屁股的動作多了。我爲什麽一直說那些靠現成工具的人是學不到技能的,就是這個原因,他必然是一丁點小改動也應付不來,因爲他根本就不瞭解原來的怎麽來,現在要怎麽改,當然也不知道了。
[此贴子已经被作者于2015-11-7 12:48编辑过]