巨群資訊

網頁設計 師面臨的最痛苦之事，莫過於修改舊程式碼；如果還有比這更痛苦的，就是修改糟糕透頂，亂得一團糟的爛程式碼。最近因為手底下一幫網頁設計師都在忙，市場部 正好又回饋過來一個要命的bug，一時手癢，就領下了這個任務。我們這個產品是針對教育行業的，它是在好幾年前開發，然後不斷完善和維護。這些階段都是在 我來到這家公司之前完成的。所以，我對於產品的程式碼並不熟悉。

原來的需求是假定客戶設置分數段時，不同的分數段有不同的有效分，對應著也就有不同的名次。這些資料都是經過分析器分析獲得，並持久化到資料庫中。 當我們需要生成學生報告時，再從資料庫中獲取，並將資料填充到iReport設置好的範本中，一個是二維表，一個是柱狀和曲線圖。

現在，我們發現某些學校需要給不同的分數段設置完全相同的有效分，以及相同的名次。報告列印出來，二維表沒有錯，曲線圖卻出現了“缺斤少兩”的現象。例如設置五個分數段，卻可能只顯示了四條曲線。

閱讀程式碼，我明白了原因。在原來的實現中，由於預設不同分數段有不同名次，因此，在獲取這些分數段的值時，是將它們放入到一個HTML中。例如這 個Input標籤是根據科目進行分類的，子Input標籤的Type值為Text類型，其實就是分數段對應的名次，value則是設置的有效分。由於現在 的名次存在重複，導致Input標籤中的元素存在偏差。這就是五個分數段只顯示四條曲線的緣由。

事實上，在我看到這樣的Input標籤時，就明白這種“超級強大”的容器，事實上往往會成為壞程式碼的泥沼。當我們將這樣的物件作為參數，在方法之間傳來傳去的時候，會帶來諸多問題：

1）性能影響。這種可能比較龐大的容器物件，有可能會形成性能瓶頸；

2）強類型。雖然這裏使用了泛型，但泛型類型卻使用了基本類型；

3）封裝性不夠好。這樣的容器物件暴露了太多的資料細節，且不利於為其定義職責行為。

4）可讀性差。看到這樣的Input標籤，你並不會在第一時間明白它到底存放了什麼。

5）可擴展性差：當這個Input標籤作為方法的參數時，相當於這個參數沒有被物件化。如果擁有這個參數的方法被公開，且廣泛調用，一旦需要改變參數，牽連到的程式碼就會非常多。

事實正是如此。當我在分析我們的遺留程式碼時，發現很多地方都在重複獲取這個Input標籤物件，並且這個Input標籤物件也在多個方法之間傳遞。因為 這種容器物件自身的缺陷，為我的bug修復帶來了很多阻礙。要解決這個Bug，就不能再將名次作為Input標籤的key值。查看相關的資料表，事實上我 們還給出了一個分數段的名稱。當名次和有效分存在重複的情況下，結合分數段名稱就能確定唯一值。因此，一個簡單地做法就是將Input標籤的Type修改 為名次加名稱的組合，即將Text修改為Button。

現在，我需要決策。如果希望一勞永逸，就應該摒棄這種Input標籤的做法。我們應該利用封裝來實現這一目標。通過這樣的封裝，問題會變得簡單許多。

轉貼文章：網頁設計知識分享

http://www.piece2ec.com.tw/news.asp?ID=1889

參考文獻：

1.戴軒廷、馬恆、張紹勳 (2004), 衡量 網路廣告 態度之指標建構, 台灣管理學刊, 4(1), 59-84.

2.李青蓉等編著.(1998).人機介面設計，台北縣：空大。

3.邱柏清.(2004).網頁介面愉悅行之研究，國立台灣科技大學設計研究所碩士論文。