本文講述了Java開發人員需知的十大戒律。分享給大家參考，具體如下：
身為一個Java開發人員提升自己程式碼的質量，可維護性，是個恆久不變的話題，網路上看到這篇文章，拿來自勉。
對Java開發者來說，有許多的標準和最佳實踐。本文列舉了每一個開發人員必須遵從的十大基本法則；如果有了可以遵從的規則而不遵從，那麼將導致的是十分悲慘的結局。
1． 在你的程式碼裡加入註釋
每個人都知道這一點，但不知何故忘記了遵守。算一算有多少次你「忘記」了添加註解？這是事實：註釋對程式在功能上沒有實質的貢獻。但是，你需要一次又一次的回到你兩個禮拜之前寫的代碼上來，可能一輩子都是這樣，你一定記不住這些代碼為什麼會這樣。如果這些代碼是你的，你還比較的幸運。因為它有可能讓你回憶起。但是不幸的是，很多時間，這些代碼是別人的，而且很有可能他已經離開公司了。
2． 不要讓事情複雜化
我以前就這麼幹過，而且我相信所有的人都這麼幹過。開發人員常常為一個簡單的問題而提出一個解決方案。我們為僅僅只有5個用戶的應用程式而引入EJBs。我們為一個應用程式使用框架而它根本不需要。我們加入屬性文件，物件導向的解決方案，和線程到應用程式中，但是它根本不需要這些。為什麼我們要這樣做？我們中的一些人是因為不知道怎麼做更好，但是還有一些人這樣做的目的是為了學習新的知識，從而使得這個應用對於我們自己來說做得比較有趣。
3． 牢牢記住――「少即是多（less is more）」並不永遠是好的
程式碼的效率是一偉大的事情，但是在很多情況下，寫更少的程式碼行並不能提高該程式碼的效率。請讓我向你展示一個簡單的例子。
if(newStatusCode.equals("SD") && (sellOffDate == null || todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null && todayDate.compareTo(lastUsedDate)>00)) ("OBS") && (OBSDate == null || todayDate.compareTo(OBSDate)<0))){ newStatusCode = "NYP";}我想問一句：說出上面的那段程式碼的if條件想做什麼容易嗎？現在，我們再來假設無論是誰寫出這段程式碼，而沒有遵從第一條規則――在你的程式碼裡加入註解。
如果我們把這個條件分到兩個獨立的if陳述句中，難道不是比較簡單嗎？現在，考慮下面的修正程式碼：
if(newStatusCode.equals("SD") && (sellOffDate == null || todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null && todayDate.compareTo(lastUsedDate)>0))){ StatPStatusCode = "NYPStatus)>0) ";}else if(newStatusCode.equals("OBS") && (OBSDate == null || todayDate.compareTo(OBSDate)<0)){ newStatusCode = "NYP";}難道它不是有了更好的可讀性？是的，我們重複了陳述條件。是的，我們多出了一個多餘的「IF」和兩對多餘的括弧。但是程式碼有了更好的可讀性和可理解性。
4． 請不要有硬代碼
開發人員常常有意識的忘記或忽略這條規則，原因是我們，和一般時候一樣，在趕時間。如果我們遵守這條規則，我們可能會趕不上進度。我們可能無法結束我們的當前狀態。但是寫一條額外的定義靜態常數的程式碼行又能花費我們多少時間呢？
這裡有一個例子。
public class A { public static final String S_CONSTANT_ABC = "ABC"; public boolean methodA(String sParam1){ if(A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){ return true; } return false; } return false; }}現在，每次我們需要和某一些變數比較字串「ABC」的時候，我們只需要引用S_CONSTANT_ABC，而不是記住實際的程式碼是什麼。它還有一個好處是：更容易在一個地方修改常數，而不是在所有的程式碼中尋找這個程式碼。
5． 不要發明自己的frameworks
已經推出了數千種frameworks，而且它們中的大多數是開源的。這些frameworks中間有許多是極佳的解決方案，被應用到成千上萬的應用中。你們需要跟上這些新frameworks的步伐，最起碼是膚淺的。在這些極好的、應用廣泛的frameworks中間，一個最好的、最直接的例子是Struts。在你所能想像的frameworks中，這個開源的web frameworks對於基於web的應用是一個完美的候選者。但是你必須記住第二條規則――不要讓事情變得複雜。如果你開發的應用程式只有三個頁面―請，不要使用Struts，對於這樣一個應用，沒有什麼「控制」請求的。
6． 不要列印行和字串相加
我知道，為了調試的目的，開發人員喜歡在每一個我們認為適合的地方添加System.out.println，而且我們會對我們自己說，會在以後刪掉這些程式碼的。但是我們常常忘掉刪除這些程式碼行，或者我們根本就不想刪掉它們。我們使用System.out.println來測試，當我們測試完成以後，為什麼我們還能接觸到它們呢？我們可能會刪掉一行我們實際需要的程式碼，只是因為你低估了System.out.println所帶來的傷害，考慮下面的程式碼：
public class BadCode { public static void calculationWithPrint(){ double someValue = 0D; for (int i = 0; i < 10000; i++) { System.out.println(someValue = someValue + i); } } public static void calculationWithOut( ){ double someValue = 0D; for (int i = 0; i < 10000; i++) { someValue = someValue + i; } } public static void main(String [] n) { BadCode.calculationWithPrint(); BadCode.calculationWithOutPrint(); }}在下面的表格中，你能夠看到calculationWithOutPrint()方法的運作花了0.001204秒。相比較而言，運行calculationWithPrint()方法花了令人驚訝的10.52秒。
（如果你不知道怎麼得到一個像這樣的表格，請參閱我的文章“Java Profiling with WSAD” Java Profiling with WSAD）
避免這樣一個CPU浪費的最好方法是引入一個包裝器方法，就像下面這樣
public class BadCode { public static final int DEBUG_MODE = 1; public static final int PRODUCTION_MODE = 2; public static void calculationWithPrint(int logMode){ double someValue = 0D; for(int i = 0; someValue + i; myPrintMethod(logMode, someValue); } } public static void myPrintMethod(int logMode, double value) { if (logMode > BadCode.DEBUG_MODE) { return; } System.out.println(value); } public static void main(String [ ] n) { BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE); }}在下面的圖中，你將看到，使用了StringBuffer的那個方法只花了0.01秒來執行，而那個使用了字串相加的方法卻花了0.08秒來運行。選擇是顯而易見的。
7． 關注GUI
不管這聽起來有多可笑，我都要再三地說明：GUI對於商業客戶來說和功能和性能一樣重要。 GUI是一個成功的系統的必要的一部分。 （但是），IT雜誌常常傾向於忽略GUI的重要性。許多機構為了省錢而不僱用那些在設計「用戶友好」GUI方面有豐富經驗的設計人員。 Java開發人員不得不依賴他們自己的HTML知識，但是他們在這方面的知識十分有限。我看到很多這樣的應用：它們是“計算機友好”，而不是“用戶友好”我很少很少能看到有開發人員既精通軟體開發，又精通GUI開發。如果你是那個不幸的開發人員，被指派去開髮用戶接口，你應該遵從以下的三個原則：
一、不要重複發明輪子。尋找有相似使用者介面需求的已經存在的系統。
二、首先創建一個原型。這是非常重要的步驟。客戶喜歡看看他們將要得到什麼。這對你來說也是很好的，因為在你全力以赴而做出一個將要讓用戶生氣的用戶介面之前，你就得到了它們的回饋。
三、戴用戶的帽子。換句話說，站在使用者的視角檢查應用的需求。例如，一個總結頁面到底要不要分頁。作為一個軟體開發者，你傾向於在一個系統中忽略分頁，因為這使得你有比較少的開發複雜性。但是，這對於從一個使用者的視角來說卻不是最好的解決方案，因為小結的資料將會有數百個資料行。
8． 永遠準備好文件化的需求
每一個業務需求都必須文件化。這可能在一些童話故事裡才能成真，但在現實世界卻不可能。不管時間對你的開發來說是多麼緊迫，也不管交貨日期馬上就要到來，你永遠都必須清楚，每一個業務需求是文檔化的。
9． 單元測試、單元測試、單元測試
我將不會深入地討論哪些什麼是把你的程式碼進行單元測試的最佳方法的細節問題。我將要說的是單元測試必須要做。這是程式設計的最基本的法則。這是上面所有法則中最不能被忽略的一個。如果你的同事能為你的程式碼建立和測試單元測試，這是最好不過的事。但是如果沒有人為你做這些事，那你就必須自己做。在創建你的單元測試計劃的時候，請遵循下面的這些規則：
一、在寫程式碼之前就寫單元測試用例。
二、在單元測試裡寫註解。
三、測試一切執行「interesting」功能的公有方法（「interesting」的意思是非setters或getters方法，除非它們透過一種特殊的方式執行set和get方法）。
10． 記住―質量，而不是數量。
不要在辦公室待得太晚（當你不必待的太晚的時候）。我理解有時，產品的問題、緊迫的最終期限、意想不到的事件都會阻止我們準時下班。但是，在正常情況下，經理是不會賞識和獎賞那些下班太晚的員工的，他賞識他們是因為他們所做產品的品質。如果你遵從了我上面給的那些規則，你將會發現你的程式碼更加少的bug，更加多的可維護性。而這才是你的工作最重要的部分。
總結
在這篇文章裡，我給了針對Java開發人員的十個重要的規則。重要的不僅是知道這些規則，在編碼的過程中遵守這些規則更為重要。希望這些規則能幫助我們成為更好的程式設計人員和專業人員。
希望本文所述對大家Java程式設計有幫助。