如何成爲一個優秀的java程序員

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

1. 爲代碼添加註釋（Add comments to your code）. – 每一個人都知道這一點，但不是每一個人都會這麼作。你有多少次「忘記」添加註釋了？確實，註釋不會爲你的程序增長任何函數功能。可是，有多少次，看到2周前寫的代碼，你都記不起它是幹什麼的？你很幸運，那些未註釋的代碼是你本身寫的，你腦海中還會有殘存的印象。很是不幸，大多時候，代碼是別人寫的，而且那我的極可能已經離開公司了。有句諺語說的好：「有來有往，互惠互利」，所以程序員應該體諒彼此（還有你本身），給你的代碼加上註釋。

2. 不要把簡單事情複雜化（Do not complicate things）. – 我曾經這麼作過，我相信你也同樣。開發者都傾向於採用複雜方式解決簡單問題。咱們在一個只有5個用戶的系統中引入EJB，爲一個並不須要框架的應用實現一套框架，採用屬性文件、採用面向對象解決方案、使用線程，而這些根本用不着。爲何會這麼作？一些人可能不知道有更好的解決方案，但另外一些人可能故意這樣作來學習新知識，或僅僅是由於有趣。對那些不知道更好解決方案的人，要多聽有經驗程序員的建議。對於那些純粹出於我的目的而將設計複雜化的人，我建議你要更加專業一點。

3. 記住 － 「越少越好」並不是老是如此(Keep in Mind – 「Less is more」 is not always better). – 高效率的代碼是件好事，但不少狀況下，並不是代碼行數越少效率就越高。看下面這個「簡單」的例子：

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條件是什麼有多困難？再設想一下，寫這段代碼的人並沒遵循第1條 － 爲代碼添加註釋。

把if條件分解成2個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和2個大括號；可是代碼確實更加易讀、更加容易理解了！

4. 不要「硬編碼」（No hard coding please）. – 因爲時間緊迫，開發者老是會忘記或故意忽略這一條。然而另外一種多是，遵循這條戒律，咱們就不會陷入「時間緊迫」的困境。定義一個static final 變量，增長一行代碼，又能花多長時間呢？譬如：

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 便可，而沒必要記住它自己是什麼。對這個常量的修改也很是方便，改一個地方便可，而沒必要在所有代碼中查找。

5. 不要發明你本身的框架（Do not invent your own frameworks）. – 不誇張地講，已經有幾千個框架存在了，大多數仍是開源的。不少框架都是極完美的解決方案，並已被用到成千的系統中。咱們只要關注最新的流行的框架，至少表面上要熟悉一下。一個最成功的、也是被普遍使用的例子是Struts框架，這個開源的web框架是創建web系統的極佳選擇，不要試圖構造你本身的Struts版本，會累死的。但你必須記住第2條（譯註：原文是「第3條」，顯然不對）戒律 —— 不要把簡單事情複雜化。若是你要開發的系統只有3個界面，就不要用Struts. 對於這樣一個系統，沒有足夠的須要被「控制」的東西（譯註：Struts將界面作MVC劃分，C即controller，因此做者說there isn’t much 「controlling」 required）。

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

字符串(String)鏈接是另外一種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 s 而使用String 鏈接須要0.08 s，選擇哪一種應該很明顯了。

7. 注意圖形用戶界面（Pay attention to the GUI）. – 不管聽上去多荒謬，但有一點我注意過屢次了：圖形用戶界面（GUI）對於商業用戶而言與程序功能及執行效率同樣重要。GUI對於應用程序的成功相當重要。 IT管理者（譯註：這裏應該是指程序開發方的IT management）經常忽略GUI的重要性，不少公司爲了省錢而不僱傭Web設計人員，而這些設計人員有足夠的經驗來設計「用戶友好」的應用軟件。 Java程序員不得不依賴他們有限的HMTL知識。我見過很是多對「計算機友好」而非對「用戶友好」的應用程序，同時精通軟件開發和用戶界面開發的開發者很是少見。 若是你是一位不幸被指派作界面開發的Java程序員，你要遵循下面3條規則：

1. 不要從新發明輪子。去看那些相似應用系統的界面。
2. 首先創建一個原型。這一步很是關鍵。客戶喜歡提早看到他們要用的東西。一樣你能夠獲得他們的反饋，而不是你辛辛苦苦作出來一個客戶不喜歡的東西。
3. 試戴用戶的帽子。換句話說，站在用戶的角度查看需求。譬如，一個統計的界面能夠分頁，也能夠不分頁。做爲開發者，極可能會忽略分頁，由於這會減小不少麻煩；而站在客戶角度，這就不是一個好的方案，由於數據可能多達幾百行。

8. 提早準備需求文檔（Always Prepare Document Requirements）. – 每項業務需求都記入文檔。這在童話故事中可能實現，而現實中很難作到。不管時間多麼緊迫，不管截止日期如何迫近，你必須確保業務需求被記錄下來。（譯註：這條明顯悖于敏捷開發的觀念，你們要獨立思考，甄別是非）

9. 單元測試，單元測試，單元測試 （Unit-test. Unit-test. Unit-test）. – 我不許備討論如何單元測試的細節，我只是想說這必需要作。這是編程中最基本的規則了，尤爲不能忽略。若是你同事能爲你的代碼建立一個測試計劃，那就再好不過了；若是不能，那就要本身作。作單元測試計劃時，遵循下面原則：

1. 編碼前就寫單元測試
2. 保留單元測試的註釋
3. 對任何「有趣的」公共方法都要作單元測試（「有趣的」是指除了像最多見的getter/setter這類方法外的方法，但包含有本身內容的getter/setter 方法）

10. 記住：質量，而非數量（Remember – quality, not quantity）. - 不要待的太晚（除非有必要）。我知道有時由於產品問題，截止期限或其餘突發事件，不能按時下班。但經理不會由於你爲通常問題待的太晚而感激或獎勵你；他們會爲有質量的工做而感激你。若是你遵循上面的列的原則，你就會寫更健壯的、少bug的程序。這纔是你最應該作的。

結論

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

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