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

作者：飛雲小俠    來自：CSDN

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

　　【概述】

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

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

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

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

　　技術在不斷的發展中，你以及你的朋友/同事都在不斷進步，"士別三日，當刮目相看"，所以不要認為你的水平一定比別人高，"尺有所短，寸有所長"，所以別人對你的函數庫/架構提出意見，提出疑問的時候，請不要驚奇，不要反感，不要認為別人在"挑刺"，也許你的函數庫/架構早就不適合當前的發展了。
　　
　　態度決定一切。你的領導或許更重視這一點。
　　
　　【必要的組成部分:單元測試，文檔，執行個體，手冊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)
　　
　　作為一個技術人員，嚴謹應該是我們的習慣之一，無論做開發還是做設計。