转自：前端外刊批评
异常谢谢，翻译的很好，受益许多，转到此处让前端小伙伴们也惊呆下……..
上次我写《前端工程师必知必会》已是三年前了，那是我写过最火的文章了。三年了，我依旧会在Twitter上收到关于这篇文章的音讯。
从2012年到如今，一篇文章都没发过让我认为有点羞羞哒。三年是一段很长的时刻，许多东西都发作了改变。2012年，我勉励同砚们去进修浏览器开辟者东西和模块化；虽然有许多同砚会认为CSS预编译和客户端模板引擎并不靠谱，但我依旧想要说一说它们；另有JSHint，虽然有#getoffmylawn（滚出我的土地）的正告，但依旧没法阻挠JSHint成为一个受欢迎的理念（正确的说，JSLint真的（只是）存在过）。
已是2015年了，我想写一篇新的，然则当我坐下来最先动笔的时刻，想到了两个事变。一，这些东西被称作“必知必会”能够有人会认为不太平正——假如你已认为2012年的那篇文章云云，那本文也是一样的了。或许有同砚会说，我们应当把 “充足敷衍营业需求的妙技” 作为 “前端必需控制的学问”，但斟酌到前端行业里也有林林总总的事情可供挑选，这么做也只能获得一个并不合适一切人的 “前端基础学问”。关于我来讲，我须要的不是事情，我想要的是被约请去做一份牛逼的事情。我想要的不只是去干活罢了，而是想和一群牛逼的人一同做牛逼的事。我不想仅仅满足于用已有的学问来完成如今的事情，而是愿望控制更多的学问来处理将来将会面临的题目。
第二，我如今已完整把Javascript作为我的中心了：CSS学问只要在必需关注机能题目时才会用到，其他场景已用的愈来愈少。我晓得有许多牛逼的前端同砚并非如许的，但我也意想到，关注JS的同砚和关注CSS的同砚之间的间隔也愈来愈远。这能够须要在另起一篇文章来议论，不过我想说的是，这篇文章中不会有引见CSS妙技范例的内容，因为我还远远没有到达能那末做的程度。
总之，就算这个妙技列表并不合适你的前端事情，没紧要，不要有压力，地球也不会爆炸。
Javascript
追念2009年，那时刻当你晓得 HTML5 在2014年才能用的时刻，你是否是认为这辈子基本上都用不到它了？假如是，那末你须要预备好接收希望迟缓然则已趋于稳定的ES6了，它也是下一代的Javascript（如今叫 ES2015 了，嗯，这名字最少示意本年就能够用了）。就我而言，ES6，额，ES2015 无疑是我个人如今最关注的 Javascript 内容。在 ES6 中将会涌现一些比较大的变化：类，真正的私有，经由革新更易用的函数和参数设定，可导入的模块，等等等等。那些控制和明白新的语法的同砚今后将会在 JS 社区牛逼闪闪。相干浏览：
- Understanding ES6，Nicholas Zakas 正在写的书。
- BabelJS，一个能够把你写的 ES6 的代码编译成 ES5 并在当代浏览器中运转的东西。他们也有一个不错的引见 ES6 的文档。
- ES6 Rocks，内里有大批的文章探究 ES6 的特征，语义和缺点。
你或许会问：那我须要成为一个 ES6 专家么？或许如今不须要，但最少你得和你的同事懂的一样多吧？或许比他们轻微多一点？固然，假如能在你的下一个新项目中作为一个娱乐性的手艺尝试也是不错的，做好预备一定没错的，因为我们永久不晓得下一刻会发作什么。
先不说新的言语特征，运用回折衷 promises 治理异步 Javascript 最少得背的倒背如流吧。浏览器端运用加载，以及运用间通讯战略得构成一套本身的看法吧。而且你应当晓得哪一种框架最合适你，而不是如今还把时刻花在明白种种框架的完成道理和该挑选哪一种框架上。
模块化和构建东西
毫无疑问，模块化是构建 Web 客户端运用的基石。回到2012年，关于运用哪一种模块化（AMD/CommonJS）计划构建浏览器端运用还存在许多争辩。而近来慢慢火起来的 UMD 则在保证代码可复用的前提下尝试防止如许的题目。 实在也没什么好争得，毕竟这俩玩艺儿之间也就差几个字符吧？
我认为相似如许的争辩实在并不都须要有一个答案，这也是我认为从2012年到如今我们发作的最大的改变，固然，或许只是我本身这么认为。因为我认为与其说“我再也不必 AMD 了”之类的话，倒不如多去议论 “在开辟和打包历程当中运用 CommonJS 和 npm 碰到的种种困难” 来的更有代价。
虽然很谢谢感动 RequireJS 曾对模块化做出的孝敬，不过如今我最先有点陶醉 webpack 了。 webpack 的构建设置比 RequireJS 越发易于明白，也更具接见性。经由历程它的热插拔特征和内置的当地静态效劳器能够让宣布越发便利。它并不强迫要求运用 AMD 或许 CommonJS – 两个它都支撑。它还完成了一大堆加载器，用来完成罕见的烦琐事情。 Browserify 也值得去相识一下，不过我个人认为它比 Webpack 落伍许多。一些靠谱的朋侪告诉我说 systemjs 也是这个范畴的竞争者，不过我还没有效过，而且它的文档烂的我连看都不想看。不过我认为它的好基友 jspm (包治理器)比较风趣，jspm 能够让你从种种包治理效劳器加载你须要的种种组件，(组件必需是相符 ES6, AMD, CommonJS and globals 范例的)，包含 npm, github 等，然则我关于这两个玩意的合体照样有点不太明白。啊，另有，虽然我说了这么多关于模块化以外的内容，但我从来没想过摒弃 AMD，我们边走边看吧。
我认为假如要住手对模块化和构建东西的争辩，构成一致的模块化体系，而且在这个体系内里，任何项目的代码都能够同享，而且还不须要 UMD 如许分外的补丁东西，我们另有很长的路要走。抱负状态下，ES6 modules 的到来会处理这些题目，不过在这一天到来之前，相似 UMD 之类的转换器会弥补这些空白，不过貌似如许做我们又把事变变得庞杂了，彷佛我们也总喜好把事变弄得庞杂。
与此同时，前端开辟人员也须要对构建东西，种种模块化体系有本身的看法和学问贮备。不管是好是坏，依据 Javascript 如今的进度，你的模块化战略会对你的项目有比较大的影响。
测试
客户端的代码测试变得愈来愈广泛，近来也诞生了一些新的测试框架： Karma，Intern 。我发明基于 promise 的 Intern 的异步测试要领相称文雅。不过多是因为习气，我大多数情况下照样用 Mocha 写测试用例。
测试的重要停滞实际上是前端开辟者的代码编写体式格局。我在2012年宣布过一个关于《编写可测试的Javascript》下载地点的演讲，紧接着几个月后又宣布了一篇相干的文章。
测试的第二大停滞是东西。Webdriver 是一个困难而庞大的事情。现在在各个浏览器端做延续集成的 UI 自动化测试基本上是不能够的，更不必说挪动端了。我们依旧停留在局限于某一小部分浏览器和装备上做轻量级的自动化功用测试，尽我们所能去研讨怎样疾速，低成本的举行这类测试的阶段。
假如你对怎样革新代码的可测试性感兴致的话，那末唯一一本最值得看的书是 Working Effectively with Legacy Code （中译版：《修正代码的艺术》。作者 Michael Feathers 定义了“遗留代码”的观点：任何未经测试的代码都是遗留代码。在测试范畴，最基本的要素就是上面这句话，只管你能够不这么认为。
流程自动化
你起首会想到 Grunt，这也是天经地义的。而 Gulp 和 Broccoli 的自动化构建体式格局也别出心裁。我没用过Broccoli，只玩过Gulp，我也最先意想到Grunt关于依靠其他效劳的庞杂使命的自动化事情存在局限性，尤其是当这类使命天天须要运转上千次的时刻。
Yeoman是在我写完2012年的那篇文章仅仅45天以后宣布的，我认可当时我并没有实时去尝试一下。不过近来我最先启动一些新项目，这些新项目有两个特性a) 这些项目都是从零最先b) 尝试用一些差别的手艺计划，试图经由历程这类体式格局找到 Bazaarvoice（供应第三方点评效劳）上第三方 JS 运用的范例化的开辟体式格局。Yeoman 在这两方面做的都很好。一个简朴的 yo react-webpack 敕令就能够为你初始化好你的项目，然后种种你想要的玩具也都无奇不有：天生测试用例，当地静态效劳器，hello world 入门顺序，等等等等。假如 React 和 webpack 不是你想要的，或许你会在 Yeoman 的 generators（项目天生器）内里找到一个你想要的，固然，本身自定义一个如许的构建包也是比较轻易的。
鉴于 Yeoman 只是一个在项目最先时才会用到的构建东西，而且鉴于我们并非老是做新项目，所以大多情况下相识一下就够了。除非，你也想去范例悉数项目开辟历程，那末它能够会更有代价一点。
Broccoli 已获得了 ember-cli 的采用，我认为他们的配对能够会有一个新名字，如许在将来才比较轻易和 Grunt /Yeoman 匹敌。而 Grunt 和 Yeoman 的开辟进度也放缓了，所以将来会发作什么，我们照样静观其变吧。
代码质量
假如你像我一样，一瞥见违背代码范例的代码时就最先抓狂，那末 JSCS 和
ESLint 就是老天赏给你的礼品，而2012压根就没这些玩意。他们都供应了自定义代码范例的体式格局，而且能够在代码提交前对你的代码做自动化校验。这让我想起了…
Git
从2012年到如今，github 的运用流程并没有发作很大的变化，比如在 pull request 页面连个分支名都没有（只是恶搞一下）。
你应当异常清楚和流畅地运用功用分支（feature branches）, 运用 rebase 兼并他人的代码干活，运用交互式 rebase 敕令和 squash 兼并提交纪录，或许尽量细颗粒度的分别项目内容，防止引发代码争执。另一个可用的 Git 东西是钩子，详细而言，就是你能够在 push 前，commit 前，实行你的种种测试用例，搜检代码质量。你能够本身写钩子，也能够运用 ghooks ，因为 ghooks 使钩子事情变得异常简朴，所以你几乎没有来由不必它。
客户端模板
这多是我在2012年的那篇文章中写的最烂的内容了，某种意义上的“烂”。客户端模板照样很有代价的，而且它已被内置到 ES2015 内里了，这不仅仅只是一件功德罢了。这些年也有一些沉重的经验，不少团队把一切的衬着事情悉数丢到浏览器端去做，效果产生了严峻的机能题目，所以 “在浏览器端衬着天生一切 HTML” 的做法天经地义的被摒弃了。 而更加智慧的做法则是，把 HTML 天生放在效劳器端，或许经由历程预编译的体式格局，先将模板做为静态资本储存起来，在须要时疾速的编译成 HTML，须要更新时也能够直接在客户端更新模板。
这里会有一些新的瞻望，不仅是对我本身，也是对一切人，当你在斟酌机能题目时，或许没必要把本身完整限定在浏览器范围内。所以，这又让我想起了……
Node
据说你懂 Javascript，那末我认为你也应当懂 Node，最少在碰到 Node 题目是能帮得上忙的，假如立刻都帮不上，那也最少深切研讨一下吧：Node 的文件体系，流，效劳器，完整差别于前端的一些开辟形式等等。对后端敬而远之只会限定我们前端的发展潜力。
纵然你的实在临盆环境中后端不必 Node，当你的事情被后端限定或障碍的时刻，Node 也是一个异常有效的东西。最起码，你也应当熟习怎样去初始化一个 Node 项目，怎样用 Express 搭建效劳器设置路由，怎样运用要求模块代办要求。
末了
谢谢 Paul, Alex, Adam, Ralph 对本文的 Review，谢谢他们绝不悭吝的指出我的不足之处，并给我提了很好的看法。
就如许，祝你好运。或许，三年以后我们会再会。
