一. 关于babel
babel的功能被定义为编译工具，那么理论上来说它就可以使用编译器的通用代码框架，通过ASTparser --> traverse --> stringify 的步骤实现编译功能，在关键的traverse环节，是需要一个规则集合的，可是转码所参考的ES6的标准并不是一个定案的标准，其中每一个特性都需要经过从stage0到stage4这样5个阶段才能正式定稿，只有stage-2草案(draft)阶段以上的特性才会在未来被支持，而处于这个阶段以下的标准是有可能被废的，如果一味地全部转换，不仅会降低工具效率，也会为代码未来的维护造成隐患。
那如果我们有一个工厂函数，接受数字0-4作为参数，然后返回所有经历了stage-x的规则集（是ES6规则的子集）作为规则集合，那么就可以在最终生成生产环境的代码时减小代码体积，假如在项目中通过babel_get_es6_by_stage(2)这样一个函数返回了规则集，那么正式代码中就不需要stage-0和stage-1的实现代码了。基于以上的考虑，我们对Babel工具进行第一次功能剥离：
推演继续，在对规则集进行了一次体积缩减后，我们得到了一个相对精简的规则集，它包含了诸多新的语法和方法，如果直接使用那的确很爽，毕竟引入了一个工具后就可以毫无后顾之忧地使用新特性，但对于生产环境的代码包来说，这种做法造成的代码冗余确是非常难以接受的。
用大家都熟悉的bootstrap为例，bootstrap.min.css的体积大约为120k，可你会发现很多人引入它完全是出于心里惯性，而在最后仅仅使用了非常基础的btn相关的样式类，或者仅仅为了使用col-md-4这种响应式布局的样式，所有使用到的样式可能只占了20k-30k的空间，但是却不得不为项目引进一个120k大的库，当然并不是所有的项目都会在意20k和120k之间的差别的。
那么我们就需要一个能够按更小粒度组合的方法babel_get_es6_by_rules([rule , ...])，让使用者可以选择自己所使用到的语法和方法，从而达到缩小引用库体积的目的：
推演继续进行。处理过兼容性问题的开发者都知道，浏览器是存在版本区分的，许多特性在不同浏览器中的实现和表现都不一样，对于ES6也是这样，较高版本的浏览器对于ES6中的一些特性是已经逐步实现支持了的，如果我们的目标用户所使用的运行环境对某些ES6特性已经提供了原生支持，或者目标用户的运行环境根本就是由开发者直接封装好的，那么原先“一锅端”的转码方式里就会存在很多没有必要的部分。
比如你在规则集中选择了对Class关键字来定义类这个特性进行转码，那么babel就需要将其转码成为使用function和prototype的ES5的实现方式，但如果你的目标用户全都是程序员，几乎全都是使用高版本的chrome作为项目环境，那么上面的转码可能就是画蛇添足了。
综上所述，我们就需要为babel提供一个判断目标环境是否需要转码的方法babel_get_rule_as_need( rule_set , env_info),将经过第一次筛选后的规则集和目标用户的环境信息传入方法，对规则集进行再一次的精简，那么我们需要再次对babel进行优化：
至此，babel便具备了针对不同的使用环境进行必要转码的能力，可这并不是问题的全部，ES6的新特性除了语法的更新外，还增加了很多原生方法或类型，例如Map,Set,Promise等这类新的全局对象，或是
