先说说最近两件让我有点诚惶诚恐的事情。第一件，是前段时间我花了一点时间去读了一点 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 循环的这种表现，只是规范这么规定了这种特殊情况下程序的表现。那其实规范原理的犄角旮旯里有太多的这些内容，我们就都要去学习？对我们平时编程有多大帮助？
回到我们的题目上来，我们面试前端工程师 JS 原理的目的到底是什么？从上面两件事情来看，我觉得面试者对 JS 原理掌握的深度并不与工作有利度产生绝对的正相关。
我们会看到很多面试题涉及到一些刁钻的原理，其实这并不适合来做第一轮的面试，因为做错了既不能证明面试者没有举一反三的学习能力也不能证明面试者没有顺藤摸瓜解决问题的能力。仅仅能证明他没有看过这几个不常用的知识点。而我们第一轮面试的应该是看面试者是否掌握了些通用的，容易踩坑的知识点。因为这直接影响到他写出来的代码的质量。如果基本知识点掌握了，那么我们再去深入的问问这些不太常用的知识点就能侧面的去看这个人是否有的专研精神。
直接上手就用刁钻的原理问题来面试的面试官可能不是想秀优越感，就是对如何考察面试者思路不清了。其实如果抛开面试这个问题，再想想到底什么是前段工程师，我们的着眼点是 JS，HTML，CSS？框架？原理？应该都不是，如果陷入了某种技术，那么就会发生我最一开始遇到的问题: 换一个环境原有的技术可能就失灵了。如何在具体的技术上再拔高一层我也有点困惑，如果以后有感悟我再来总结吧。
最后我想说明下，此篇只是我的感悟，而且我不是反对对原理的专研，而是希望不要为了学原理死抠原理。
