本文從Java代碼編寫的初期到結尾，做了一次整體的總結，希望對初學者有幫助。
一個錯誤的命名會很誤導人，不良的命名，對於閱讀代碼的人來說很糾結。一個良好的命名對自己也有很大的幫助。
我個人命名的變量都比較長，一般是單詞的全稱，這樣代碼讀起來易懂，有些縮寫你根本不知道它代表的單詞是什麼，除了像id代表identifier，org代表organization這些大家常見的縮寫命名。
命名一個方法時候，最好能讓大家見名知意，看到名字就能猜出你的功能，而不需要去看方法的註釋，甚至是讀源碼來了解你的功能。
寫一個方法時可以先把這個方法的功能、算法原理交代一下，以後自己或者是其他人維護你的代碼時候可以很方便，對於易出錯的部分加註釋提醒。
小編相信這裏有很多學習java的朋友，小編整理了一份java方面的學習資料，想要獲取的可以加我的java學習羣的喲，928204055。歡迎愛學習Java的你們。
寫方法的時候的參數，少用基本類型的組合，而用class類型
在實際項目開發中改一個接口的成本還是挺大的，實際項目開發中爲了達到層次清晰、解耦的目的，後臺分了好多層，action、business、dao其中dao還有分了dao接口和實現，一個接口修改得牽動多少地方。
而當初設計的接口傳遞的是User對象，那麼你的代碼可以簡單的增加幾行就能達到了目的，而不需要修改那麼多的接口，一邊修改一邊糾結。
同樣的代碼不要粘來粘去，當時寫的時候確實是快了，可是以後需要修改的時候可就慢多了。
更可怕的是你要修改多處，結果你只修改了一處，而你自己卻以爲萬事大吉了，說不定哪天就蹦出個bug來。應該把這些公共的代碼提取成一個class或者是一個方法。
一個方法中寫好多代碼，寫的時候確實是很方便，很快，更好的辦法是把一個大的方法分解成幾個小的方法，然後在主方法中調用其他子方法。
如果把所有的邏輯都寫在一個方法中，當需求發生變化的時候，再要修改那就慢多了。
我自己寫代碼的時候，剛開始寫某個功能的時候很慢，有幾種實現很糾結到底用那種實現，思考半天，給個變量起個名兒也得半天，有時候還不知道對應的英文單詞，好吧，再打開桌面詞典，查查單詞。
寫個方法時也得糾結半天，先想好方法的名字，然後是參數，還有返回值。
一小段邏輯的代碼可以提取出一個private方法，然後在一個方法中調用好幾個私有的小方法。
這樣讀代碼的人讀起來也輕鬆，日後需求發生變化了，你的這些個小的邏輯代碼塊兒只要重新組合下，就又能滿足新的功能，可以複用。
我自己寫一個新功能的時候，第一次寫很慢，如果是這個新功能發生了變化，需要修改代碼，修改起來非常快，許多代碼塊兒都是現成的，只需要重新組合一下方法的調用即可。
增加一個新的功能模塊時最好有個設計文檔，先把方方面面都考慮周全了，設計好了再編碼實現。
如果一開始就有個設計文檔，能把方方面面都考慮周全，實現起來就容易多了，實現的代碼還能優雅些。
爲了達到最終的目的，可能中間要走些彎路，如果增加的功能多了，每次實現都走一些彎路，系統最終會變的臃腫不堪。
如果推倒重來，以前的功夫就都白費了，不光是編碼，還有測試部門的測試，有時時間也不允許重構，再說了重構還有風險，這其中的代價還是挺大的。
所以新增功能一定要把需求搞清除，有個良好的設計文檔，考慮周全了再編碼實現。
最後在向SVN提交代碼時先做個功能測試，然後沒問題了，再做個codereview。