如何重構“箭頭型”代碼

cloud 發布于2019-08-19 10:56 / 1354人閱讀

摘要：寫代碼時，代碼的運行中的控制狀態或業務狀態是會讓你的代碼流程變得混亂的一個重要原因，重構箭頭型代碼的一個很重要的工作就是重新梳理和描述這些狀態的變遷關系。重構箭頭型代碼其實是在幫你重新梳理所有的代碼和邏輯，這個過程非常值得為之付出。

所謂箭頭型代碼，基本上來說就是下面這個圖片所示的情況。

那么，這樣“箭頭型”的代碼有什么問題呢？看上去也挺好看的，有對稱美。但是……

關于箭頭型代碼的問題有如下幾個：

1）我的顯示器不夠寬，箭頭型代碼縮進太狠了，需要我來回拉水平滾動條，這讓我在讀代碼的時候，相當的不舒服。

2）除了寬度外還有長度，有的代碼的if-else里的if-else里的if-else的代碼太多，讀到中間你都不知道中間的代碼是經過了什么樣的層層檢查才來到這里的。

總而言之，“箭頭型代碼”如果嵌套太多，代碼太長的話，會相當容易讓維護代碼的人（包括自己）迷失在代碼中，因為看到最內層的代碼時，你已經不知道前面的那一層一層的條件判斷是什么樣的，代碼是怎么運行到這里的，所以，箭頭型代碼是非常難以維護和Debug的。

代碼量如果再大一點，嵌套再多一點，你很容易會在條件中迷失掉（下面這個示例只是那個“大箭頭”下的一個小箭頭）

FOREACH(Ptr, argument, node->arguments) {

int index = manager->expressionResolvings.Keys().IndexOf(argument.Obj());
if (index != -1) {
    auto type = manager->expressionResolvings.Values()[index].type;
    if (! types.Contains(type.Obj())) {
        types.Add(type.Obj());
        if (auto group = type->GetTypeDescriptor()->GetMethodGroupByName(L"CastResult", true)) {
            int count = group->GetMethodCount();
            for (int i = 0; i < count; i++) { auto method = group->GetMethod(i);
                if (method->IsStatic()) {
                    if (method->GetParameterCount() == 1 &&
                        method->GetParameter(0)->GetType()->GetTypeDescriptor() == description::GetTypeDescriptor() &&
                        method->GetReturn()->GetTypeDescriptor() != description::GetTypeDescriptor() ) {
                        symbol->typeInfo = CopyTypeInfo(method->GetReturn());
                        break;
                    }
                }
            }
        }
    }
}

}

上面這段代碼，可以把條件反過來寫，然后就可以把箭頭型的代碼解掉了，重構的代碼如下所示：
FOREACH(Ptr, argument, node->arguments) {

int index = manager->expressionResolvings.Keys().IndexOf(argument.Obj());
if (index == -1)  continue;
 
auto type = manager->expressionResolvings.Values()[index].type;
if ( types.Contains(type.Obj()))  continue;
 
types.Add(type.Obj());

auto group = type->GetTypeDescriptor()->GetMethodGroupByName(L"CastResult", true);
if  ( ! group ) continue;

int count = group->GetMethodCount();
for (int i = 0; i < count; i++) { auto method = group->GetMethod(i);
    if (! method->IsStatic()) continue;
    
    if ( method->GetParameterCount() == 1 &&
           method->GetParameter(0)->GetType()->GetTypeDescriptor() == description::GetTypeDescriptor() &&
           method->GetReturn()->GetTypeDescriptor() != description::GetTypeDescriptor() ) {
        symbol->typeInfo = CopyTypeInfo(method->GetReturn());
        break;
    }
}

}

這里的思路其實就是，讓出錯的代碼先返回，前面把所有的錯誤判斷全判斷掉，然后就剩下的就是正常的代碼了。

對于 if-else 語句來說，一般來說，就是檢查兩件事：錯誤和狀態。

檢查錯誤
對于檢查錯誤來說，使用 Guard Clauses 會是一種標準解，但我們還需要注意下面幾件事：

1）當然，出現錯誤的時候，還會出現需要釋放資源的情況。你可以使用 goto fail; 這樣的方式，但是最優雅的方式應該是C++面向對象式的 RAII 方式。

2）以錯誤碼返回是一種比較簡單的方式，這種方式有很一些問題，比如，如果錯誤碼太多，判斷出錯的代碼會非常復雜，另外，正常的代碼和錯誤的代碼會混在一起，影響可讀性。所以，在更為高組的語言中，使用 try-catch 異常捕捉的方式，會讓代碼更為易讀一些。

檢查狀態
對于檢查狀態來說，實際中一定有更為復雜的情況，比如下面幾種情況：

1）像TCP協議中的兩端的狀態變化。

2）像shell各個命令的命令選項的各種組合。

3）像游戲中的狀態變化（一棵非常復雜的狀態樹）。

4）像語法分析那樣的狀態變化。

對于這些復雜的狀態變化，其本上來說，你需要先定義一個狀態機，或是一個子狀態的組合狀態的查詢表，或是一個狀態查詢分析樹。

寫代碼時，代碼的運行中的控制狀態或業務狀態是會讓你的代碼流程變得混亂的一個重要原因，重構“箭頭型”代碼的一個很重要的工作就是重新梳理和描述這些狀態的變遷關系。

總結
好了，下面總結一下，把“箭頭型”代碼重構掉的幾個手段如下：

1）使用 Guard Clauses 。盡可能的讓出錯的先返回，這樣后面就會得到干凈的代碼。

2）把條件中的語句塊抽取成函數。有人說：“如果代碼不共享，就不要抽取成函數！”，持有這個觀點的人太死讀書了。函數是代碼的封裝或是抽象，并不一定用來作代碼共享使用，函數用于屏蔽細節，讓其它代碼耦合于接口而不是細節實現，這會讓我們的代碼更為簡單，簡單的東西都能讓人易讀也易維護，寫出讓人易讀易維護的代碼才是重構代碼的初衷！

3）對于出錯處理，使用try-catch異常處理和RAII機制。返回碼的出錯處理有很多問題，比如：A) 返回碼可以被忽略，B) 出錯處理的代碼和正常處理的代碼混在一起，C) 造成函數接口污染，比如像atoi()這種錯誤碼和返回值共用的糟糕的函數。

4）對于多個狀態的判斷和組合，如果復雜了，可以使用“組合狀態表”，或是狀態機加Observer的狀態訂閱的設計模式。這樣的代碼即解了耦，也干凈簡單，同樣有很強的擴展性。

5）重構“箭頭型”代碼其實是在幫你重新梳理所有的代碼和邏輯，這個過程非常值得為之付出。重新整思路去想盡一切辦法簡化代碼的過程本身就可以讓人成長。

GPU云服務器云服務器代碼重構網站重構數據重構頁面重構

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/76719.html

重構：一項常常被忽略的基本功

摘要：無論如何，單元測試一直是一中非常重要卻常常被忽視的技能。在實踐中，重構的要求是很高的它需要有足夠詳盡的單元測試，需要有持續集成的環境，需要隨時隨地在小步伐地永遠讓代碼處于可工作狀態下去進行改善。 showImg(https://segmentfault.com/img/bVbttWF?w=1000&h=528); 五月初的時候朋友和我說《重構》出第 2 版了，我才興沖沖地下單，花了一個...

idealcn 2019-08-23 17:56 評論0 收藏0
如何用微服務重構應用程序

摘要：以下兩個要點將會對任何微服務重構策略產生重大影響。批量替換通過批發更換，您可以一次性重構整個應用程序，直接從單體式轉移到一組微服務器。如果您通過使用破解您的微服務器，那么每個域將圍繞一個用例，或者更常見的，一組相互關聯的用例。在決定使用微服務之后，為了將微服務付諸實踐，也許你已經開始重構你的應用程序或把重構工作列入了待辦事項清單。無論是哪種情況，如果這是你第一次重構應用程序，那么您...

KevinYan 2019-06-28 15:53 評論0 收藏0
如何重構

摘要：重構定義重構是對軟件內部結構的調整，目的是在不改變軟件可觀察行為的前提下，提高其可理解性，降低其修改成本。重構節奏小步前進，頻繁測試。 1.重構定義：重構是對軟件內部結構的調整，目的是在不改變軟件可觀察行為的前提下，提高其可理解性，降低其修改成本。 2.重構節奏：小步前進，頻繁測試。 3.重構意義： 1.改進軟件設計 2.使軟件更容易被理解 3.幫助找到bug 4.提高編程速度惡...

iamyoung001 2019-08-19 10:33 評論0 收藏0
如何編寫高質量代碼

摘要：如果你不能以高標準來要求自己，即使你看再多的如何寫出高質量代碼，懂再多的代碼規范，也是沒有用，最終還是會寫出低質量代碼。建議先從代碼規范開始，熟悉代碼規范，遵循規范寫代碼，直到成為習慣，然后再學習其它方法，最終寫出高質量代碼。更多文章什么是高質量代碼? 高質量代碼具有以下幾個特點：可讀性高結構清晰可擴展（方便維護）代碼風格統一低復雜性簡練編寫高質量代碼主要遵循以下...

only_do 2019-08-23 14:37 評論0 收藏0
重構-改善既有代碼的設計(二) --重構原則

摘要：改進代碼設計的一個重要原則就是消除重復代碼使軟件更容易被理解優秀的代碼能夠讓接收你代碼的付出更少的學習成本。重構更容易找到重構能加深對代碼的理解。可以重構的情況添加功能時可以重構。說明你沒有發現代碼的錯誤。需要重構復審代碼時可以重構。為何重構重構不是銀彈，但是幫助你達到以下幾個目的改進軟件設計不良的程序需要更多的代碼。而代碼越多，正確的修改就越困難。改進代碼設計的一個重要原則就...

myshell 2019-08-15 18:11 評論0 收藏0