【51CTO.com快译】一位前端开发者分享她的工作流与理想工具集选项。每个新项目总会带来一段令人兴奋的旅程，但糟糕的规划也可能毁掉这一切。人们往往将前端开发工作流程视为繁琐且优先级较低的任务，但由此带来的后果往往会在生命周期当中出现。
事实上，工程技术的本质就是提升产品水准、从以往错误中总结经验，而后制定出一套精简的实施流程。我们应当将这些原则运用到流程当中，从而在项目开始时即建立起可供每位开发者使用的规则、工具与技术选项。如此一来，产品本身亦将更加灵活、可扩展且易于维护。
作为一名前端工程师，我总会在开始新项目前确保工作流程的明确性与组织性。下面，我将与大家分享自己的整个设计过程。
1. 设置一套任务运行器
有些朋友可能不太熟悉任务运行器，这实际上就是一种用于自动执行重复任务的软件。其适合处理的任务包括JavaScript压缩、文件连接、复制文件/目录、执行脚本以及编译CSS文件。任务运行器通常立足于命令行，允许开发者“观察”特定文件或者目录的变化，而后在适当时运行任务。
在这方面，我个人推荐Grunt与Gulp。关于二者孰优孰劣的问题，恐怕很大程度上取决于使用习惯。Grunt以配置为核心，较为笨拙缓慢，但却易于上手且拥有庞大的技术社区。Gulp需要更为复杂的操作流程，但速度却更好。
下面来看二者的优劣总结：
Grunt
+ 易于上手
+通过配置实现更高控制水平
+发展历史更久，社区规模更大，插件选项更多
–非流式文件I/O使其速度较慢
Gulp
+ 需要配置的部分较少
+ 处理速度更快
+流式机制，允许异步文件处理
+ 代码编写需求更低
–API较为有限
Grunt与Gulp都运行在Node.js之上，因此团队中的每位开发者都需要首先安装Node.js。
另外一种适合由任务运行器负责的任务为编译模板语言，例如Jade。
2. 定义CSS流程
接下来，大家需要选择一种CSS方法，答案可以是BEM、SMACSS或者Atomic CSS。具体选择同样取决于您的个人喜好。我自己使用的是BEM，其易于学习且能够在大型团队中用于高效处理各类应用组件。
在决定了CSS的编写规则之后，大家应当考虑如何编写CSS代码。结合当下趋势，大家都在利用Sass或者Less编写更为简洁的CSS代码。然而，CSS4很可能在不久的将来彻底取代这些“语言”。
考虑到预处理机制会给构建流程增加额外的时间投入，因此应当讨论其是否必要。例如，如果大家选择使用BEM，则可能不再需要使用Sass或者Less中的嵌套功能优势。
使用Compass等Sass库能够显著提升Sass的功能性，引入包括sprite-map生成、跨浏览器混合、文件读取以及数学辅助函数等，这一切都能让开发者在其CSS中实现更多效果。不过需要注意，使用Sass与Compass的前提是要求每位开发者预先安装Ruby。
另外，大家可以利用postcss等JS插件对CSS进行后处理。作为可扩展插件，postcss允许大家自动根据浏览器支持需求添加浏览器前缀、检查CSS、压缩文件并生成sprite等。我也在使用postcss，这里向大家强烈推荐。
3. 制定JavaScript规则
这也是开始新项目中最令人兴奋的部分，正确处理亦能够切实降低后续的技术债务。大家可以整理出一些严格的要求，包括JS如何编写、使用哪套框架以及设计模式等。
编写哪种风格的JavaScript？ES 5、ES 6+、TypeScript还是其它？
这是个大问题，而且往往很难找到惟一的正确答案。
ES5
ES5的优势在于，它能够帮助所有开发者更为顺畅地使用JavaScript，面对易于理解的结构并掌握如何使用各类动态语言特性。对于经验丰富的开发者而言，其不会带来任何学习曲线，且全部主流JS MVC框架皆能够支持ES5。
当然，其***缺陷在于迫使开发者继续编写平淡无奇的陈旧JavaScript代码。其冗长、松散且面向对象的传统语言特色使其无法吸引使用C#、Java以及Ruby等语言的开发者。根据我的个人经验，JavaScript会给新手软件开发者带来陡峭的学习曲线。
“Undefined不是函数？？这是什么意思？？！”——每位软件开发者肯定都有过这样的疑问。
ES6+
ES6代表着JavaScript的未来——或者会是ES7？总之，利用现代语言标准编写代码以应对未来需求绝对是个正确的选择。ES6提供一系列***吸引力的语言特性：类、接口、Lambda函数、模块导入/导出功能以及其它多种能够在“真正的”编程语言中发现的元素。
ES6的缺点在于，大家仍然需要将代码转译为ES5以获得更为广泛的浏览器、服务器与操作系统支持。这虽然不是什么大问题，且相信能够在不久的将来得到解决，但就目前来讲其仍在构建流程中增加了额外的步骤。另外，其确实会带来学习曲线，但这同时也是提升开发团队技能水平的好机会。
TypeScript
TypeScript是微软针对JavaScript自身不足给出的解决办法。其优势包括ES6+中包含的一切提升，同时亦面向Visual Studio提供工具，且受到Angular v2的大力支持。TypeScript旨在通过添加更多现代语言特性以实现JavaScript的可扩展性，同时帮助开发者更轻松地立足.NET开发环境。
在缺点方面，大家仍然需要将TypeScript转译为ES5，且面对相关学习曲线。
而这就引发了下一个问题。
我们该使用哪套JavaScript框架？
目前市面上的JavaScript框架不计其数，因此我们几乎很难确定下惟一***的一款。相反，我们在这里选择了最出色的三种，分别为Angular、Ember与Backbone。三者皆拥有相对悠久的发展历史，因此成熟度更高且具备规模可观的社区资源库。另外，三者分别采用区别明显的方式构建应用程序。下面来看它们的优缺点：
Angular
Angular v2是我个人的首先方案，其具备与Angular v1相同的出色体验，我也期待着能在下一个项目中使用其***版本。
+ 极高的原型设计与构建速度
+ 为TypeScript与Dart提供说明文档
+ 可轻松配合Jasmine与Karma实现测试驱动型开发
+ 大量独有功能
– 大量独有功能
– 要求开发者必须遵循Angular独有的方式进行开发
Ember
良好的中间性选项。
+ 组件驱动型特性
+ 独有功能少于Angular，但多于Backbone
+ 使用handlebars模板引擎
+ CLI
+ 可经由CLI轻松实现测试
Backbone
老派而又纯粹的框架
+ 几乎不具备任何独有功能
+ 可对设计模式、代码样式以及架构进行全面控制
+ 部分***影响力的应用与网站皆运行于Backbone之上
+ 可选择您偏好的模板引擎
+ 基本上属于简洁版HTML，无需额外属性
– 要求使用大量样板代码
– 不存在依赖性，但可配合Marionette等视图框架提升使用体验
– 总体代码编写量要求更高，但亦可借此实现更佳优化
– 自带测试环境
总结
通过以上探讨，下面我来汇总自己理想中的***前端开发流程：
- Grunt负责任务运行
- Sass负责CSS预处理
- Postcss负责后处理
- 编写TypeScript
- 利用 AngularJS进行构建
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
