摘要：避免脆弱的基類問題。紅牌警告沒有提到上述任何問題。單向數(shù)據(jù)流意味著模型是單一的事實來源。單向數(shù)據(jù)流是確定性的，而雙向綁定可能導(dǎo)致更難以遵循和理解的副作用。

原文地址

1. 你能說出兩種對 JavaScript 應(yīng)用開發(fā)者而言的編程范式嗎？

希望聽到：

2. 什么是函數(shù)編程？

希望聽到：

3. 類繼承和原型繼承的不同？

希望聽到

4. 函數(shù)式編程和面向?qū)ο缶幊痰膬?yōu)缺點？

希望聽到

5. 什么時候類繼承是一個合適的選擇？

希望聽到

6. 什么時候原型繼承是一個合適的選擇？

希望聽到

7.“贊成對象組合超過類繼承”是什么意思？

8.什么是雙向數(shù)據(jù)綁定和單向數(shù)據(jù)流，它們有何不同？

希望聽到：

9.單一與微服務(wù)架構(gòu)的優(yōu)缺點是什么？

希望聽到：

10.什么是異步編程，為什么它在JavaScript中很重要？

希望聽到：

結(jié)論

JavaScript 是多范式語言，支持 命令式/程序式編程，以及 OOP（面向?qū)ο缶幊蹋┖秃瘮?shù)編程。JavaScript 通過原型繼承支持 OOP。

希望聽到：

原型繼承（還有：原型，OLOO）

函數(shù)式編程（還有：閉包，第一等函數(shù)，lambadas（匿名函數(shù)））

紅牌警告：

沒有范式概念，沒有提到原型對象或函數(shù)編程

了解更多：

JavaScript支柱之一：原型面向?qū)ο?/p>

JavaScript支柱之二：函數(shù)編程

函數(shù)編程通過創(chuàng)建數(shù)學(xué)意義上的方法來避免共享狀態(tài)和修改數(shù)據(jù)來生成程序。Lisp 是最早支持函數(shù)編程的，受到 lambda 的啟發(fā)。Lisp 和 很多Lisp 家族語言至今仍然使用。

函數(shù)式編程是 JavaScript 基本概念。一些常見的函數(shù)工具在 ES5 中被添加。

希望聽到：

純函數(shù)

無副作用

單一功能構(gòu)成

函數(shù)式語言：Lisp，ML，Haskell，Erlang，Clojure，Elm，F(xiàn) Sharp，OCaml等等

提到支持函數(shù)式編程的特性：一等函數(shù)，高階函數(shù)，作為參數(shù)/值的函數(shù)

紅牌警告：

沒有提到純函數(shù)和避免副作用

不能提供函數(shù)式編程語言的例子

不能識別 JavaScript 中函數(shù)式編程的特點

了解更多：

JavaScript支柱之二：函數(shù)編程

不可變的東西

軟件構(gòu)成

Haskell 音樂學(xué)院

類繼承：繼承來自類（類似藍圖-類的一種描述），創(chuàng)建子類關(guān)系：等級分類法。通過構(gòu)造函數(shù)的 new 關(guān)鍵字實例化。類繼承可能在 ES6 中不允許使用 class 關(guān)鍵字。

原型繼承：實例繼承直接來自另一個對象。實例是通過工廠方法或者 Object.create()實現(xiàn)。實例可能從多個不同的對象中組成，允許容易地選擇性繼承。

在 JavaScript 中，原型繼承比類繼承更加簡單和可擴展。

希望聽到

類：創(chuàng)建緊密耦合或者層次結(jié)構(gòu)分類

原型：提到鏈接繼承，原型委托，函數(shù)繼承，對象組合

紅牌警告：

JavaScript支柱之一：原型面向?qū)ο?/p>

常見的JavaScript中的繼承誤解

OOP優(yōu)點：容易理解對象的基本概念，容易理解方法調(diào)用的意義。OOP 傾向使用命令式風(fēng)格而不是聲明式風(fēng)格，它讀起來像是直接指示計算機去做什么。

OOP缺點：OOP 典型地依賴共享狀態(tài)。對象和行為被一個實體跟蹤，也就是說任何數(shù)量的無序命令用函數(shù)可以隨機訪問，會導(dǎo)致像競爭條件一樣的不可描述的行為。

FP優(yōu)點：函數(shù)式范式，程序員可以避免共享狀態(tài)和副作用，也就消滅了同個資源的多個函數(shù)計算引起的bug。這種特性是 point-free風(fēng)格的可用性。相較于 OOP，函數(shù)傾向于快速簡單而容易的重組通用的可復(fù)用代碼。

函數(shù)式編程更喜歡聲明和聲明風(fēng)格，它不會一步步指示操作，而是結(jié)合要做的事，讓潛在的方法關(guān)系如何去做。這為重構(gòu)和性能優(yōu)化留下巨大的空間，甚至允許你替換全部算法只需要一點點代碼改變，這種更有效的方式（比如：內(nèi)存管理，使用懶惰評估替換有限評估）

利用純函數(shù)的計算也很容易在多個處理器或跨分布式計算集群中擴展，而不必擔(dān)心線程資源沖突，競爭條件等...

FP缺點：過度使用FP功能（如無點樣式和大型組合）可能會降低可讀性，因為生成的代碼通常更抽象地指定，更簡潔，更具體。

與函數(shù)式編程相比，更多人熟悉OO和命令式編程，因此即使是函數(shù)式編程中常見的習(xí)慣也會讓新團隊成員感到困惑。

FP比OOP有更陡峭的學(xué)習(xí)曲線，因為OOP的廣泛流行使得OOP的語言和學(xué)習(xí)材料變得更具會話性，而FP的語言往往更具學(xué)術(shù)性和正式性。 FP概念經(jīng)常被寫成使用來自lambda演算，代數(shù)和類別理論的習(xí)語和符號，所有這些都需要在這些領(lǐng)域中的先驗知識基礎(chǔ)被理解。

希望聽到

提到共享狀態(tài)的問題，競爭相同資源的不同事物等等......

意識到FP能夠從根本上簡化許多應(yīng)用程序。

意識到學(xué)習(xí)曲線的差異。

闡明副作用以及它們?nèi)绾斡绊懗绦虻目删S護性。

意識到功能強大的代碼庫可能具有陡峭的學(xué)習(xí)曲線。

意識到與同等的FP代碼庫相比，高度OOP代碼庫可以非常耐受變化并且非常脆弱。

意識到不可變性導(dǎo)致了一個極易訪問和可延展的程序狀態(tài)歷史記錄，允許輕松添加諸如無限撤消/重做，倒帶/重放，時間旅行調(diào)試等功能。 可以在任一范例中實現(xiàn)不變性，但共享有狀態(tài)對象的擴散使OOP中的實現(xiàn)變得復(fù)雜。

紅牌警告：無法列出一種風(fēng)格或另一種風(fēng)格的缺點-有經(jīng)驗的人對任何風(fēng)格都能說出一些限制。

了解更多

JavaScript支柱之一：原型面向?qū)ο?/p>

JavaScript支柱之二：函數(shù)編程

答案永遠不會，或者幾乎從不。 當(dāng)然永遠不會超過一個級別。 多級類層次結(jié)構(gòu)是反模式。 多年來我一直在發(fā)出這個挑戰(zhàn)，我聽過的唯一答案屬于幾種常見的錯誤觀念之一。 更常見的是，挑戰(zhàn)是沉默。

“如果某個功能有時很有用
有時很危險
如果有更好的選擇
然后總是使用更好的選擇?！?-- Douglas Crockford

希望聽到

很少，幾乎從來沒有，或從未。

從一個框架基類，如React.Component，單個級別有時是可以的。

“贊成對象組合而不是類繼承?！?/p>

了解更多

JavaScript支柱之一：原型面向?qū)ο?/p>

JS 對象-糟糕的繼承

原型繼承有多種類型：

授權(quán)（即原型鏈）。

連接（即mixins，Object.assign（））。

功能性（不要與函數(shù)式編程混淆。用于為私有狀態(tài)/封裝創(chuàng)建閉包的函數(shù)）。

每種類型的原型繼承都有自己的一組用例，但它們在啟用組合方面同樣有用，它創(chuàng)建了有一個或用一個或可以做一個的關(guān)系而不是使用類繼承創(chuàng)建是一個的關(guān)系。

希望聽到

在模塊或函數(shù)編程沒有提供明顯解決方案的情況下。

當(dāng)需要從多個來源組合對象時。

任何時候你需要繼承。

紅牌警告：

不知道何時使用原型。

沒有意識到mixins或Object.assign（）。

了解更多

JavaScript 程序設(shè)計

這是“設(shè)計模式：可重用的面向?qū)ο筌浖脑亍钡囊谩?這意味著代碼重用應(yīng)該通過將較小的功能單元組裝到新對象中而不是從類繼承并創(chuàng)建對象分類來實現(xiàn)。

換句話說，使用can-do，has-a或 uses-a 關(guān)系而不是is-a關(guān)系。

希望聽到：

避免使用類層次結(jié)構(gòu)。

避免脆弱的基類問題。

避免緊耦合。

避免嚴格的分類（強制是一種新用例最終錯誤的關(guān)系）。

避免大猩猩香蕉問題（“你想要的是香蕉，你得到的是拿著香蕉的大猩猩，以及整個叢林”）。

使代碼更靈活。

紅牌警告：

沒有提到上述任何問題。

未能闡明構(gòu)成和階級繼承之間的差異，或組成的優(yōu)勢。

雙向數(shù)據(jù)綁定意味著 UI 表單被綁定，用來動態(tài)地建模數(shù)據(jù)，使得當(dāng) UI 表單改變時，模型數(shù)據(jù)隨之改變，反之亦然。

單向數(shù)據(jù)流意味著模型是單一的事實來源。 UI中的更改觸發(fā)消息，指示用戶對模型的意圖（或React中的“存儲”）。 只有模型才有權(quán)更改應(yīng)用程序的狀態(tài)。 結(jié)果是數(shù)據(jù)總是在單一方向上流動，這使得它更容易理解。

單向數(shù)據(jù)流是確定性的，而雙向綁定可能導(dǎo)致更難以遵循和理解的副作用。

希望聽到：

React是單向數(shù)據(jù)流的新規(guī)范示例，因此提及React是一個很好的信號。 Cycle.js是單向數(shù)據(jù)流的另一種流行實現(xiàn)。

Angular是一種使用雙向綁定的流行框架。

紅牌警告：

不了解任何一個意味著什么。 無法闡明差異。

單一體系結(jié)構(gòu)意味著您的應(yīng)用程序是作為一個有凝聚力的代碼單元編寫的，其組件旨在協(xié)同工作，共享相同的內(nèi)存空間和資源。

微服務(wù)架構(gòu)意味著您的應(yīng)用程序由許多較小的獨立應(yīng)用程序組成，這些應(yīng)用程序能夠在自己的內(nèi)存空間中運行，并且可能在許多不同的機器上相互獨立地進行擴展。

單一優(yōu)點：單一架構(gòu)的主要優(yōu)勢在于大多數(shù)應(yīng)用程序通常都有大量的交叉問題，例如日志記錄，速率限制以及審計跟蹤和DOS保護等安全功能。

當(dāng)一切都在同一個應(yīng)用程序中運行時，很容易將組件與這些跨領(lǐng)域的問題聯(lián)系起來。

還有性能優(yōu)勢，因為共享內(nèi)存訪問比進程間通信（IPC）更快。

單一架構(gòu)缺點：隨著應(yīng)用程序的發(fā)展，單一應(yīng)用程序服務(wù)往往會緊密耦合并糾纏在一起，因此很難將服務(wù)隔離，例如獨立擴展或代碼可維護性。

單一體系結(jié)構(gòu)也很難理解，因為當(dāng)您查看特定服務(wù)或控制器時，可能存在依賴性，副作用和魔法，這些并不明顯。

微服務(wù)優(yōu)點：微服務(wù)架構(gòu)通常組織得更好，因為每個微服務(wù)都有非常特定的工作，并且不關(guān)心其他組件的工作。解耦服務(wù)也更容易重構(gòu)和重新配置，以滿足不同應(yīng)用程序的需求（例如，同時提供Web客戶端和公共API）。

它們還可以具有性能優(yōu)勢，具體取決于它們的組織方式，因為它可以隔離熱服務(wù)并將其擴展為獨立于應(yīng)用程序的其余部分。

微服務(wù)缺點：當(dāng)您構(gòu)建新的微服務(wù)架構(gòu)時，您可能會發(fā)現(xiàn)許多在設(shè)計時沒有預(yù)料到的跨領(lǐng)域問題。一個單一的應(yīng)用程序可以建立共享的魔術(shù)助手或中間件來處理這些跨領(lǐng)域的問題，而不需要太多的努力。

在微服務(wù)架構(gòu)中，您需要為每個交叉問題產(chǎn)生多帶帶模塊的開銷，或者將交叉問題封裝在所有流量路由通過的另一個服務(wù)層中。

最終，即使是單一的體系結(jié)構(gòu)也傾向于通過外部服務(wù)層來傳輸流量以解決交叉問題，但是采用單一體系結(jié)構(gòu)，可以延遲這項工作的成本，直到項目更加成熟為止。

微服務(wù)經(jīng)常部署在他們自己的虛擬機或容器上，導(dǎo)致VM爭用工作激增。這些任務(wù)經(jīng)常通過容器隊列管理工具自動完成。

希望聽到：

盡管初始成本高于monolthic應(yīng)用程序，但對微服務(wù)的積極態(tài)度。意識到微服務(wù)從長遠來看往往會表現(xiàn)更好并且規(guī)模更大。

關(guān)于微服務(wù)與單片應(yīng)用程序的實用性。構(gòu)建應(yīng)用程序，以便服務(wù)在代碼級別彼此獨立，但在開始時很容易捆綁在一起作為單個應(yīng)用程序。微服務(wù)開銷成本可能會延遲，直到付出代價變得更加實際。

紅牌警告：

不了解單片和微服務(wù)架構(gòu)之間的差異。

對微服務(wù)的額外開銷沒有意識到或不切實際。

不知道IPC和網(wǎng)絡(luò)通信對微服務(wù)造成的額外性能開銷。

對微服務(wù)的缺點太負面了。無法明確解決單一應(yīng)用程序的分離方式，以便在時機成熟時將它們輕松拆分為微服務(wù)。

低估了獨立可擴展微服務(wù)的優(yōu)勢。

同步編程意味著，除了條件和函數(shù)調(diào)用之外，代碼從上到下依次執(zhí)行，阻止長時間運行的任務(wù)，如網(wǎng)絡(luò)請求和磁盤I / O.

異步編程意味著引擎在事件循環(huán)中運行。當(dāng)需要阻塞操作時，將啟動請求，代碼將繼續(xù)運行而不會阻塞結(jié)果。當(dāng)響應(yīng)準備就緒時，將觸發(fā)中斷，從而導(dǎo)致運行事件處理程序，控制流繼續(xù)執(zhí)行。通過這種方式，單個程序線程可以處理許多并發(fā)操作。

用戶界面本質(zhì)上是異步的，并且花費大部分時間等待用戶輸入來中斷事件循環(huán)并觸發(fā)事件處理程序。

默認情況下，節(jié)點是異步的，這意味著服務(wù)器的工作方式大致相同，在循環(huán)中等待網(wǎng)絡(luò)請求，并在處理第一個請求時接受更多的傳入請求。

這在JavaScript中很重要，因為它非常適合用戶界面代碼，并且非常有利于服務(wù)器上的性能。

希望聽到：

了解阻塞意味著什么，以及性能影響。

了解事件處理，以及為什么它對UI代碼很重要。

紅牌警告：

不熟悉異步或同步的術(shù)語。

無法表達性能影響或異步代碼與UI代碼之間的關(guān)系。

堅持高級主題。如果他們能夠回答這些問題，那通常意味著他們有足夠的編程經(jīng)驗可以在幾周內(nèi)獲得語言怪癖和語法，即使他們沒有很多JavaScript經(jīng)驗。

不要基于易于學(xué)習(xí)的東西（包括經(jīng)典的CS-101算法或任何類型的拼圖問題）取消候選人資格。

你真正需要知道的是，“這位候選人是否理解如何將應(yīng)用程序放在一起？”

這就是口語采訪。

在真實的采訪中，我更加強調(diào)編碼挑戰(zhàn)和觀察候選人代碼。這些主題在我的“掌握JavaScript面試”系列中有詳細介紹。