你是否曾打開一個代碼倉庫，閱讀體驗卻像是在解一場“地獄難度”的解謎游戲？

最開始還算溫和： 一個簡單的 if，再配上一個 else，看起來井井有條。

但很快，它開始分支，再分支。 幾百行代碼之后，你開始調(diào)試這樣一段邏輯：

if (user.isAdmin && !user.hasSubscription && moon.isInRetrograde)

這不是在寫程序，這是在解星座+運勢+權(quán)限的組合謎題。

這就是 if 的毒性 —— 看似無害，實則成癮。

一切始于“無害的第一課”

還記得我們是怎么學(xué)編程的嗎？

第一天，變量。第二天，if-else。 “如果 A，就做 B；否則就做 C。”邏輯清晰，通俗易懂。

然后老師讓你寫一個計算器，一個登錄頁面，一個小游戲。

結(jié)果？你交出了一份布滿條件判斷的“謎之結(jié)構(gòu)”。

我們說：“沒事，這是成長的過程?！?但接下來沒人告訴你什么時候該停下來了。

圖片

?? 然后，成癮開始了

你會看到這樣的代碼：

• 支持五種用戶類型的邏輯判斷
• 處理十二種支付狀態(tài)的分支
• 或者，組合七十多個 feature flag 的條件語句

代碼瞬間變成一份比超市小票還長的 switch-case。

你會看到多層嵌套的 if，層層遞進、無限回環(huán)。

你會看到這樣的“布爾湯”：

if (!isActive && !isArchived && (isPremium || isTrial))

看似“只是邏輯”，實則不具可維護性、不具可擴展性、不具可理解性。

問題不是你加了多少功能，而是你用什么結(jié)構(gòu)承載它。

沒人教我們“if 之后該做什么”

我們只學(xué)會了 if，卻沒人告訴我們：什么時候不該再用它。

我們沒學(xué)過：

• 什么時候該引入對象映射
• 什么時候該用多態(tài)來代替分支
• 什么時候應(yīng)該盡早用 guard return 避免嵌套地獄
• 什么時候狀態(tài)多了該用狀態(tài)機管理

于是大家開始像搭積木一樣堆疊判斷 —— 直到某天，加一個小功能也能讓整座大廈轟然倒塌。

更糟的是，有經(jīng)驗的程序員會用三元表達式、可選鏈、邏輯短路“優(yōu)雅”地藏住混亂。

表面上看起來干凈利落，實際邏輯還是如履薄冰。

我們應(yīng)該學(xué)什么？

別再把 if-else 當(dāng)作默認選擇，而是當(dāng)作第一步。

接下來的正確打開方式是：

• 用對象 Map 替代平鋪判斷
• 行為不同用多態(tài)處理（而不是 type === 'X'）
• 用 Guard 提前 return，避免陷入層層嵌套
• 用明確的領(lǐng)域模型替代 flag 組合
• 狀態(tài)復(fù)雜？別硬撐，狀態(tài)機才是解藥

你可能會說：“這些看起來太重了?！?等你的 if-else 長成五頭六臂的巨獸時，你就知道這不叫 overkill，這叫預(yù)防災(zāi)難。

結(jié)語：if 本身無罪，濫用才可怕

if 像是編程語言的 GOTO —— 法律允許，但會毀掉結(jié)構(gòu)。

它最初是邏輯的起點，最終卻成為“技術(shù)債”的縮影。

所以，下次你寫下一個 if，不妨問問自己：

這是最后一個判斷，還是又一次陷入復(fù)雜深淵的起點？

如果你喜歡這樣的技術(shù)思考，歡迎點贊、關(guān)注或評論交流。 我會持續(xù)分享更多關(guān)于寫出可維護代碼的實踐與反思。

是否需要我基于此內(nèi)容再生成一版適用于微信公眾號/知乎的長圖文格式？或者視頻腳本/講演稿版本也可以提供。