|
為了給朋友同事一些設計問題上的指導，特撰寫此文，很多觀點都是從別人的文章中獲取，有些觀點肯定也有偏頗，有些觀點也僅僅是提出并沒有做詳細論述，請多拍磚，以便改正。
【概述】
-------
在工作中，作為一個程序員或者一個設計師，總是要設計一些函數庫或者一個框架，當然最經常的還是做項目，即使是一個項目，也會被經常改動，甚至交給別人改動。
當你做這些工作的時候，你的這些成果都是要給別人了解使用的，或者說給以后的你使用的，為了別人的方便或者為了自己的方便，我們要盡可能做好設計。
【放正心態，任何東西都是不斷發展的】
----------------------------------
技術是日新月異的，每一天都有新的技術出來，正所謂"山外有山，人外有人"，每一個新的輪子出來，都可能比你要設計的輪子好，所以在設計的時候，應該了解一下是否已經有了類似的輪子，是否要設計一個新的輪子。
即使你的輪子已經設計好了，也不好認為自己的輪子一定比別人的輪子好，雖然你的輪子可能更適合你的實際使用。
技術在不斷的發展中，你以及你的朋友/同事都在不斷進步，"士別三日，當刮目相看"，所以不要認為你的水平一定比別人高，"尺有所短，寸有所長"，所以別人對你的函數庫/框架提出意見，提出疑問的時候，請不要驚奇，不要反感，不要認為別人在"挑刺"，也許你的函數庫/框架早就不適合當前的發展了。
態度決定一切。你的領導或許更重視這一點。
【必要的組成部分:單元測試，文檔，實例，手冊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。
借鑒也是一種捷徑。
警告:借鑒但不要抄襲，借鑒代碼要注明來源，尊重他人也是尊重自己。
| 
