前言
我不喜歡業務代碼中航天飛機式if/else語句, 它複雜而臃腫, 至少從美感而言, switch就比if/else優雅很多. 如果跨語言比較的話, 私以為ReasonML的模式比對比起尋常的switch語句又要強上太多. JS中對複雜判斷的不同寫法, 帶來的感覺是很不同的, 這篇文章裡, 我将簡單介紹幾種用于替代if/else的寫法. 隻有熟悉更多代碼思路, 才能開闊我們的思維, 如果不能學習寫代碼的更多可能性, 也許我們就成了被代碼控制住的人.
if/else
我們以一個售後流程為例. 使用者購買商品後, 可能會因為錯件漏件/品質問題/描述不符等原因聯系商家進行售後服務, 其中可能會涉及退款/退貨/換貨/補發等售後支援服務, 商家對此次售後的服務情況也會影響使用者對商家的喜好. 在這樣的場景下, 我們假設以下僞代碼:
在這個場景下, 每一種售後原因導向的售後支援服務内容是不同的, 比如錯件漏件時使用者不能選擇換貨服務. 如此一來, 我們的判斷條件也就成了一個[售後原因 * 售後支援服務]的二維清單. 此時再加上根據售後原因以及售後支援服務的不同, 判斷條件妥妥地升為三維: [售後原因 * 售後支援服務 * 使用者喜好]
顯然, 在這種重業務邏輯的地方if/else語句顯得力不從心, 主要原因如下:
- 判斷條件後置. 也就是說, 在} else if (serviceReason === '品質問題') {一句中, 我們通常要在行末才能找到判斷條件, 而些内容并沒有高亮支援, 是以經常與下一行的普通代碼混在一起, 讓人眼花缭亂無法辨識.
- 代碼縮進不清晰, 當判斷層數增加, 或是花括号中的内容加長, 那麼閱讀代碼的時候, 尋找if語句對應的結束位置總是給人帶來負擔.
- 奢侈的換行, 當if/else語句中的邏輯很短, 像else { user.love(-5 }這段代碼, 占用了3行的位置顯得過于奢侈.
三目運算符/短路表達式
在一些簡單的表達式中, 可以使用三目運算符或短路表達式去簡化判斷, 如user.love這個函數的調用就可以抽成單獨的一句, 是以下面這種判斷完全可以進行簡化:
逗号運算符
通過括号和逗号運算符, 我們可以把語句變成表達式去執行. 靈活運用逗号運算符可以使三目或短路支援一些更複雜的情況:
不過上述代碼, 在Standard規範中是不被推薦的. ESLint會警告你要求将這行内容轉化為if/else寫法. 當然, 你也可以修改ESLint規範以關閉警告, 前提是你(及團隊成員)喜歡這種寫法, 也千萬不要為了簡化而簡化.
switch/case
處理複雜的多分支判斷時, 大部分人會選擇使用switch作為長if/else的替代品, 你覺得下面這種寫法如何呢?
很遺憾, 看來switch語句并沒有比if/else要好多少. 隻是有一點我要強調, 在上面這個例子中, 所有有關判斷的關鍵字的地方(如switch, case, &&, 這些都屬于代碼高亮區域), 幾乎都存在與每一行開頭的前兩個語元内. 是以目前為止, 單純就搜尋判斷條件的難度而言, switch是要比if/else好上一些, 盡管這種好處會随着判斷分支的增加而逐漸被消磨(這算是一種遺憾吧).
其實還有一個令我覺得遺憾的地方, switch語句不能和短路運算符一并使用, 下面是一種錯誤的示範:
稍微有些難受, 畢竟使用if判斷會增加縮進. 現在讓我們來看一種更加簡潔的思路.
配置資料與業務邏輯分離
配置資料與業務邏輯分離(下簡稱配置邏輯分離)沒有先決條件, 和三目短路表達式一樣, 你随時都可以開始在代碼中使用它. 使用配置邏輯分離, 通常需要定義一個用來存放資料配置的對象, 同時要定義一個flag作為配置的鍵, 配置的值則可以是函數, 數組等任意類型的值. 在執行邏輯的地方, 隻需要将判斷條件與flag進行比對, 就可以擷取到目前判斷條件下的業務邏輯方法:
有沒有眼前一亮的感覺呢?
在上面的代碼片段中, 我們将每一種狀态的資料配置和執行業務邏輯的代碼進行了一定層度的分離, 使得代碼長度短了不少. 通過逗号運算符, 我們可以同時執行業務邏輯函數, 并且傳回使用者對店家的映像分數.
如果你不想這麼激進, 也許下面的代碼是一種好的實踐:
更加靈活的資料配置
上一節使用了對象進行資料配置, 如果說有那麼一點遺憾的地方, 那就是盡管屬性的值可以為任意類型, 但是屬性本身卻隻能是字元串類型, 這使得某些場景下我們不能很好的發揮配置邏輯分離的作用. 想象以下場景: 每個月末, 商家會挑選出狂熱粉絲(喜愛程度大于等于100)發送留言"感謝你"并贈送10元優惠券, 普通粉絲(分數0-100)發送留言"感謝