前言
之前刷某乎的時候，看到這麼一個問題：“如何衡量一個人的 JavaScript 水平？[2]”然後自己也不要臉地回答了一下這個問題。以下是我的答案：
原文如下：
A：看一個人寫代碼是否有規範，代碼是否壯健，是否可拓展，可讀性高不高，API設計是否合理。
這些都是長年累月積累下來的且獨立於編程語言以外的。
遠比把什麼手寫bind，原型鏈，閉包給背下來更有價值。
這才是證明你代碼水平的關鍵點。
Q：在面試的時候如何快速判斷出呢？
A：讓面試者設計個組件，不用寫，回答就行。從API設計，文檔編寫，項目結構，單元測試，編寫模式，性能優化等方面來回答。
有工作經驗的人，基本業務邏輯都能寫，但是寫的好不好，就是經驗跟能力以及學習力的體現 。
個人說明
首先來個免責聲明，以上的回答都是個人的經驗與見解，答案肯定不唯一，甚至不一定全對，所以求輕噴。
上面問如何在面試的時候快速判斷對方是否是高級前端的時候，我為什麼說是“設計組件”呢？
因為我覺得有一定實力的前端來說，“組件”這個概念是繞不過的，或者看過開源組件的源碼，或者自己寫過組件。
對於一般的業務問題，我相信作為一個從業了一定時間的開發者，無論水平如何，這都不是問題，但是如何區分這個開發者的水平，可以通過他寫的代碼來判斷，當然也不完全是，畢竟在996或者趕進度的時候，很容易就會為了完成快速出產品而寫，這種情況下代碼質量跟個人水平不一定能體現。
下面，我們以設計一個“按鈕（<button>）組件/<button>”為例，來探索這個問題。
首先“按鈕（<button>）/<button>”的作用這個我們是否明確？它是裝飾性的組件還是功能性的組件？
這個問題很簡單，“按鈕（<button>）”是一個功能性的組件，是讓用戶通過點擊或觸碰來採取行動並做出選擇的一個組件。/<button>
場景
那麼“按鈕（<button>）”通常放在什麼地方？有經驗的開發可能會想到以下場景：/<button>
•對話框•模態窗口•表單•卡片•工具欄
代表狀態可能會有以下幾種：
•默認狀態•初始狀態•信息狀態•警告狀態•危險狀態
形態可能會有以下幾種：
•實心按鈕•文本按鈕•描邊按鈕•圖標按鈕•圓角按鈕•直角按鈕
尺寸可能會有以下幾種：
•small•medium•large
操作性可能會有以下幾種：
•回車鍵點擊•鼠標點擊•觸摸點擊•禁止點擊
攜帶的事件可能有以下兩種：
•click事件•回車鍵keydown事件•tap事件
以上雖然是偏樣式，但是作為一個組件開發者，這都是我們日常所需要考慮的。
API
在API的設計環節，我們通過上述的場景，我們可能會暴露出以下的API
•type：按鈕狀態•size：按鈕尺寸•color：按鈕顏色•text：按鈕內的文本•icon：按鈕內的圖標•htmlType：原生按鈕支持的type屬性•attrs：其他的原生屬性•variant：按鈕形態•click：鼠標點擊事件•tap：觸摸屏點擊事件•keydown：回車鍵按下事件
編寫核心邏輯
在我們API設計好之後，我們就可以開始開發了，這時候根據我們項目的類型，選擇的開發工具以及模式，可能會有所不同。
我們是獨立編寫還是直接在項目裡面去編寫，如果是獨立編寫，選擇哪個打包工具，是gulp還是webpack還是其它，為什麼這麼選？
例如如果我們是用TS寫，我們可能需要編寫Button.d.ts，如果是vue的組件，我們還得考慮Vue.use注入到Vue中，也就是Button.install(vue)，如果是react，我們還得考慮是否使用React.forwardRef來進行ref轉發。
然後就是我們的代碼規範，是用Function還是Class，共同的代碼塊如何抽象，如何，還有命名規範是什麼，哪些屬性必選，哪些屬性可選，默認值是什麼？我們是怎麼考慮的？
所以最終的組件使用可能會是這種形式：
<code>import Button from './componenet/Button'<button>添加/<code>
單元測試
在我們開發的過程中，有一道麻煩但又必不可少的工序就是單元測試，這時候單元測試的庫我們是怎麼選？用Jest還是Mocha？測試用例怎麼寫？如何模擬點擊或者異步響應？是否需要快照（snapshots）？這也是在我們的考慮範圍內。
所以我們的測試腳本可能長這樣：
<code>import Button from './componenet/Button'import { shallow } from 'enzyme'describe('<button>', () => { it('render success', () => { const wrapper = shallow(( <button>添加 )) expect(wrapper.text('添加')).to.equal(true) })})/<code>其它
其它的諸如開發文檔，使用文檔，版本迭代，項目配置，打包開發優化，以及其他自動化的功能，也是我們所需要考慮。
總結
以上便是我們在開發一個“按鈕（<button>）組件/<button>”時可能會考慮到的點，可能有不夠完善的地方，但是我想說的意思是，這其實可以很好的衡量一個人的JavaScript水平。比如你再會手寫原型鏈關係圖，閉包，防抖，節流等基礎概念，但是如果不在項目中運用起來，終究是紙上談兵，對技術水平沒有太多實質的幫助，當然不是說精通這些內容不好，但是比起實戰，還是差強人意。
能手寫代碼的不一定是高級，但是如果能寫好一個組件，水平再差也不會差到哪裡去。
本文似乎有點文不對題了，本來談的是“如何衡量一個人的JavaScript水平”，結果卻超綱了許多。但是通過這種方式，確實能夠判斷出一個人代碼水平，當然也並不只是JS，換成安卓，IOS也同樣適用。
不知道你是通過什麼方式來衡量一個的JavaScript水平的呢？歡迎留言區域回覆互動。
閱讀更多 極光學苑 的文章
