先說說最近兩件讓我有點坐臥不安的事情。第一件,是前段時間我花了一點時間去讀了一點 ES6 規範。對於第一次讀規範的我是比較困難的,由於有不少術語及平時不常見的描述方式。通過幾個知識點的閱讀,我已經能讀得比較順暢,也掌握了規範層面的原理,我也頗有成就感。可是隨後當我開始入坑 react-native 並寫 demo 的時候,發生了很不爽的事情,就是我看不懂 demo 報的錯誤了。由於錯誤不是 JS 引發的錯誤,我忽然意識到 JS 在這種狀況下變成了僅僅是一種 DSL,而我寫了這麼多年的 JS,看了規範原理在這個時候竟然都用不上了。前端
第二件事情是我看了道 JS 的題目: 用 for 循環給一系列 dom 元素註冊 click 監聽函數,每一個元素被點擊後 alert 循環變量 i。問點擊元素後的表現?有必定經驗的工程師應該很快能反應過來,這題很常見: 點擊全部元素都會 alert 出相同的值( i 最後取值 )。若是要 alert 遞增的數字,那麼最典型的處理方式是在註冊監聽函數這段代碼外面加個當即執行的函數,把全局變量 i 賦值給閉包中的局部變量便可。那若是用 ES6 如何解決呢?只要用 let 去聲明循環變量 i,就能不用閉包來完成咱們原有的意圖。雖然我知道 let 建立的是局部變量,可是即便每次循環都是一個新建立的 i,那麼也解釋不通 let 聲明的 i 會遞增(明明每次循環都是一個新的 i )。而後去扒了規範,原來規範規定這種狀況每次循環要把上一次 i 的值賦值給當次新建立的變量 i。那麼問題來了,這種狀況下並不能用已知的 let 是聲明局部變量這個原理去推導出 for 循環的這種表現,只是規範這麼規定了這種特殊狀況下程序的表現。那其實規範原理的犄角旮旯裏有太多的這些內容,咱們就都要去學習?對咱們平時編程有多大幫助?react
回到咱們的題目上來,咱們面試前端工程師 JS 原理的目的究竟是什麼?從上面兩件事情來看,我以爲面試者對 JS 原理掌握的深度並不與工做有利度產生絕對的正相關。面試
咱們會看到不少面試題涉及到一些刁鑽的原理,其實這並不適合來作第一輪的面試,由於作錯了既不能證實面試者沒有觸類旁通的學習能力也不能證實面試者沒有順藤摸瓜解決問題的能力。僅僅能證實他沒有看過這幾個不經常使用的知識點。而咱們第一輪面試的應該是看面試者是否掌握了些通用的,容易踩坑的知識點。由於這直接影響到他寫出來的代碼的質量。若是基本知識點掌握了,那麼咱們再去深刻的問問這些不太經常使用的知識點就能側面的去看這我的是否有的專研精神。編程
直接上手就用刁鑽的原理問題來面試的面試官可能不是想秀優越感,就是對如何考察面試者思路不清了。其實若是拋開面試這個問題,再想一想到底什麼是前段工程師,咱們的着眼點是 JS,HTML,CSS?框架?原理?應該都不是,若是陷入了某種技術,那麼就會發生我最一開始遇到的問題: 換一個環境原有的技術可能就失靈了。如何在具體的技術上再拔高一層我也有點困惑,若是之後有感悟我再來總結吧。react-native
最後我想說明下,此篇只是個人感悟,並且我不是反對對原理的專研,而是但願不要爲了學原理死摳原理。前端工程師