最近我工作的主要內容，是在和別人結對編程，以對一個大型的遺留系統項目進行重構。

[[283642]]

過程中，我發現一個特別有意思的東西，我重構了很多的 if 語句。從這些 if 語句里，大抵是映射出了業務的變化。于是，我便想寫一篇文章來記錄一下相關的心得。

你寫的 if 就是你的犯罪證據

業務的復雜性，導致了架構的復雜性。在這些代碼故事里，發生得最多的地方就是 if 語句。所以，你可以從大部分的 if 語句里，看到一些代碼上的壞味道。

業務條件復雜

你先寫了一個 if 語句里面只有一個條件，沒問題。但是后來的人，又加了一個條件，因為業務上確實需要這么做。于是，后來，又不得加了一個if 語句，導致了這個條件變得更加復雜。

if(isCondition && isNotASwitchCase && .... && ....) { 
 
} 

所以，完了，這些代碼越來越難以維護。

于是，我們應對于這類條件判斷，有兩種做法：提取變量和提取方法。當你的判斷條件是一個方法的時候，你可以想象一下它的架構是多么的復雜。

難以閱讀的字符串判斷

開始的人加了一個簡單的條件判斷，因為當時真的只有這么一種業務場景。你又不能過度設計，成一個 switch-case。但是，后來又多了好多個場景。

if(aCondition =="A") { 
 
} elseif(bCondition =="B") { 
 
 
} 

更不要提有人在每個 if 里寫一個： if (myString.toUpperCase.equals(myOtherString.toUpperCase))。

針對于有限的 if 語句來說，可以轉為 switch case(在 IDEA 里只需要 alt + enter 就可以自動完成)。

隨著時間的推移我們的條件越來越復雜，我們的 if 語句會越來越復雜。

多層嵌套 if 語句

隨著 if 條件進一步擴大化，我們的條件語句就變成了一個多層嵌套的循環語句。每多一層嵌套代碼復雜度就 * 2，它的閱讀難度就越來越大。于是乎：

if(condition) { 
 
if(blabla) { 
 
... 
 
} 
 
} 

面對這一類 if 條件語句，我們能所做的就是：

• 提供方法
• 反轉 if 語句

諸如于：

if(!condition) {return}; // 為了演示方便 
 
if(blabla){...} 

又或者是諸如于三元表達式，不過我討厭難以閱讀的三元表達式——但是，只是 true 和 false 的情況下，還是相當不錯的。

復雜的 if 塊內邏輯

當業務進一步復雜化的時候，我們的 if 條件里就充斥著各種各樣的邏輯。

if(conditionA) { 
 
blablaA; 
 
blaA(blabla).blabla; 
 
} 

我們的 if 方法隨之變得越來越長，于是嘗試去抽成一個方法。但是，當你又遇到一個新的場景時，你又加了一個 if 語句。后來，又又加了一個 if 語句。你才發現說，『咦，不對，這些 If 語句違反了開閉原則』。

于是，你嘗試把代碼重構成多態以替換 if 語句。

你開心的話，還可以轉為 Factory + Strategy。

你開心的話，你也可以將它轉為 HashMap 。

但是，在你寫下第一個 if 的時候，你并不知道它會變成什么樣的。所以，不要提前去把它轉為這么復雜的架構。

上帝 if

如果你的業務場景真的超級復雜，那么你可能會看到一個非常長的 if 代碼。它可能有幾十個條件，有幾百行到幾千行的規模。

那么，你可以嘗試使用注冊表模式+ 注解，通過反射的方式來重構你的 if 語句。

重構

在你進一步修改代碼之前，讓我們來又雙叕明確一下什么叫重構

重構(Refactoring)就是通過調整程序代碼改善軟件的質量、性能，使其程序的設計模式和架構更趨合理，提高軟件的擴展性和維護性。

換句話來說，重構只是在改善現有的代碼，使其更易于閱讀，換句話來說就是：Clean Code。而當我們說整潔的代碼(Clean Code)，說的是易于理解、修改和測試的。易于理解和修改意味著：

• 易于理解整個系統的架構
• 易于理解整個應用程序的執行流程
• 易于理解不同對象如何相互協作
• 易于理解理解每種方法的作用
• 易于理解每個表達式和變量的目的是什么

而易于理解的前提便是能讓每個團隊成員快速理解。(PS：當然了，若是有些人智商不夠或者經驗不夠，他/她需要去需要去增強這方面的能力)。這便意味著，出于這樣的目的，你不能編寫過于抽象、簡練的邏輯。而你又不能寫得過于繁瑣，充滿大量地無用字符。

若是想使代碼易于測試，則要先使代碼可測試。而在這沒有測試之前，我們是難以對代碼進行大規模重構。所以，我們就陷入了一個死循環，沒有測試，測試不了，沒法重構。

WHY

等等，那我們為什么要進行重構呢?為了 ￥￥￥￥￥￥￥$$$$$$$$$ => 快速發布軟件。

當軟件是一個產品而不是一個項目的時候，我們就需要不斷發布新功能，以滿足客戶的要求。而為了快速發布應用，我們需要讓每次的改動最小，測試最少，才能實現快速發布。基于這樣一個目標，我們會發現我們的諸多實踐都是以此為出發點的。比如說，我們采用插件化、微服務化、組件化的方式，都是為了將軟件的改動變小，這樣一來，就減少了相應部分的測試工作，從某種意義上來說，就加快了軟件發布的流程，從而更好的實現業務價值。因此，我們的第一步就是使二進制改動最小。而要做到二進制改動最小，那么我們就要做到高內聚、低耦合。

因此，不論是在編程還是在設計架構的時候，我們都要盡量滿足 SOLID 五項原則中的：

• 單一職責原則：它規定一個類應該只有一個發生變化的原因。
• 開閉原則：軟件中的對象應該對于擴展是開放的，但是對于修改是封閉的。

回到問題上

既然，我們都已經知道了，如何去重構，如何用設計模式來解決問題。那么，我們會讓我們的代碼變得更好嗎?不會，因為在流水線式的生產里，每個人都能找到合理的理由。

我們日常開發的模式是：紅-綠-重構。而因為時間的原因，我們少去了重構這一步。

上吊繩驅動開發

在上吊繩(deadline)的驅動下，我寫了一這篇文章。盡管預先寫好了文章的大綱，但是有很多字是打錯的。

而對于真實的業務開發來說，要事先設計好相關功能的架構，意味著你得有充足的時間。這樣一來說，你在大的方面上才不會犯錯。可是呢，你真的有那么多的時間可以設計嗎?你今天加的班，還好嗎?

代碼所有權

改動了你的代碼，我就要負責。所以，我不去修改別人的代碼。

懼怕修改

沒有測試，難以理解代碼背后的業務原因。外加之組織文化，導致的溝通障礙;又或者是大家都很忙，沒人愿意解釋/回顧一下這一塊的代碼。

能力不夠

對，大部分的問題本質都是人的問題。

因為你只需要按下 IDEA 的快捷鍵，就能完成上面的大部分重構工作。當然了，需要有技巧的按，而不是像 Monkey 一樣彈鋼琴。

結論

開心就好。