本文從Java程式碼編寫的初期到結尾，做了一次整體的總結，希望對初學者有幫助。

一個錯誤的命名會很誤導人，不良的命名，對於閱讀程式碼的人來說很糾結。一個良好的命名對自己也有很大的幫助。

我個人命名的變數都比較長，一般是單詞的全稱，這樣程式碼讀起來易懂，有些縮寫你根本不知道它代表的單詞是什麼，除了像id代表identifier，org代表organization這些大家常見的縮寫命名。

命名一個方法時候，最好能讓大家見名知意，看到名字就能猜出你的功能，而不需要去看方法的註釋，甚至是讀原始碼來了解你的功能。

寫一個方法時可以先把這個方法的功能、演算法原理交代一下，以後自己或者是其他人維護你的程式碼時候可以很方便，對於易出錯的部分加註釋提醒。

小編相信這裡有很多學習java的朋友，小編整理了一份java方面的學習資料，想要獲取的可以加我的java學習群的喲，928204055。歡迎愛學習Java的你們。

寫方法的時候的引數，少用基本型別的組合，而用class型別

在實際專案開發中改一個介面的成本還是挺大的，實際專案開發中為了達到層次清晰、解耦的目的，後臺分了好多層，action、business、dao其中dao還有分了dao介面和實現，一個介面修改得牽動多少地方。

而當初設計的介面傳遞的是User物件，那麼你的程式碼可以簡單的增加幾行就能達到了目的，而不需要修改那麼多的介面，一邊修改一邊糾結。

同樣的程式碼不要粘來粘去，當時寫的時候確實是快了，可是以後需要修改的時候可就慢多了。

更可怕的是你要修改多處，結果你只修改了一處，而你自己卻以為萬事大吉了，說不定哪天就蹦出個bug來。應該把這些公共的程式碼提取成一個class或者是一個方法。

一個方法中寫好多程式碼，寫的時候確實是很方便，很快，更好的辦法是把一個大的方法分解成幾個小的方法，然後在主方法中呼叫其他子方法。

如果把所有的邏輯都寫在一個方法中，當需求發生變化的時候，再要修改那就慢多了。

我自己寫程式碼的時候，剛開始寫某個功能的時候很慢，有幾種實現很糾結到底用那種實現，思考半天，給個變數起個名兒也得半天，有時候還不知道對應的英文單詞，好吧，再開啟桌面詞典，查查單詞。

寫個方法時也得糾結半天，先想好方法的名字，然後是引數，還有返回值。

一小段邏輯的程式碼可以提取出一個private方法，然後在一個方法中呼叫好幾個私有的小方法。

這樣讀程式碼的人讀起來也輕鬆，日後需求發生變化了，你的這些個小的邏輯程式碼塊兒只要重新組合下，就又能滿足新的功能，可以複用。

我自己寫一個新功能的時候，第一次寫很慢，如果是這個新功能發生了變化，需要修改程式碼，修改起來非常快，許多程式碼塊兒都是現成的，只需要重新組合一下方法的呼叫即可。

增加一個新的功能模組時最好有個設計文件，先把方方面面都考慮周全了，設計好了再編碼實現。

如果一開始就有個設計文件，能把方方面面都考慮周全，實現起來就容易多了，實現的程式碼還能優雅些。

為了達到最終的目的，可能中間要走些彎路，如果增加的功能多了，每次實現都走一些彎路，系統最終會變的臃腫不堪。

如果推倒重來，以前的功夫就都白費了，不光是編碼，還有測試部門的測試，有時時間也不允許重構，再說了重構還有風險，這其中的代價還是挺大的。

所以新增功能一定要把需求搞清除，有個良好的設計文件，考慮周全了再編碼實現。

最後在向SVN提交程式碼時先做個功能測試，然後沒問題了，再做個codereview。