如果你熱愛編碼，就應該少寫代碼

“如果你喜歡一個人，就應該盡量少說那些甜言蜜語。”不知道大家是否聽過某些戀愛專家的肺腑之言。對于程式員來說，如果你熱愛編碼，那麼我也勸你：“能少寫一行代碼就盡量少寫一行。”

可能有些同學覺得這話聽起來有點玄乎：“代碼寫得少，不就意味着缺乏實戰經驗嗎？那我何年何月才能進一線大廠，成為真正的大神呢？”

如果你要這麼了解的話，我就必須要糾正你一下。我表達的意思是這樣的，來通過兩行簡短的代碼表情達意吧。

if (str == null || "".equals(str)) {}

if (StringUtils.isEmpty()) {}

就上面這兩行代碼來說，我的第一選擇是使用第二行代碼來進行判空操作，因為它的代碼量更少——簡潔明了，也更不容易出錯。

如果我們程式員沒有這種（寫更少代碼的）追求的話，那我們的程式設計技藝就隻會原地踏步，長此以往的後果就是各種避免重複造輪子的第三方類庫就不會出現。

就判空操作來說，str == null || "".equals(str) 已經幹得非常漂亮了（null 和空字元串都考慮在内了），但性能仍然有待優化，可以使用更高效的 str == null || str.length() == 0 來替代。為什麼這麼說呢？

因為 Sting 類的 equals() 方法本身是很沉重的，其源碼如下所示。

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    if (anObject instanceof String) {
        String aString = (String)anObject;
        if (!COMPACT_STRINGS || this.coder == aString.coder) {
            return StringLatin1.equals(value, aString.value);
        }
    }
    return false;
}      

而 str.length() == 0 則簡單得多，無非就是兩個數值“==”比較。孰優孰劣，高下立見。StringUtils.isEmpty() 的内部就恰好使用的是 str == null || str.length() == 0。

對于某些程式員來說，承認這個事實是痛苦的，因為他們是那麼的熱愛原生。他們争辯說：“那我甯願使用 str == null || str.length() == 0 也不使用第三方類庫的 StringUtils.isEmpty()，因為寫原生更直接、更純粹。”

不，别這樣，我耐着性子再勸一句，要理智啊。假如哪天需要把" "（n 個空格）這樣的字元串也作為空字元串進行判斷呢？難不成要在原生的判斷條件中追加 n 個 || " ".equals(str)？

還是追求簡潔點好啊！因為我們可以把 StringUtils.isEmpty() 換成 StringUtils.isBlank()，該方法已經為我們考慮好了，來看一下源碼。

public static boolean isBlank(final CharSequence cs) {
    int strLen;
    if (cs == null || (strLen = cs.length()) == 0) {
        return true;
    }
    for (int i = 0; i < strLen; i++) {
        if (Character.isWhitespace(cs.charAt(i)) == false) {
            return false;
        }
    }
    return true;
}      

很周全吧？

作為程式員，為我們編寫的每一行代碼負責任是理所應當的一件事。

代碼簡潔度；

功能的完整度；

執行速度；

編碼所花費的時間；

健壯性；

靈活性。

這 6 項名額都值得我們去考量，盡管它們之間有些是對立的，比如說花了一個月的時間實作了一個健壯性非常良好、執行速度也非常快的程式，那可能“編碼所花費的時間”（一個月）就有點長了。那怎麼樣做是值得的呢？

答案隻有一個：從簡潔開始，再去達其他的标。

代碼會随着時間的推移慢慢增加（新的需求、bug 修複），你寫的代碼越多，bug 藏身的地方就越多，代碼編譯的速度就會越慢，維護代碼的壓力也會随之增加。

這是不争的事實。

就好像我們程式員一樣，歲月這把殺豬刀不僅會給我們理個發（減少一下發量），還會增加我們的贅肉，如果不堅持鍛煉的話，新陳代謝的減緩就會讓我們胖成球。

代碼是我們程式員創造出來的，如果隻在擴充功能的時候追加代碼，不在重構的時候精簡代碼，那麼堆疊如山的代碼就會像蘋果一樣腐爛，一個傳染倆。

當然了，代碼并不是我們的敵人，真正的敵人是誰呢？你往鏡子前面一站就恍然大悟了。真正的敵人是我們自己，如果你還熱愛編碼，就要時刻提醒自己，能少寫代碼就少寫！

記得偉大的文學家馬克吐溫曾說過這樣一句話：

我沒有時間寫一封簡短的信，是以我寫了一封長的。

寫代碼和寫文字在本質上是一種事情，把代碼寫得少一點遠比寫得多一點更不容易，它需要耗費更多的腦力才能完成。

Medium 上的一個作者 Elliot Chance 也曾表達過和我類似的觀點，他說：“要分辨兩個程式員的優劣，就是給他們一樣的時間，越好的程式員寫出來的代碼越少（當然是可以運作的）。”

越多的代碼并不一定代表着認真，有可能代表的是懶惰，懶得去思考，才會寫出臃腫的代碼。那怎樣才能寫出更少的代碼呢？

首先，要多思考，不要拿到需求就開始敲代碼；

其次，多積累經驗，張三豐打架都是赤手空拳，武器招數都不要不要的，因為他真的是身經百戰啊；

最後，基礎紮實，隻有把程式設計語言的本質吃透，比如說上文中提到的 str.length() == 0 和 "".equals(str)，如果你沒有研究過源碼，你壓根就不知道它們之間的性能優劣。

不過，有一點我需要提醒大家，假如你的公司的績效考核是按照代碼的數量來評定的，那就當我什麼皮也沒放過。或者，要不你換一家注重代碼品質的公司？