scud(飛雲小俠) 2005-7-23 http://www.jscud.com 轉載請註明作者
爲了給朋友同事一些設計問題上的指導,特撰寫此文,很多觀點都是從別人的文章中獲取,有些觀點肯定也有偏頗,有些觀點也僅僅是提出並沒有做詳細論述,請多拍磚,以便改正.
【概述】
-------
在工作中,作爲一個程序員或者一個設計師,總是要設計一些函數庫或者一個框架,當然最經常的還是做項目,即使是一個項目,也會被經常改動,甚至交給別人改動.
當你做這些工作的時候,你的這些成果都是要給別人瞭解使用的,或者說給以後的你使用的,爲了別人的方便或者爲了自己的方便,我們要儘可能做好設計.
【放正心態,任何東西都是不斷髮展的】
----------------------------------
技術是日新月異的,每一天都有新的技術出來,正所謂"山外有山,人外有人",每一個新的輪子出來,都可能比你要設計的輪子好,所以在設計的時候,應該瞭解一下是否已經有了類似的輪子,是否要設計一個新的輪子.
即使你的輪子已經設計好了,也不好認爲自己的輪子一定比別人的輪子好,雖然你的輪子可能更適合你的實際使用.
技術在不斷的發展中,你以及你的朋友/同事都在不斷進步,"士別三日,當刮目相看",所以不要認爲你的水平一定比別人高,"尺有所短,寸有所長",所以別人對你的函數庫/框架提出意見,提出疑問的時候,請不要驚奇,不要反感,不要認爲別人在"挑刺",也許你的函數庫/框架早就不適合當前的發展了.
態度決定一切.你的領導或許更重視這一點.
【必要的組成部分:單元測試,文檔,實例,手冊etc】
--------------------------------------------
單元測試,文檔,API Doc,手冊,演示程序,Change Log,Readme,build.xml等等
有一天別人使用了你設計的函數庫/框架,當你升級後,原來的項目卻不能工作了,經過一天的調試,你終於找到了原因,原來是不小心寫錯了一個東西.
你肯定不希望上述的事情發生,那麼請你寫單元測試吧,這樣既不浪費自己的時間,也不耽誤別人的工作,何樂而不爲.你花在寫單元測試的時間/帶來的樂趣和你升級後改正莫名其妙的錯誤的時間和苦惱相比,肯定更有價值.你看到單元測試的綠條,難道不感到高興嗎?!
如果你不能保證你的程序修改沒有錯誤,不要指望你的同事認爲你的錯誤是可以容忍的,他們在心裏早就開始罵你了,呵呵.寫單元測試吧
看看任何一個知名的框架,都包含完善的文檔,單元測試,示例程序,用戶手冊,那麼請你也包含這些吧.哦,對了,請詳細地寫好JavaDoc,它很重要.
使用你的框架/函數庫的人如果到處去找使用方法,去找某個類(但是他不知道是否有這個類),那麼說明你的文檔沒有到位.如果你希望別人使用你的這個類或者功能,那麼請寫好文檔,不要指望別人去讀你的源碼然後就能理解它是幹什麼用的.
如果你做到這些,那麼你的函數庫/框架也有了"知名"的前提,難道不是嗎?如果沒有,我想是沒法讓別人更好地使用的.
對了,有了這些東西,還要有一個良好的目錄組織,這個也可以參考別的框架的組織方式.
【借鑑成熟的設計,參考已有的項目】
--------------------------------
1.要做一個新的東西,沒有想法.不要驚訝,我肯定先找一個現有的東西來借鑑.
當然前提是不要重新發明輪子,或者是你有充分條件要重新發明一個輪子.
Struts,WebWork,Spring等等都是成熟的框架,不管你使用起來是否符合你的習慣.
在你成爲大師之前,你的設計思想估計前人都已經提出並實踐過了,所以要勇敢地去借鑑."站在巨人的肩膀上"我們能更近一步.
例如我們厭倦了在訪問數據庫時使用如下的代碼:
| try { //your code here } catch(Exception e) { //catch Exception } finally { //must do something } |
我們就可以借鑑Spring框架的JdbcTemplate類,看看它是如何利用回調函數來處理的.
我們使用hibernate時是不是也會使用類似上面的代碼,那麼可以參考Spring框架的HibernateTemplate.
借鑑也是一種捷徑.
警告:借鑑但不要抄襲,借鑑代碼要註明來源,尊重他人也是尊重自己.
2.在實際的項目中,往往可以參考已經有的項目來做自己的設計.
例如做一個網站,我不知道如何訪問數據庫,如何佈局,如何分層,那麼我們可以參考已經有的網站程序,看看別人是如何利用SiteMesh或者tiles佈局,如何使用Hibernate來訪問數據庫或者使用已經封裝好的JDBC類來訪問數據庫,如何利用Struts,WebWork或者其他訪問來分層.
【遵守約定俗成的一些做法】
-------------------------
爲了使別人更方便地使用你的東西,那麼在設計一些通用的函數或者類的時候,請遵守通用的做法,不要與衆不同,除非你的內部實現確實與衆不同.
例如實現一個類似ArrayList的類,那麼請不要這樣寫:
| public int count() { return list.size(); } public Item getItem(int i) { return list.get(i); } |
而應該這樣:
| public int size() { return list.size(); } public Item get(int i) { return list.get(i); } |
當然每個人都有自己的想法,如果你非常認爲你原來的方式比普通的好,那麼請提供2套方式供別人選擇.它不會給你帶來麻煩,只是一個一看就懂的做法,不用懷疑,這樣做有好處.
很多類的設計都有一些約定俗成的做法,那麼在你設計一個新類的時候,先借鑑一下吧,多看看JDK的源碼/文檔,看看別人是怎麼實現的.這更有助於推廣你的成果.
【不要迷信權威】
---------------
在使用已有的框架或者函數庫時,不要認爲所有的東西都是正確的或者是最好的最好,肯定不是.沒有完美的東西,已經存在的東西在設計的時候因爲種種侷限或者因爲作者的水平,對現在來說肯定存在不合理的設計,或者過於理想化的設計,而不能滿足實際情況.
不迷信權威,才能到達新的境界.
【不要輕易排斥,不瞭解就不要草率發表意見,要嚴謹】
------------------------------------------------
在網上經常看到.Net和Java的比較/火拼,或者是Struts VS Webwork或者是其他等等,非常之多.經常看到的是一方對對方的東西不甚瞭解,就開始批評,結果說不到點子上,反而被嘲笑一番.
幾種技術的比較有時候是必要的,例如技術選型的時候.但是如果一些對這些技術根本不瞭解的人來選型,來評判,你能對結果信服嗎?
存在就是合理,任何技術都有其存在的理由,雖然有些東西早就過時了,但是在當時它也是應運而生的.
幾種技術,都是來解決同樣的問題,但是問題也有很多方面,解決方式也有很多種,每個人的想法也都不一樣,思路也不一樣,所以沒有絕對符合要求的技術,但是應該有符合你的技術,不符合你的技術不等於也不滿足別人的要求.所以不要輕易排斥別的東西.
在做技術比較的時候,如果你不瞭解,那麼請不要輕易發表意見,至少你可以親自去了解,去實踐之後在發表你的意見豈不是更好.
在發表意見的時候,也要嚴謹,不要輕易下結論,要經過求證,否則一旦錯誤只會讓對手笑話,讓你的同事看不起你.例如你說Hibernate3不支持jdk1.3,那麼最好去好好找到你的證據,否則就會成爲錯誤.(Hibernate3支持jdk1.3)
作爲一個技術人員,嚴謹應該是我們的習慣之一,無論做開發還是做設計.