最近我工作的主要內(nèi)容，是在和別人結(jié)對編程，以對一個大型的遺留系統(tǒng)項目進行重構(gòu)。

[[283642]]

過程中，我發(fā)現(xiàn)一個特別有意思的東西，我重構(gòu)了很多的 if 語句。從這些 if 語句里，大抵是映射出了業(yè)務(wù)的變化。于是，我便想寫一篇文章來記錄一下相關(guān)的心得。

你寫的 if 就是你的犯罪證據(jù)

業(yè)務(wù)的復(fù)雜性，導(dǎo)致了架構(gòu)的復(fù)雜性。在這些代碼故事里，發(fā)生得最多的地方就是 if 語句。所以，你可以從大部分的 if 語句里，看到一些代碼上的壞味道。

業(yè)務(wù)條件復(fù)雜

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

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

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

于是，我們應(yīng)對于這類條件判斷，有兩種做法：提取變量和提取方法。當(dāng)你的判斷條件是一個方法的時候，你可以想象一下它的架構(gòu)是多么的復(fù)雜。

難以閱讀的字符串判斷

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

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

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

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

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

多層嵌套 if 語句

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

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

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

• 提供方法
• 反轉(zhuǎn) if 語句

諸如于：

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

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

復(fù)雜的 if 塊內(nèi)邏輯

當(dāng)業(yè)務(wù)進一步復(fù)雜化的時候，我們的 if 條件里就充斥著各種各樣的邏輯。

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

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

于是，你嘗試把代碼重構(gòu)成多態(tài)以替換 if 語句。

你開心的話，還可以轉(zhuǎn)為 Factory + Strategy。

你開心的話，你也可以將它轉(zhuǎn)為 HashMap 。

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

上帝 if

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

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

重構(gòu)

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

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

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

• 易于理解整個系統(tǒng)的架構(gòu)
• 易于理解整個應(yīng)用程序的執(zhí)行流程
• 易于理解不同對象如何相互協(xié)作
• 易于理解理解每種方法的作用
• 易于理解每個表達式和變量的目的是什么

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

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

WHY

等等，那我們?yōu)槭裁匆M行重構(gòu)呢?為了 ￥￥￥￥￥￥￥$$$$$$$$$ => 快速發(fā)布軟件。

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

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

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

回到問題上

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

我們?nèi)粘ｉ_發(fā)的模式是：紅-綠-重構(gòu)。而因為時間的原因，我們少去了重構(gòu)這一步。

上吊繩驅(qū)動開發(fā)

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

而對于真實的業(yè)務(wù)開發(fā)來說，要事先設(shè)計好相關(guān)功能的架構(gòu)，意味著你得有充足的時間。這樣一來說，你在大的方面上才不會犯錯?？墒悄兀阏娴挠心敲炊嗟臅r間可以設(shè)計嗎?你今天加的班，還好嗎?

代碼所有權(quán)

改動了你的代碼，我就要負(fù)責(zé)。所以，我不去修改別人的代碼。

懼怕修改

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

能力不夠

對，大部分的問題本質(zhì)都是人的問題。

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

結(jié)論

開心就好。