Java開發者須要堅守的十大準則

1、爲代碼加註釋。
    雖然每一個人都知道這點，但有時卻不自覺忘了履行，今天你「忘了」加註釋了嗎？雖然註釋對程序的功能沒什麼「貢獻」，但過一段時間，好比說兩星期以後或者更長，回過頭來看看本身的代碼，說不定已經記不住它是幹什麼的了。若是這些代碼是你我的的，那還算是走運了，不幸的是，固然了，大多數時候都是別人的不幸，不少時候你們都是在爲公司寫代碼，寫代碼的人也許早已經離開了公司，但別忘了一句古話，有來有往嘛，爲他人，也爲咱們本身，請爲你的代碼加上註釋。

2、不要讓事情複雜化。
    程序員有時候老是對簡單問題想出複雜的解決方案，好比說，在只有五個用戶的程序中引入EJB、對程序實現了並不須要的框架（framework），之類的還有屬性文件、面向對象解決方案、多線程等等。爲何要這樣作呢？也許咱們並不知道是否這樣會更好，但這樣作也許能夠學到一些新東西，或者讓本身更感興趣一些。若是是不知道爲何這樣作，建議多請教經驗豐富的程序員，若是是爲了我的的目的，麻煩讓本身更專業一點。

3、始終牢記——「少便是好（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和兩個花括號，但代碼的可讀性與可理解性就一會兒提升了一大截。

4、請不要硬編碼。
    開發者常常有意「忘記」或忽略掉這點，由於有些時候開發日程逼得實在太緊。其實，多寫一行定義靜態變量的代碼能花多少時間呢？
public class A {
public static final String S_C; 
public boolean methodA(String sParam1){
if (A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){
return true; 
}
return false; 
}
}
　　如今，每次須要將「ABC」與其餘變量進行比較時，沒必要記住實際代碼，直接引用A.S_CONSTANT_ABC就好了，並且在從此須要進行修改時，也可在一處修改，不會翻遍整個源代碼逐個修改了。

5、不要「創造」本身的框架（framework）。
    確切來講，有數以千計的各類框架存在，並且大多數是開源的，這些框架都是優秀的解決方案，可用於平常程序開發中，咱們只需使用這些框架的最新版本就好了，至少表面上要跟上形勢吧。被你們廣爲接受的最爲明顯的一個例子就是Struts了，這個開源web框架很是適合用在基於web的應用程序中。是否是想開發出本身的Struts呢，仍是省點力氣吧，回頭看看第二條——不要讓事情複雜化。另外，若是正在開發的程序只有3個窗口，就不要使用Struts了，對這種程序來講，不須要那麼多的「控制」。

6、不要使用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秒，選擇顯而易見了。

7、多關注GUI（用戶界面）。
    再三強調，GUI對商業客戶來講，與程序的功能及效率同等重要，GUI是一個成功程序的最基本部分，而不少IT經理每每都沒注意到GUI的重要性。在現實生活中，許多公司可能爲了節省開支，沒有僱用那些有着設計「用戶友好」界面豐富經驗的網頁設計者，此時Java開發者只能依賴他們自身的HTML基本功及在此領域有限的知識，結果，不少開發出來的程序都是「計算機友好」甚於「用戶友好」。不多有開發者同時精通軟件開發及GUI設計，若是你在公司「不幸」被分配負責程序界面，就應該遵照下面三條原則：
　　一、 不要再發明一次輪子，即不作無用功。現有的程序可能會有相似的界面需求。
　　二、 先建立一個原型。這是很是重要一步，用戶通常想看到他們將使用的東西，並且能夠先利用這個原型徵求用戶的意見，再慢慢修改爲用戶想要的樣子。
　　三、 學會換位思考。換句話來講，就是從用戶的角度來審查程序的需求。舉例來說，一個彙總的窗口能夠跨頁或者不跨頁，做爲一個軟件開發者，可能會傾向於不跨頁，由於這樣簡單一些。可是，從用戶的角度來看，可能不但願看到上百行數據都擠在同一頁上。

8、文檔需求不放鬆。
    每一個商業需求都必須記錄在案，這可能聽上去像童話，彷佛在現實生活中很難實現。而咱們要作的是，無論開發時間多緊迫，無論最終期限多臨近，對每一個商業需求都必須記錄在案。

9、單元測試、單元測試、單元測試。
    關於什麼是單元測試的最好方法，在此不便細說，只是強調，單元測試必定要完成，這也是編程中最基本的原則。固然了，若是有人幫你作單元測試天然是最好，若是沒有，就本身來作吧，當建立一個單元測試計劃時，請遵照如下三條最基本的原則：
　　一、 先於編寫類代碼以前編寫單元測試。
　　二、 記錄單元測試中的代碼註釋。
　　三、 測試全部執行關鍵功能的公有方法，這裏不是指set和get方法，除非它們是以本身獨特方式執行set和get方法。

10、質量，而不是數量。
    有些時候由於產品問題、期限緊迫、或一些預料以外的事情，致使經常不能按時下班，但通常而言，公司不會由於僱員常常加班而對之表揚和獎勵，公司只看重高質量的工做。若是遵照了前九條原則，你會發現本身寫出的代碼bug少且可維護性高，無形中質量提升了一大步。