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

原文地址

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

希望聽(tīng)到：

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

希望聽(tīng)到：

3. 類(lèi)繼承和原型繼承的不同？

希望聽(tīng)到

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

希望聽(tīng)到

5. 什么時(shí)候類(lèi)繼承是一個(gè)合適的選擇？

希望聽(tīng)到

6. 什么時(shí)候原型繼承是一個(gè)合適的選擇？

希望聽(tīng)到

7.“贊成對(duì)象組合超過(guò)類(lèi)繼承”是什么意思？

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

希望聽(tīng)到：

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

希望聽(tīng)到：

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

希望聽(tīng)到：

結(jié)論

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

希望聽(tīng)到：

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

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

紅牌警告：

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

了解更多：

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

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

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

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

希望聽(tīng)到：

純函數(shù)

無(wú)副作用

單一功能構(gòu)成

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

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

紅牌警告：

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

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

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

了解更多：

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

不可變的東西

軟件構(gòu)成

Haskell 音樂(lè)學(xué)院

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

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

在 JavaScript 中，原型繼承比類(lèi)繼承更加簡(jiǎn)單和可擴(kuò)展。

希望聽(tīng)到

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

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

紅牌警告：

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

常見(jiàn)的JavaScript中的繼承誤解

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

OOP缺點(diǎn)：OOP 典型地依賴(lài)共享狀態(tài)。對(duì)象和行為被一個(gè)實(shí)體跟蹤，也就是說(shuō)任何數(shù)量的無(wú)序命令用函數(shù)可以隨機(jī)訪問(wèn)，會(huì)導(dǎo)致像競(jìng)爭(zhēng)條件一樣的不可描述的行為。

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

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

利用純函數(shù)的計(jì)算也很容易在多個(gè)處理器或跨分布式計(jì)算集群中擴(kuò)展，而不必?fù)?dān)心線(xiàn)程資源沖突，競(jìng)爭(zhēng)條件等...

FP缺點(diǎn)：過(guò)度使用FP功能（如無(wú)點(diǎn)樣式和大型組合）可能會(huì)降低可讀性，因?yàn)樯傻拇a通常更抽象地指定，更簡(jiǎn)潔，更具體。

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

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

希望聽(tīng)到

提到共享狀態(tài)的問(wèn)題，競(jìng)爭(zhēng)相同資源的不同事物等等......

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

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

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

意識(shí)到功能強(qiáng)大的代碼庫(kù)可能具有陡峭的學(xué)習(xí)曲線(xiàn)。

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

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

紅牌警告：無(wú)法列出一種風(fēng)格或另一種風(fēng)格的缺點(diǎn)-有經(jīng)驗(yàn)的人對(duì)任何風(fēng)格都能說(shuō)出一些限制。

了解更多

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

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

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

“如果某個(gè)功能有時(shí)很有用
有時(shí)很危險(xiǎn)
如果有更好的選擇
然后總是使用更好的選擇。“
-- Douglas Crockford

希望聽(tīng)到

很少，幾乎從來(lái)沒(méi)有，或從未。

從一個(gè)框架基類(lèi)，如React.Component，單個(gè)級(jí)別有時(shí)是可以的。

“贊成對(duì)象組合而不是類(lèi)繼承。”

了解更多

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

JS 對(duì)象-糟糕的繼承

原型繼承有多種類(lèi)型：

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

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

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

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

希望聽(tīng)到

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

當(dāng)需要從多個(gè)來(lái)源組合對(duì)象時(shí)。

任何時(shí)候你需要繼承。

紅牌警告：

不知道何時(shí)使用原型。

沒(méi)有意識(shí)到mixins或Object.assign（）。

了解更多

JavaScript 程序設(shè)計(jì)

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

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

希望聽(tīng)到：

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

避免脆弱的基類(lèi)問(wèn)題。

避免緊耦合。

避免嚴(yán)格的分類(lèi)（強(qiáng)制是一種新用例最終錯(cuò)誤的關(guān)系）。

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

使代碼更靈活。

紅牌警告：

沒(méi)有提到上述任何問(wèn)題。

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

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

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

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

希望聽(tīng)到：

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

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

紅牌警告：

不了解任何一個(gè)意味著什么。 無(wú)法闡明差異。

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

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

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

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

還有性能優(yōu)勢(shì)，因?yàn)楣蚕韮?nèi)存訪問(wèn)比進(jìn)程間通信（IPC）更快。

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

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

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

它們還可以具有性能優(yōu)勢(shì)，具體取決于它們的組織方式，因?yàn)樗梢愿綦x熱服務(wù)并將其擴(kuò)展為獨(dú)立于應(yīng)用程序的其余部分。

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

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

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

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

希望聽(tīng)到：

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

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

紅牌警告：

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

對(duì)微服務(wù)的額外開(kāi)銷(xiāo)沒(méi)有意識(shí)到或不切實(shí)際。

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

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

低估了獨(dú)立可擴(kuò)展微服務(wù)的優(yōu)勢(shì)。

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

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

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

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

這在JavaScript中很重要，因?yàn)樗浅＿m合用戶(hù)界面代碼，并且非常有利于服務(wù)器上的性能。

希望聽(tīng)到：

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

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

紅牌警告：

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

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

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

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

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

這就是口語(yǔ)采訪。

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