在技術社區中，經常可以看到一些博客推廣編程語言的各種“高級特性”和“高級模式”，并使用這些特性編寫一些“優雅”的代碼。那么，學習和使用這些東西到底是好是壞呢？本文旨在幫助你做出判斷。

技巧的巧妙與智慧的智慧

許多人以使用語言和框架的晦澀特性為榮，通過利用各種罕見的 API 展示自己對框架的熟悉度。他們認為自己的編程和技術水平高于那些編寫簡單邏輯的學生。這個觀點是否合理？下面通過幾個例子來推導一下：

首先，在招聘開發人員時，有一個有趣的現象：層次越高的應聘者，考察的具體編碼技能越少，而更多考察架構能力、業務理解和工程質量。請注意，理解架構、業務和工程不是指溝通或管理等軟技能，而是工程師的扎實專業能力。

另一方面，在技術社區中，最受歡迎的內容往往是各種框架和庫的“入門指南”。從暢銷的《XXX 從初學者到專家》指南到《一步一步教你如何學習 XXX》，最熱門的內容仍然圍繞如何操作這些 API 和應用某些技術知識模式。

結合這些現象和一些常識，我們可以得出以下三個條件：

• 程序員的層次越高，其技能樹中技術知識的比例越小。
• 高級程序員的比例遠小于初級程序員。
• 在編程社區中，大多數人關心的是技術知識。

根據這些條件，我們可以做出一個松散的推論：那些最關注和癡迷于編程技能的人，很可能是初級程序員中的大多數。這樣，炫耀技巧不一定能表明技術水平高超。

需要明確的是，我們并不認為編程技能不重要。相反，高級程序員對技能的理解遠比初級程序員深刻，許多高超的代碼可以在數量級上優化和解決問題。那么，我們應該如何評價這樣的代碼呢？

能夠應用各種高級特性的學生無疑被認為是“聰明”的。然而，何時何地使用它們需要基于所謂的“智慧”來判斷。這類似于 Facebook 和 Google 的代碼標準中經常看到的說法：

用你最好的判斷力。

雖然聽起來令人愉快，但這是一個非常玄妙的概念。下面我們將進行一些更具體的討論，并提取一些常見的技巧和技術。

常見的技巧和技術

使用危險的語義

許多人在閱讀了《高級程序設計》之類的書后，會將他們對高級特性的理解應用到實際項目中，以炫耀自己的技術水平。在前端領域，這些行為包括但不限于：

• 了解 == 和 === 的區別，并在不同情況下使用不同的符號進行邏輯判斷。
• 了解變量提升行為，并利用它實現特殊的代碼執行順序。
• 理解原型和構造函數，并使用它們實現各種繼承關系。
• 掌握 this 指向的各種規則，并利用特殊規則綁定上下文。
• ...

雖然使用這些特性的代碼確實可以運行，但問題在于這些語義都是危險的，或者是語言設計問題造成的糟粕。在已知它們難以使用并且有成熟替代解決方案的情況下，為什么要使用它們來炫耀自己的技術水平？然而在前端社區中，這種行為屢見不鮮。例如，僅僅理解 this 指針的各種規則就足以寫一篇長文（這在許多技術社區中早已成為一個乏味的話題）。而像 == 這樣的特性雖然有無數的陷阱，令人驚訝的是仍有許多人在閱讀博客后“合理”地使用它們。至于變量提升，這種完全反直覺的設計缺陷被一些人用來創造各種花哨的面試題。

當然，這絕不是反對理解這些所謂的“高級特性”如何工作以及為什么它們會導致混亂的行為。對于每一個想要成長的可靠學生來說，學習它們是很重要的。這里給出的建議是：

1. 至少了解它們一次，達到能夠指出問題所在的水平。
2. 學習這些特性的替代解決方案，并知道如何避免陷阱。
3. 除非維護底層庫，否則不要在代碼中使用它們。

應用設計模式

設計模式也是技術文章中非常常見的一個話題。例如，許多文章將《設計模式》中的幾十種模式應用到 JavaScript 中，使用上述的各種“高級特性”模擬和實現這些模式。最后，他們會提升說這些模式都是“優秀程序員必須知道的”，因此在簡歷上加上一行“熟練掌握各種設計模式”顯得很有吸引力！

設計模式的最初目的是彌補靜態語言如 Java 的不足。隨著編程語言的發展，許多“經典”設計模式已經成為語言機制的一部分。例如，export 對單例模式的內置支持，用函數層包裹內容就是工廠模式，yield 也實現了迭代器模式等等。此外，JS 的動態特性使得 JSON 的靈活性遠遠超過 reflection，而函數作為一等公民的設計使得 JS 的回調函數比 Java 的回調接口或 Visitor 模式靈活得多。

許多提倡設計模式的文章并不是因為它們人為地制造了不必要的復雜性，而是因為它們創造了一種誤解，即“如果不使用 XX 模式，說明你的技能不足”。至少從個人閱讀優秀開源項目源碼的經驗來看，我沒有發現機械地應用模式的實例；相反，問題得到了清晰的描述，隨后提供了可讀的抽象。當然，可以事后在其中找到某些實現的模式；然而，我更愿意相信作者在編碼時并沒有“這里需要使用 XX 模式”的心態。然而，許多缺乏辨別能力的初學者可能會因為缺乏閱讀高質量代碼的經驗或受到公司遺留項目中舊代碼的影響，最終固執地遵循這些刻板的方法。在我看來，這相當遺憾。

減少代碼行數

我們都知道，通過復制粘貼生成的冗長和重復的代碼是不好的。然而，大多數復制粘貼發生在時間緊迫、沒有時間進行優化的情況下。考慮到我們的同學們的工作強度，這可以理解。另一方面，還有另一種極端行為，即通過各種非常規手段“簡化”代碼，以實現“最簡潔”的代碼。

例如，剛開始學習函數式編程的學生可能會特別喜歡 a(b(c(d, e(f, g)))) 這樣的代碼，認為深度嵌套函數可以大大減少中間變量，從而節省代碼量；有些學生喜歡用邏輯運算符連接各種條件邏輯，并將它們全部寫在一行，如 a || b && c && d常見的還有實用函數的參數越來越多，直到一次性傳入一行。

再考慮一下，這樣的代碼是否增強了可讀性。深度嵌套的函數調用帶來了許多右括號，如 )))))), 這在 Lisp 中早已備受詬病；單行條件邏輯不利于調試；具有許多參數的函數往往表現復雜，難以調試。

這些編碼習慣可以很容易地以更好可讀性的形式替換，而不會帶來太多麻煩。然而，故意創建這樣的代碼可能會使后續的維護人員感到不適。對于行間斷和縮進的具體實踐，工具如 JavaScript Standard Style 可以自動處理大多數情況。

隱式重寫常識

現代工程框架通常提供許多可定制的接口，允許開發人員輕松修改框架的行為。例如，React 公開了上下文，而 Redux 和 MobX 等庫利用這個接口大大優化了深度 prop 傳遞的體驗。然而，在典型業務代碼中，框架內的許多隱含約定和規范，如果不合理地進行定制，會導致重大挑戰。這些類型的修改通常發生在不起眼的地方，但可能有很大的影響。

例如，在我們之前維護的一個項目中，有一個巧妙的修改，用自己的 XXX.BaseComponent 替換了 React.Component 基類。自定義組件沒有涉及任何與業務邏輯相關的更改，而是添加了一些無法解釋的初始化代碼。結果是關于 React 組件基類的隱含常識失效了。在維護時，乍一看替換的組件看起來很普通；然而，回滾會導致問題。此外，這些“黑魔法”代碼沒有注釋或文檔，不清楚最初引入它們是為了什么問題。對于這種編碼實踐，除了過于聰明之外，似乎沒有其他合理的評價。

另一個例子是這個項目中的另一個“聰明”做法，即根據請求路徑用三四個不同的自定義版本替換 window.fetch（不用擔心——不會告訴你為什么！）。這意味著當維護人員編寫新的 fetch 請求時，不能依賴之前關于 fetch 的任何隱含知識，而必須通過追蹤前任的自定義版本進行調試——這很神奇，不是嗎？

還有一些隱式實踐，問題出在副作用上。例如，當看到 user = getUser(id) 時，可能不會期望這個 getUser 函數不僅查詢用戶，還悄悄顯示提示消息、發送請求并清除當前數據。當然，在前端開發中，管理眾多與 UI 相關的網絡副作用本身增加了復雜性。然而，如果調用一個函數會導致許多連鎖結果，進一步增加復雜性，許多維護人員可能會選擇棄用和重寫。

重新發明輪子

在技術社區中，你經常可以看到“最全面的前端實用函數”之類的合集，并且它們的點贊數往往很高。然而，一個 500 合 1 的小霸王游戲卡比超級馬里奧更有趣嗎？

我有幸讀過一些這樣的文章，發現這些打包的函數往往連固定主題都沒有：左邊是 getCookie，右邊是 deepClone，上面是 isEmail，下面是 scrollTop。每個實現只有幾行相當于將英文函數名翻譯成中文的注釋，沒有測試用例、依賴配置或文檔。它們被稱為“小而美”。

這樣的代碼值得復制到你的項目中重復使用嗎？坦率地說，它們只是滿足“我可以發明輪子”沖動的產品。當然，我完全相信作者可以輕松優雅地編寫一個深拷貝函數。但是項目不是面試；對于一個穩定可靠的輪子庫，除了簡單的實現外，還需要許多與代碼無關的東西。根據布魯克斯定律（《人月神話》）的軟件項目中，實際編碼時間只占 1/6；其余的大部分時間需要用于測試、文檔和溝通。對于具有更高質量要求的庫代碼，匆忙編寫或從網上復制（哦不！讓我們稱之為內聯）代碼能否滿足？

在正式項目中使用庫，如果穩定的現有依賴滿足需求，顯然應首先選擇。如果遇到需要自己重新發明輪子的情況，確保在可靠項目的5/6之外的時間也做好；不要不必要地重復劣質輪子。

追求高層次的抽象

最后一點可能更為小眾，因為對于許多人來說，復制粘貼即可滿足需求，這違反了他們的習慣。然而，正因為如此，這是一種更高級形式的“巧妙”。

[高級] 聽起來像是純粹的圣杯。[高階函數] 和 [高階組件] 似乎是 [高級程序員] 的完美搭配。然而，如果你需要維護這些高階函數，你會怎么想？

() => () => () => () => 123

一個返回 123 的函數，由另一個函數返回，確實很高層次。但是這會不會讓你感到困惑...

結語

在編程中，技巧和智慧是不可或缺的，但僅僅依賴技巧并不能保證代碼質量。通過理解和運用合適的設計模式、提高代碼可讀性以及避免不必要的復雜性，我們可以編寫出既高效又易于維護的代碼。這不僅是對技術能力的證明，也是對團隊合作和項目成功的承諾。