Java開發者的十大戒律(轉）

 有許多標準和實踐準則可適用於Java開發者，但此處要說的，是每個Java開發者需堅守的基本原則。

　　一、為程式碼加註釋。雖然每個人都知道這點，但有時卻不自覺忘了履行，今天你“忘了”加註釋了嗎?雖然註釋對 程式的功能沒什麼“貢獻”，但過一段時間，比如說兩星期之後或者更長，回過頭來看看自己的程式碼，說不定已經記不住它是幹什麼的了。如果這些程式碼是你個人 的，那還算是走運了，不幸的是，當然了，大多數時候都是別人的不幸，很多時候大家都是在為公司寫程式碼，寫程式碼的人也許早已經離開了公司，但別忘了一句古 話，有來有往嘛，為他人，也為我們自己，請為你的程式碼加上註釋。

　　二、不要讓事情複雜化。程式設計師有時候總是對簡單問題想出複雜的解決方案，比如說，在只有五個使用者的程式中引 入EJB、對程式實現了並不需要的框架(framework)， 之類的還有屬性檔案、物件導向解決方案、多執行緒等等。為什麼要這樣做呢?也許我們並不知道 是否這樣會更好，但這樣做也許可以學到一些新東西，或者讓自己更感興趣一些。如果是不知道為什麼這樣做，建議多請教經驗豐富的程式設計師，如果是為了個人的目 的，麻煩讓自己更專業一點。

　　三、始終牢記——“少即是好(Less is more)並不總是對的”。程式碼效率雖然很重要，但在許多解決方案中，編寫更少的程式碼並不能改善這些程式碼的效率，請看下面這個簡單的例子：

if(newStatusCode.equals("SD") && (sellOffDate == null || todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null && todayDate.compareTo(lastUsedDate)>0)) || (newStatusCode.equals("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))){ newStatusCode = "NYP"; }else if(newStatusCode.equals("OBS") && (OBSDate == null || todayDate.compareTo(OBSDate)<0)) { newStatusCode = "NYP"; }

　　是不是讀起來容易多了呢，在此只是多加了一個if和兩個花括號，但程式碼的可讀性與可理解性就一下子提高了一大截。

　　四、請不要硬編碼。開發者經常有意“忘記”或忽略掉這點，因為有些時候開發日程逼得實在太緊。其實，多寫一行定義靜態變數的程式碼能花多少時間呢?

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就行了，而且在今後需要進行修改時，也可在一處修改，不會翻遍整個原始碼逐個修改了。

　　五、不要“創造”自己的框架(framework)。確切來說，有數以千計的各種框架存在，而且大多數是開 源的，這些框架都是優秀的解決方案，可用於日常程式開發中， 我們只需使用這些框架的最新版本就行了，至少表面上要跟上形勢吧。被大家廣為接受的最為明顯的 一個例子就是Struts了，這個開源web框架非常適合用在基於web的應用程式中。是不是想開發出自己的Struts呢，還是省點力氣吧，回頭看看第 二條——不要讓事情複雜化。另外，如果正在開發的程式只有3個視窗，就不要使用Struts了，對這種程式來說，不需要那麼多的“控制”。

　　六、不要使用println及字串連線。通常為了除錯方便，開發者喜歡在可能的所有地方都加上 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 calculationWithOutPrint(){ 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秒。

　　要避免浪費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 < 10000; i++) { someValue = 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); } }

　　另外，字串連線也是浪費CPU時間的一個大頭，請看下面的示例程式碼：

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

　　在測試中可發現，使用StringBuffer的方法只用了0.01秒執行完畢，而使用連線的方法則用了0.08秒，選擇顯而易見了。

　　七、多關注GUI(使用者介面)。再三強調，GUI對商業客戶來說，與程式的功能及效率同等重要，GUI是一 個成功程式的最基本部分，而很多IT經理往往都沒注意到GUI的重要性。在現實生活中，許多公司可能為了節省開支，沒有僱用那些有著設計“使用者友好”介面 豐富經驗的網頁設計者，此時Java開發者只能依賴他們自身的HTML基本功及在此領域有限的知識，結果，很多開發出來的程式都是“計算機友好”甚於“用 戶友好”。很少有開發者同時精通軟體開發及GUI設計，如果你在公司“不幸”被分配負責程式介面，就應該遵守下面三條原則：

　　1、 不要再發明一次輪子，即不做無用功。現有的程式可能會有類似的介面需求。

　　2、 先建立一個原型。這是非常重要一步，使用者一般想看到他們將使用的東西，而且可以先利用這個原型徵求使用者的意見，再慢慢修改成使用者想要的樣子。

　　3、 學會換位思考。換句話來說，就是從使用者的角度來審查程式的需求。舉例來講，一個彙總的視窗可以跨頁或者不跨頁，作為一個軟體開發者，可能會傾向於不跨頁，因為這樣簡單一些。但是，從使用者的角度來看，可能不希望看到上百行資料都擠在同一頁上。

　　八、文件需求不放鬆。每個商業需求都必須記錄在案，這可能聽上去像童話，似乎在現實生活中很難實現。而我們要做的是，不管開發時間多緊迫，不管最終期限多臨近，對每個商業需求都必須記錄在案。

　　九、單元測試、單元測試、單元測試。關於什麼是單元測試的最好方法，在此不便細說，只是強調，單元測試一定要完成，這也是程式設計中最基本的原則。當然了，如果有人幫你做單元測試自然是最好，如果沒有，就自己來做吧，當建立一個單元測試計劃時，請遵守以下三條最基本的原則：

　　1、 先於編寫類程式碼之前編寫單元測試。

　　2、 記錄單元測試中的程式碼註釋。

　　3、 測試所有執行關鍵功能的公有方法，這裡不是指set和get方法，除非它們是以自己獨特方式執行set和get方法。

　　十、質量，而不是數量。有些時候因為產品問題、期限緊迫、或一些預料之外的事情，導致常常不能按時下班，但一般而言，公司不會因為僱員經常加班而對之表揚和獎勵，公司只看重高質量的工作。如果遵守了前九條原則，你會發現自己寫出的程式碼bug少且可維護性高，無形中質量提高了一大步。