引言

大家好，我是有清

《史記》有云：大樂必易，大禮必簡，寫給機器看的代碼簡單，但是寫給人看的代碼就需要一點心思

在我們平常的開發過程中，如果遇到代碼嵌套過深的函數，那么我們會

什么叫嵌套過深呢

我們可以簡單看一段發工資的例子

我們將函數內部一個左花括號視為一個嵌套深度，那么我們這個函數具有足足 5 層深度，正常情況下超過 3 層深度，這段代碼便會散發出臭的味道，當然這不是業界定義，只要你覺得這一段代碼不好理解，那么這一段代碼就存在可以優化的空間

扁平化

那如何減少我們這個嵌套深度呢？扁平化管理我們代碼呢

通常情況下，我們具有兩種手段，第一種是提煉，將一段代碼提煉到一個獨立的函數；第二種是反轉，盡快將結果返回給函數。

接下來，我們開始使用這兩種手段，去重構一下我們的代碼。

提煉

我們什么時候可以提煉函數呢？

就是當我們 「需要花一段時間去理解這一段代碼是用來干什么的時候我們就可以將這一段代碼去提煉為函數」

舉個簡單一點的??

有時候我們需要檢查response 是否正確，正確的話，我們才會進行一系列對應的邏輯處理

if(Objects.nonNull(respponse) && Objects.equals(respponse.code, "200") && Objects.nonNull(response.getModel())) {
 // do something
}

通常情況下，我們要去閱讀主要邏輯之前，我們需要去看一下if這到底是什么情況才會走入我們的邏輯，但其實這邊都是一些常規的校驗，我們大多數的時候根本不關心這個校驗的具體邏輯，因為它是用來預防我們的代碼出現異常的取值報錯

那么，我認為這種的 if 就可以提煉出來一個函數

if(this.isSucess(respponse)) {  
    // do something  
}  

private Boolean isSucess(Response resp) {  
    return Objects.nonNull(respponse) && Objects.equals(respponse.code, "200") && Objects.nonNull(response.getModel())  
}

讀者只需要關心，這個 response 是 sucess 即可，不需要具體關心我是怎么 check 這個 response，因為它相對主邏輯來說不是那么的重要

當然還有一種情況，在代碼邏輯中區分紅花和綠葉，這也是阿里開發手冊中推薦的我們的一點，單個方法的總行數不要超過 80 行，代碼邏輯分清紅花和綠葉，個性和共性，綠葉邏輯單獨出來成為額外方法，使主干代碼更加清晰；共性邏輯抽取成為共性方法，便于復用和維護

好，接下來我們優化一下引言中的代碼

優化之后，主干邏輯就清晰了，我們想要知道每個情況下的工資是如何發放的，只需要點進去具體的函數查看即可

但是這么多的 if 嵌套，看的還是很不舒服，我們繼續下一個動作

反轉

通常情況下，我們的if、else 就是用來區分在不同的情況下，代碼是走向陽光道還是獨木橋，陽光道就是可以理解為都是我們重要的邏輯，讀者都需要看

獨木橋你可以理解為異常情況，需要立刻從函數中返回回去，我們通常稱這樣的語句為衛語句，基于我們防御性編程的思想下，盡快的檢查返回該函數結果

同樣阿里規范也給我們提到了這一點

那么我們根據這個思想再進一步優化一下我們引言的代碼

最后再對比一下重構前后的代碼

總結

在本文中我們接觸到了，可以借助提煉以及反轉去優化我們的代碼嵌套，其實你可以看看當前你的項目中的代碼是否存在這樣的情況，可以考慮是否優化一波，當然優化的時候切記回歸測試的重要性

借用熊節的一句話：據說古時高僧有云 “時時勤拂拭，勿使惹塵?！?，代碼當如是，專業人士的技藝應當如是

希望大家都能像寫詩一樣的寫代碼

寫在最后

在朋友的安利下，上周去了西溪濕地尋梅

順著路標的最佳賞梅點，我們一路往前走，但其實花還是沒有那么的密集，我們可疑惑，是梅花還沒開，還是已經謝了

直到，我們看見有個游人，在拍照的時候不斷的搖那個梅花樹想讓自己更為出片，我才悟了，原來不密集的梅花，不是樹的不挽留，而是愛美的人的追求