Chapter4 主要讲述如何去搭建和熟悉开发环境，但是作为资深的前端开发，我们要用能力去设计一个完整的应用开发流程，这个流程就是一个构建系统，它通过Chapter3 中设计的流程以代码、工具形式来加强规范。
通常前端应用中，构建系统需要做以下事情：
- 依赖管理及安装
- 优化开发环境
- 代码质量检测
- 编译及打包
- 测试及部署
- ...
前端的应用构建已经变得相当复杂了，前端应用需要管理依赖版本，需要编译代码，需要编译scss等等
4.1 依赖管理工具
在项目源码管理中，依赖管理相当重要，早期没有依赖管理时，项目依赖放在代码库中，每次更新依赖，都需要向代码库提交新的版本，导致项目代码越来越大，现在有了依赖管理，直接npm install ，在执行运行服务就可以开发了
不同的模块化方案
AMD, commonJs, UMD，它们是三种不同的JavaScript模块化方案，对项目有一定程度影响着依赖管理
AMD： 异步模块定义，典型表现形式即是通过构建好的JavaScript库文件，直接在浏览器中引入依赖，如jQuery，为了使用AMD方式的库，还需使用如 require.js 这样的AMD管理依赖，如果这些AMD库是在浏览器上通过script直接引入并运行，它们就可以使用bower 来进行管理。 一般对它管理方式有两种：一种直接下载对应的库到本地，一种把资源添加到bower.json，打包到bower服务器，bower直接下载，不过这种方式越来越少了，现在现在都用npm了
commonJs： 最初被用于非浏览器端使用JavaScript来管理模块，如node.js开发服务器应用，设计目的是避免模块定义全局对象，及JavaScript作用域问题，在common库，每个文件就是一个模块，开始common在node服务端应用，后来webpack将这些common编译为浏览器能运行的JavaScript，前端框架则都直接使用commonjs 来管理模块。通过npm 和 yarn管理，所以的依赖包作者都会传到npm官方，供所以人直接下载，yarn 是可以缓存它下载的每个包，所以它会比npm 更快，是脸书推出的
随着AMD和common的流行。于是将这两种方式糅合在一起，就诞生了UMD, 它会判断是否是node模块，umd里面有判断，判断typeof export 是否存在于node模块，不存在则使用AMD方式加载
4.2 软件包源管理
小公司会使用npm官方源，大型公司除了会使用npm官方源，还会使用自己公司内部的包服务（nodeky shi yong cnpmjs来搭建自己私有化包服务器），目的为了解决npm 官方源版本更新带来的宕机风险
4.3 设计构建流
构建流是逐步演进的，很难在项目初始时便设计出完整的构建流，只有在开发中不断去完善，构建流通常来源于：
- 过去的开发经验
- 前端框架提供的命令
- 应用脚手架提供的功能
如何设计应用的构建流呢？我们进一步了解：
- 我们需要做的任务是？
- 每个任务具体步骤拆解是？
- 部署时，对应的形式是？
- 有没有现成的插件可使用
npm 适用于脚本简单的应用构建 gulp / grunt 适用于复杂的项目工作流构建 webpack 项目的模块化打包 【多了解weback方式配置和工作流即可】
