為了給朋友同事一些設計問題上的指導，特撰寫此文，很多觀點都是從別人的文章中獲取，有些觀點肯定也有偏頗，有些觀點也僅僅是提出并沒有做詳細論述，請多拍磚，以便改正。

　　【概述】
　　-------
　　在工作中，作為一個程序員或者一個設計師，總是要設計一些函數庫或者一個框架，當然最經常的還是做項目，即使是一個項目，也會被經常改動，甚至交給別人改動。
　　當你做這些工作的時候，你的這些成果都是要給別人了解使用的，或者說給以后的你使用的，為了別人的方便或者為了自己的方便，我們要盡可能做好設計。
　　

　　【放正心態，任何東西都是不斷發展的】
　　----------------------------------

　　技術是日新月異的，每一天都有新的技術出來，正所謂"山外有山，人外有人"，每一個新的輪子出來，都可能比你要設計的輪子好，所以在設計的時候，應該了解一下是否已經有了類似的輪子，是否要設計一個新的輪子。

　　即使你的輪子已經設計好了，也不好認為自己的輪子一定比別人的輪子好，雖然你的輪子可能更適合你的實際使用。

　　技術在不斷的發展中，你以及你的朋友/同事都在不斷進步，"士別三日，當刮目相看"，所以不要認為你的水平一定比別人高，"尺有所短，寸有所長"，所以別人對你的函數庫/框架提出意見，提出疑問的時候，請不要驚奇，不要反感，不要認為別人在"挑刺"，也許你的函數庫/框架早就不適合當前的發展了。
　　
　　
　　態度決定一切。你的領導或許更重視這一點。
　　
　　
　　【必要的組成部分:單元測試，文檔，實例，手冊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。
　　
　　借鑒也是一種捷徑。
　　
　　警告:借鑒但不要抄襲，借鑒代碼要注明來源，尊重他人也是尊重自己。