技術標籤：程式碼重構重構

回想一下，我們平時寫程式碼過程中，做得最多一件事是什麼？建立一個類，我們要給類起一個名字；建立一個方法，我們要給方法起一個名字；建立一個變數，我們要給變數起一個名字。可想而知，我們無時無刻都在命名，所以我們重構的第一招就是給“娃”起個好名字。

但是也有人會問了：不好、一般或者好的命名對程式碼編譯、執行並沒有影響，為什麼要花把時間浪費在這個無意義的事上。話雖如此，但實際上一個好的命名是整潔程式設計的核心。寫出來的程式碼在大部分的情況下，是給人看的，我們應該追求寫出人能夠讀懂而不是僅機器能夠讀懂的程式碼。在我還沒有太多程式設計經驗時，我對寫出漂亮程式碼往往有心無力，因為我不知道什麼樣的程式碼是漂亮的，隨著經驗越來越豐富，我開始學習各種技巧。其中的一個技巧就是給任何需要命名的地方反覆斟酌，爭取做到看到這個變數名就能知道這一段程式是要做什麼。可能我們一時半會不能立即想出一個很好的名字，沒關係，我們可以先放下等發現有更好的名字時再返回來修改。

這麼說，可能也是太泛泛而談了，下面我們舉一些列子來說明。

1. 名字要做到名副其實

變數名、方法名或者類名應該能夠儘可能地答覆所有的大問題。通過名字，我們就能知道它為什麼會存在，它做什麼事，應該怎麼用等等。如果一個名字還需要註釋來補充說明，那就不算是名副其實。比如下面的這段程式碼：

public List<int[]> getThem() {
    List<int[]> list = new ArrayList<int[]>();
    for (int[] x : theList) {
        if (x[0] == 1) {
            list.
 
add(x);
        }
    }
    return list;
}

上面的這段程式碼並沒有複雜的表示式，程式碼也不長，甚至沒有涉及任何其他類或多型方法，但是第一眼看到這個程式碼，誰能告訴我它在做什麼？

問題不在於程式碼的簡潔度，而是在於程式碼的模糊度：即上下文在程式碼中未被明確體現的程度。要看懂上面程式碼，我們至少需要了解這些問題：

（1）theList中的型別是什麼？

（2）theList下標為0是什麼？4又是什麼含義？

（3）我們怎麼使用返回的列表？

我們從程式碼片段中無法找到上述問題的答案，但返回來說，這些問題的答案不應該就在這裡告訴給讀者嗎？看到這，也許你很想知道那該如何重構了。往下看：

public List<Cell> getSelectedCells() {
    List<Cell> selectedCells = new ArrayList<Cell>();
    for (Cell cell : cells) {
        if (cell.isSelected()) {
            selectedCells.add(cell);
        }
    }
    return selectedCells;
}

重構後的程式碼在沒有任何業務背景下是不是也比重構前的程式碼好理解很多，即使我不再解釋它要做什麼，相信你們也知道這段程式碼大概要幹嘛。而我們實際上什麼都沒修改，只是簡單地修改了一些變數名和方法名，這就是選用好名字的力量。

2. 做有意義的區分

如果我們只是為了滿足編譯器而寫程式碼，那將給團隊的其他成員帶來麻煩。比如以數字區分結尾，這樣的名字純屬誤導，因為它們沒有提供任何正確資訊，沒有提供導向作者意圖的線索。如：

public Entity convert(Entity e1, Entity e2) {
    // do something
    return e2;
}

如果我們能夠將引數名字修改為source和target，那麼看上去就好很多。還有在很多場景包括我自己在很多時候也沒有做到很好的區分，比如我們有一個Product類和ProductInfo類，它們的名稱雖然不同，但表達的意思是相同的，我們也通常稱之為廢話，而廢話是沒有意義的，是冗餘的。再舉個明瞭點的例子，比如nameString，試問一下，誰會認為nameString會比name好？難道name除了字串，還會是一個整數型別？如果真是這樣，別在誤導他人了，請趕快另想一個名字。

3. 使用可搜尋的名字

單字母名稱和數字常量有個問題，就是很難在一整個工程中找出來。找DEFAULT_MIN_VALUE比找數字0容易多吧？找name比找n容易多吧？採用能表達意圖的名稱，貌似使程式碼看起來變長，但想想當你想要在全域性中找到它時，結果搜出來一堆無相關的東西，那是多麼糟糕的一種體驗。

取好名字最難的地方在於需要良好的描述技巧和共有的業務背景，與其說這是一種技術問題，還不如說是一種教學問題，而結果是我們大多數人並沒有學會做得更好。一個好的名字可以是整段程式碼的關鍵字，通過這些關鍵字我們就能將業務描述清楚，就像我們通過關鍵字，就能將整篇文章大意記住。

重構從取一個好名字開始，實際上我大部分在重構過去的程式碼，第一件事就是重新理解業務邏輯，然後看到不爽的名字直接改掉。而重構後，你對自己寫過的程式碼會更加的自信，而這種自信彷彿是與生俱來的。