镜像：https://www.sdk.cn/news/5412
书名：https://medium.freecodecamp.com/making-sense-of-front-end-build-tools-3a1b3a87043b#.ugfky3xr2
全文：即便对许多训练有素的开发人员而言，众多的后端辅助工具却是会让她们深感恶心，例如我。化解那个难题的最合适配套措施，是在基本概念上认知她们的组织工作形式，早已她们间互相配合的形式。
Node, NPM, Grunt, Gulp, Bower, Webpack, Browserify, Yeoman, Brunch……众多的术语让你一时间深感不知所措，好似显然学不完。
只不过关键性是，千万别被它鲁银投资。要晓得，大部份那些辅助工具，其起初的结构设计目地，都是要让你的组织工作显得更单纯。
要想弄晓得那些辅助工具是甚么、怎样组织工作和为甚么要采用它，你只不过只须要紧紧抓住极少数核心理念基本概念。
基本概念1：build辅助工具的三大核心理念机能，是“加装vs行事”
从其本质上说，开发辅助工具做的事就三个：
帮你加装东西
帮你行事
当你接触到一个新的开发辅助工具的时候，你首先须要搞清楚一个东西：“那个辅助工具的目地是帮我加装东西，却是帮我行事？”
加装类的辅助工具，比如npm、Bower和Yeoman几乎甚么东西都能装，它可以用来加装后端库，比如Angular.js或是React.js。它还可以为你的开发环境加装服务器。它可以加装测试库。它甚至可以帮你加装其他的后端开发辅助工具。
简而言之，任何你能想到的与代码有关的东西，它都能加装。
而帮你行事类的辅助工具，比如Grunt、Webpack、Require.js、Brunchu和Gulp则更加复杂一点。这类辅助工具的目标，是在web开发中帮你完成自动化。有的时候，这类辅助工具所做的事，被称为“任务（task）”。
为了完成那些任务，这类辅助工具经常须要自己的包和插件生态。每一个辅助工具都会采用不同的形式来完成任务。那些辅助工具所做的事也不尽相同。许多辅助工具，擅长处理那些你所指定的任务，比如Grunt和Gulp等辅助工具。还有许多辅助工具，只只专注于一件事，比如处理JavaScript的依赖，比如Browserify和Require.js等辅助工具。
有的时候，你在一个项目之中可能须要采用多种辅助工具。比如，我就曾在一个项目中采用了不同的辅助工具来将下列任务进行自动化处理：
在一个文件中替换文本字符串
创建文件夹，并且将文件转移到那些文件夹中
用一条单一命令运行单元测试
在我保存文件的时候刷新浏览器
大部份JavaScript文件整合为一个文件，将大部份CSS文件整合为一个文件
对大部份JavaScript和CSS进行简化处理
在html页面中修改<script>标签的位置
在你认知了后端辅助工具分为加装类辅助工具和帮你行事的辅助工具之后，你就可以轻松的对它进行归类：
基本概念2：build辅助工具的“祖宗”是Node和npm
Node和npm负责加装和运行大部份那些辅助工具，因此你的大部份项目中都会有它的身影。由于那个原因，很多开发人员在加装新的辅助工具之前，都会尽可能的尝试采用这三个辅助工具化解难题。
它三个一个负责加装，一个负责帮你行事。Node是行事辅助工具，而npm则是加装辅助工具。
npm可以加装Angular.js和React.js等库。它还可以加装服务器，让你的应用在开发阶段可以在本地运行。它还可以加装很多其他辅助工具，帮你完成很多事，比如简化代码。
而Node，则是帮你完成事的，比如运行JavaScript文件，和服务器等。
如果你刚刚开始学习，那么Node和npm都是必学的东西。随着你的项目不断丰富，你将会逐渐晓得这三个辅助工具的极限能力。当它无法满足你的须要的时候，是你须要开始加装其他辅助工具的时候了。
基本概念3：build只不过是production-ready版本的应用
开发人员经常会把JavaScript和CSS拆分成独立的文件。
独立文件的好处，是让你可以专注于编写针对性较强的代码，让每一部分代码只针对一个难题，以免日后代码多到让你自己都难以管理。但是当你的应用准备好被推向市场的时候，项目内存在多个JavaScript或是CSS文件并不是一个好主意。当用户访问你的网站的时候，每一个文件都须要独立的HTTP请求，这会让站点加载速度下降。
化解方法就是，给项目创建“build”，它要将大部份CSS文件合并成一个文件，然后再合并JavaScript文件。这样一来，你就可以将文件完成最小化。要想创建那个build，你须要采用build辅助工具。
下图是一个开发阶段的应用，注意到了吗，里面有5个<script>标签和3个<link>标签。看看左边，里面有的DEVELOPMENT文件夹中有10个文件。
开发阶段的应用
而下面这种图，则是同一个应用，不过它现在早已处于了bulid阶段。里面的<srcipt>标签和<link>标签的数量都编程了一个。而DEVELOPMENT文件夹被PRODUCTION文件夹替代，里面的文件数量也从10个变成了4个。
应用代码只不过并没有变，我们只是把代码显得看上去更简洁而已，这是所谓的“build”。
build阶段的应用
你可能会想，build这东西真的有必要吗？它的作用不过是节省用户几毫秒的时间而已。如果你的站点只有你自己，或者身边少数的几个人在开，那么你不用费劲的做build。但是如果你的站点或是应用有着较高的流量，那么你就必须做build。
因此，如果你只是在学习开发的阶段，或者你的站点流量较低，你没有必要花时间和精力去生成build。
念4：“加装”和“行事”间的界限有时会模糊
没有辅助工具只能做一件事，而无法做另一件事。大部份辅助工具都是“加装”和“行事”的结合体。但是一般而言，一个辅助工具会有自己的强项，或是强于加装，或是强于行事。
有的时候，一个加装类辅助工具也能运行文件。npm是这样，它也能运行命令和脚本，不仅仅是加装文件。
基本概念5：“最正确辅助工具组合”这么个东西不存在
采用哪些辅助工具，完全是你自己说了算的事。
你也可以选择什么辅助工具都不用。但是要记住，随着项目地发展，复制、黏贴、整合、开启服务器等事会让你慢慢手忙脚乱起来。
你也可以只采用Node和npm，其他辅助工具一概不用。对新手而言，这种形式很好，但是和上一条一样，慢慢你会开始深感力不从心。
或者，除了Node和npm之外，你也可以采用极少数其他辅助工具。那么，你的开发过程将会以Node和npm为核心理念，然后搭配Grunt和Bower，或是Webpack或是Gulp和Bower。
采用正确的辅助工具，能够帮你将很多繁琐的事实现自动化。但是采用辅助工具的代价，是你须要付出学习成本。
基本概念6：build辅助工具学习成本较高，因此你只须要学习你用的上的辅助工具
项目开发本身就早已很复杂了，你可能要采用新的语言或是框架。你可能须要应付复杂的业务逻辑。而引入新的辅助工具，只会让你的学习成本显得更高。
对此，我的建议是，只学习那些你用的上的辅助工具，其他的就先缓一缓吧。
学习任何一种新东西，最合适的形式是进行实践。比如，千万别为了学习Grunt而去学习，你可以在你的项目中去尝试运用。
基本概念7：大部份build辅助工具目标都一样：通过对大量低技术含量任务完成自动化，让你的组织工作显得更轻。
采用build辅助工具最开心的时刻，是我所谓的“build辅助工具涅槃”时刻，在那个时候，你会觉得自己充分发挥了辅助工具的大部份潜力。那个时刻，你是你保存了一个文件，或是运行了一条命令之后，成千上万个任务自动运行的时候。
如果你的辅助工具依然要求你手动移动文件、更改值、或是运行命令才能获得新的build，那说明你还没有迎来涅槃的时刻。
采用build辅助工具最大的好处之一，是在保存了一个文件之后，你就能创建一个新的build，并且将其发送到你的浏览器中。它能够显著的提升后端开发流程的速度。
那么我们应该在配置和调试build辅助工具的时候，应该付出多少精力？很单纯，如果你对当前辅助工具的效果深感满意，那就可以停止配置了。
基本概念8：不是你自己的难题，有的时候那些辅助工具的说明文档写的是挺烂的
我保证，不仅是你会这样想。很多辅助工具的说明文档写的都很烂。有的时候，连搞清楚辅助工具最基本的机能都是一件很困难的事。你会发现，很多人都和你有一样的困扰。
虽然这样的文档有点让人讨厌，但是同时也给了你一个机会，让你去发挥创意和你的编程能力。
毕竟，我们的组织工作不是化解难题么？
