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

2019-11-18 11:49:24

字體：大中小

來源：轉載

供稿：網友

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

上一篇：給JAVA設計開發新手一些建議和意見(2)

下一篇：JAAS基礎