Java程式員應該遵循的10條戒律

<a href="http://soft.chinabyte.com/database/459/12317459.shtml">http://soft.chinabyte.com/database/459/12317459.shtml</a>

Java程式員有許多應遵循的守則或最佳實踐方式。本文概述了每個開發者最應該遵循的10條守則或戒律，如果不遵循它們，将會導緻災難性後果。

　　1. 為代碼添加注釋(Add comments to your code)。 – 每個人都知道這一點，但不是每個人都會這麼做。你有多少次“忘記”添加注釋了？确實，注釋不會為你的程式增加任何函數功能。但是，有多少次，看到2周前寫的代碼，你都記不起它是幹什麼的？你很幸運，那些未注釋的代碼是你自己寫的，你腦海中還會有殘存的印象。非常不幸，大多時候，代碼是别人寫的，并且那個人很可能已經離開公司了。有句諺語說的好：“有來有往，互惠互利”，是以程式員應該體諒彼此(還有你自己)，給你的代碼加上注釋。

　　3. 記住 - “越少越好”并非總是如此(Keep in Mind – "Less is more" is not always better)。 – 高效率的代碼是件好事，但很多情況下，并非代碼行數越少效率就越高。看下面這個“簡單”的例子：

　　if(newStatusCode.equals("SD") &amp;&amp; (sellOffDate == null || todayDate.compareTo(sellOffDate)&lt;0 || (lastUsedDate != null &amp;&amp; todayDate.compareTo(lastUsedDate)&gt;0)) ||(newStatusCode.equals("OBS") &amp;&amp; (OBSDate == null || todayDate.compareTo(OBSDate)&lt;0))){ newStatusCode = "NYP"; }

　　指出這個if條件是什麼有多困難？再設想一下，寫這段代碼的人并沒遵循第1條 - 為代碼添加注釋。

　　if(newStatusCode.equals("SD") &amp;&amp; (sellOffDate == null || todayDate.compareTo(sellOffDate)&lt;0 || (lastUsedDate != null &amp;&amp; todayDate.compareTo(lastUsedDate)&gt;0))){ newStatusCode = "NYP"; }else if(newStatusCode.equals("OBS") &amp;&amp; (OBSDate == null || todayDate.compareTo(OBSDate)&lt;0)) { newStatusCode = "NYP"; }

　　這樣可讀性不是更好嗎？的确，我們寫了重複語句;的确，我們多寫了一個if和2個大括号;但是代碼确實更加易讀、更加容易了解了!

　　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; } }

　　現在，每次需要比較字元串“ABC”與某個變量的時候，我們隻要引用 A.S_CONSTANT_ABC 即可，而不必記住它本身是什麼。對這個常量的修改也非常友善，改一個地方即可，而不必在全部代碼中查找。

　　6. 對Print行或字元串說不(Say no to Print lines and String Concatenations)。 – 我知道為了調試友善，程式員喜歡到處用System.out.println ,然後對自己說過一會就删掉。但我們常常忘記删掉這些行或不願删掉，我們用System.out.println 做測試，為什麼測完後還要去改代碼？這很可能導緻誤删一行我們需要的代碼。不要低估System.out.println 的危害，看下面代碼：

　　public class BadCode { public static void calculationWithPrint(){ double someValue = 0D; for (int i = 0; i &lt; 10000; i++) { System.out.println(someValue = someValue + i); } } public static void calculationWithOutPrint(){ double someValue = 0D; for (int i = 0; i &lt; 10000; i++) { someValue = someValue + i; } } public static void main(String [] n) { BadCode.calculationWithPrint(); BadCode.calculationWithOutPrint(); } }

　　下面表格可以看出，calculationWithOutPrint() 方法執行時間是0.001204 s. 作為對比，calculationWithPrint() 方法居然需要令人難以置信的10.52 s來執行!

　　(若你想知道怎麼做一個這樣的表，請閱讀另一篇文章"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; i &lt; 10000; i++) { someValue = someValue + i; myPrintMethod(logMode, someValue); } } public static void myPrintMethod(int logMode, double value) { if (logMode &gt; BadCode.DEBUG_MODE) { return; } System.out.println(value); } public static void main(String [] n) { BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE); } }

　　字元串(String)連接配接是另一種CPU浪費方式，看下面的例子：

　　public static void concatenateStrings(String startingString) { for (int i = 0; i &lt; 20; i++) { startingString = startingString + startingString; } } public static void concatenateStringsUsingStringBuffer( String startingString) { StringBuffer sb = new StringBuffer(); sb.append(startingString); for (int i = 0; i &lt; 20; i++) { sb.append(sb.toString()); } }

　　從下面表格可以看出使用 StringBuffer隻要花 0.01 s 而使用String 連接配接需要0.08 s，選擇哪種應該很明顯了。

　　不要重新發明輪子。去看那些類似應用系統的界面。

　　首先建立一個原型。這一步非常關鍵。客戶喜歡提前看到他們要用的東西。同樣你可以得到他們的回報，而不是你辛辛苦苦做出來一個客戶不喜歡的東西。

　　試戴使用者的帽子。換句話說，站在使用者的角度檢視需求。譬如，一個統計的界面可以分頁，也可以不分頁。作為開發者，很可能會忽略分頁，因為這會減少很多麻煩;而站在客戶角度，這就不是一個好的方案，因為資料可能多達幾百行。

　　8. 提前準備需求文檔(Always Prepare Document Requirements)。 – 每項業務需求都記入文檔。這在童話故事中可能實作，而現實中很難做到。無論時間多麼緊迫，無論截止日期如何迫近，你必須確定業務需求被記錄下來。(譯注：這條明顯悖于靈活開發的觀念，大家要獨立思考，甄别是非)

　　9. 單元測試，單元測試，單元測試 (Unit-test. Unit-test. Unit-test)。 – 我不準備讨論如何單元測試的細節，我隻是想說這必須要做。這是程式設計中最基本的規則了，尤其不能忽略。如果你同僚能為你的代碼建立一個測試計劃，那就再好不過了;如果不能，那就要自己做。做單元測試計劃時，遵循下面原則：

　　編碼前就寫單元測試

　　保留單元測試的注釋

　　對任何“有趣的”公共方法都要做單元測試(“有趣的”是指除了像最常見的getter/setter這類方法外的方法，但包含有自己内容的getter/setter 方法)

　　10. 記住：品質，而非數量(Remember – quality, not quantity)。 - 不要待的太晚(除非有必要)。我知道有時因為産品問題，截止期限或其他突發事件，不能按時下班。但經理不會因為你為一般問題待的太晚而感激或獎勵你;他們會為有品質的工作而感激你。如果你遵循上面的列的原則，你就會寫更健壯的、少bug的程式。這才是你最應該做的。

　　結論

　　本文中總結了Java程式員最應注意的10項守則。僅僅知道是不夠的，還要遵循它們。希望這些守則能讓我們做更加專業的程式員。

　　不是每個人都能成為高手，但是不努力，就算有再高的天分，也白癡一個!