| 本文从ES2015、模块和构建工具、测试、过程自动化、代码质量、Git、客户端模板、Node等方向全面介绍了前端开发者必须了解与掌握的技术与工具。尤其对于JS开发者，是一份很好的开发指南。 【编者按】感谢@lenville对《A Baseline for Front-End [JS] Developers: 2015》的翻译，该文章全面而系统地介绍了前端开发者所应掌握的关键技术及最流行、实用的工具，尤其对于JS开发者大有裨益。 大约三年前，我写了一篇《 前端开发者的基本技能》，嗯，那大概是我最出名的一篇文章。三年后，仍然有人在Twitter上@我询问如何开始学习前端知识。 在某种程度上，我曾经写下的文字历经了时间的考验：令我感到震惊的是，2012年我写的那篇文章并没给我带来难堪的问题。尽管如此，3年之久，很多 事情都变得与众不同。2012年我鼓励人们学习浏览器开发工具，紧跟模块化开发大潮；那时候人们还不太接受CSS预处理和客户端模板这类新事物，它们仍然 值得一提；相比于JSLint锱铢必较的精确（甚至让人感到厌烦），JSHint非常受欢迎，它使我们彻底解放。 现在时间来到了2015年，我想写一个升级版的前端指南，但是当我坐下动笔开始写的时候，我突然意识到两件事情： 相对来说，称这篇文章为基本技能是不公平的，如果你回忆起以前的文章，你会发现这篇文章仿佛偏离了基础。人们可能会争辩说，我们应该考虑那些能让我 们找到工作的技能来作为基本技能。但是事实上，市场上有很多前端的工作可以选择，为了得到一份工作你并不需要太多的基础。于我而言，我并不想简单找一份工 作了事，我希望参与到一份绝妙的工作中去；我不想简单工作就度过一整天，我希望能够与有才能的人一起工作；我不想从事那些已经被大众所熟知的，坐在这里稍 作思考，预计差不多明天之前就可以完成的那种工作，我希望从事那些，因为我知道如何去工作，我能在明天之前钻研出一个成果，所以我明天可以顺利完成任务的 工作，对，就是有挑战的那种！ 我的世界正在变得彻底以JavaScript为中心：除了一些必要的性能优化，我的日常工作接触到的CSS知识越来越少。我知道有许多非常聪明的前 端开发者，他们的JS和CSS技能都很厉害，但是根据我的观察，专注研究JavaScript和专注研究CSS的人们正在逐渐分离。我大概可以写另外一篇 博文来阐述这个话题，但在这里我只想说：我没有做过多有关CSS的准备，所以不要对这一点抱有过多的期许。 简而言之：当你以你的前端世界的视角来阅读这篇文章，不一定能找到你需要的内容。但请谨记，我们都是很棒的开发者！ JavaScript 记忆回到2009年，如果你在文章里读到类似“HTML5将会在2014年定稿使用”的预言，是否看起来那一天还很遥远？如果当时你这样想，你将要准备好迎接缓慢更新但是稳步向前的ES6（现在被称为 ES2015，这个名称已经随处可见），也就是下一个版本的JavaScript。准备与ES6——啊不对，ES2015——接轨吧，毫无疑问，这是接下来在JavaScript领域中最重要的事情。ES6 classes、真正的隐私、更好的函数和参数、可引入（import）的模块以及许多其它特性，一定会彻底改变游戏规则。那些能力十足并且十分高产的新语法无疑将会彻底从JS社区中孕育出来。为此，你需要阅读：
新的语言特性先暂且不谈，你应该能够流利地说出JavaScript的异步模式，并且使用回调和promise来管理它。关于在浏览器中加载应用并在每个应用之间通信的策略，你应该拥有足够完备的见解。你也许应该掌握一个你非常喜欢的应用开发框架，同时也应该对其它的框架是如何运行的有一个概览，你需要稍作权衡选择你喜欢的那一个。
模块和构建工具 毫无疑问，模块应当是客户端Web应用的构建元素。回到2012年，关于使用什么类型的模块来构建浏览器应用的讨论此起彼伏，不过基本围绕着 AMD和 CommonJS展开。还有一个略显粗俗的 UMD包装器尝试融合二者来方便大家重用代码——他们认为，既然长得差不多，不如多写点儿代码来同时支持二者。 我认为这场争论没有一个统一的结论，但是我感觉这是自2012年我写文章之后，这个领域中最大的转变，当然这也可能只是我个人的心路历程。我没有彻底搞定AMD，但是我被它的实用性征服了，你可以使用CommonJS开发并部署Web应用，使用npm引入模块。 RequireJS为模块通信做了很大的贡献，出于对它的厚爱，我现在有点儿迷恋W ebpack了。 webpack的功能——例如容易理解的构建参数（译者注：build flag，命令行中形如-p的参数）——相比于RequireJS来说更容易理解。通过它的内建开发服务器实现的热交换构建打造了一个快速且令人愉悦的开 发传奇。它并不强制你使用AMD或者CommonJS，因为它同时支持两者。还有非常多的加载器，使得完成许多相同工作对它来说简直是小意思。你也可以去 了解一下 Browserify，但在我看来，一定要在熟悉了Webpack之后再去搞它，我信任的聪明人儿告诉我， systemjs在这个领域也是一个的认真的竞争者，但是我还没用它呢，它的文档让我很想拜读。它的包管理器 jspm很迷人，允许你从包括npm在内的不同的源拉取所需的模块，但是我有点儿担心这俩货结合起来会有些问题。我不得不重复，我从没想过我会与AMD分开，但是看起来我不得不放弃它了，我们终将会看到这事情的发生。 我仍然渴望有一天我可以停止喋喋不休地争论有关模块和构建工具的话题，那时候全世界只有一个模块系统，这样就可以在所有项目里共享使用代码，同时还 能免去使用UMD的开销。理想情况下，那一天将会因为ES6模块而变为现实——在这一天到来前你可以使用转译器（Transpiler）来填补空缺——但 我发现很有可能我们会持续不断地找一些方法让它变得愈发复杂。 与此同时，前端开发者需要了解至少一对构建工具和相关的模块系统，这需要在实践中不断积累经验。不管怎样，就目前JavaScript的发展情况来说，你仍然需要选择一个模块系统，它将支撑你的每一个项目。 测试 一些新的测试框架，例如 Karma和 Intern，已经让客户端代码的测试变的轻而易举。我发现Intern基于promise来进行异步测试的方法特别（作者拼错了particulary）爽，我不得不承认，大多数时候我依然用Mocha来写测试——有时我还真就是屈于习惯的生物啊。 测试过程中的主要阻碍是前端开发者倾向于写的代码，关于这个问题，我在2012年末公开谈论了有关 编写可测试的JavaScript的话题，几个月后随即写了一篇有关这个话题的 文章。 测试过程中第二个大的阻碍是工具化，Web驱动仍然是你需要处理的巨大伤痛。一个复杂UI在所有支持平台上的持续自动化测试依然不可行，即使可行开 销也非常巨大，以致于那看起来根本不可能实现——更别提移动端了。很大程度上我们仍然局限于在浏览器、设备、操作系统结合的支持平台的很小的一个子集上做 一些轻量级自动化功能测试，并且越来越难以依赖可以快速、便宜地运行的底层测试。有时候想想这个问题就觉得自己弱爆了。 如果你对改进未经检验（不可测试）的代码问题感兴趣，有一本书非常值得一读： Working Effectively with Legacy Code，作者Michael Feathers将“遗留代码”定义为任何没有测试的代码，在测试的话题上，唯一的底线是接受这一说法的真实性，即使其它约束会阻止你解决它。 |
