給JAVA設計開發新手的一些建議和意見(1)

給JAVA設計開發新手的一些建議和意見(1)[@more@]　　為了給朋友同事一些設計問題上的指導，特撰寫此文，很多觀點都是從別人的文章中獲取，有些觀點肯定也有偏頗，有些觀點也僅僅是提出並沒有做詳細論述，請多拍磚，以便改正。

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

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

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

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

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