工具链

这里有一份简洁的前端知识体系等待你查收，看看吧，会有惊喜哦~若是以为不错，麻烦star哈~

前言

古语云：“工欲善其事，必先利其器”，程序员群体对工具的爱好和重视是一个悠久的传统。简单趁手的工具是程序员开发的好帮手。

可是在工程方面，工具不只仅是简单的“趁手”便可，假如一个团队人人都本身发明几个小工具，那么后果将会是灾难性的：同一个团队的同窗没法互相配合写代码，一旦有人离职，可能某一个项目就永远没法跑起来了。

因此咱们今天从工程的角度谈一谈工具体系的规划。

工具总论

跟性能不一样，工具体系并不是业务结果，因此咱们无法用简单的数据指标来衡量工具，它的结果更多程度是一种开发体验：帮助技术团队内的同窗提高效率和体验。

做为工程体系，咱们考虑工具的时候一样要遵循基本规则：现状与指标、方案、实施、结果和监控。

不过，对工具而言，指标和结果都是一种“软性指标”，也就是团队的开发效率和开发体验。这里我不太推荐把开发效率和开发体验过分数据化，个人经验是：开发效率提高n倍永远是一种臆想或者主观论断。

工具体系的目标

前面已经讲到，工具是为技术团队自己服务的工程体系，那么，工具的目标是什么呢？其实每一种工具的出现，必然都有一个很是具体的目标，好比npm帮助咱们进行包管理，Yeoman帮助咱们初始化项目模板。

可是这些目标是工具的目标，不是工具体系的目标。咱们作一个假设，假如你是一个前端团队的工具体系负责人，如今要你来规划团队的工具体系，你会怎么作呢？

若是你到社区找了一大堆工具，而且把它们要解决的问题都罗列出来，做为工具体系的目标，那就彻底走上了错误的道路。

实际上，在考虑具体的工具以前，咱们应该解决工具体系的“元问题”，即：咱们对工具自己的要求是什么？

考虑到工程行为都是团队合做，咱们对工具最基本的要求就是：版本一致。

只有整个团队的工具版本一致，至少要作到避免大版本差别，才能作到互相接手代码时，团队成员可以正确的使用工具开发。

工具体系的另外一个重要需求是：避免冲突，一些工具可能互相没有干扰，好比Yeoman和gulp，有一些工具则由社区设计了配合方案，好比webpack和babel，有一些工具，则存在着根本性冲突，如gulp和grunt。

因此，在谈及具体问题以前，咱们必需要有这两个要求的解决方案。这就须要引入一个新的概念：工具链。

工具链是一系列互相配合的工具，可以协做完成开发任务（注：工具链这个词最先是由C/C++程序员引入的概念，通常包含编译、连接、调试等工具）。

下面咱们就来谈谈工具链的设计。

工具体系的设计

要想设计一个工具链，首先咱们须要整理一下，前端开发大约要作哪些事，下面是个人答案：

• 初始化项目；
• 运行和调试；
• 测试（单元测试）；
• 发布。

那么，一个前端项目的工具链，大约就会包含这些功能。一个典型的社区项目工具链可能就相似下面这样：

• Yeoman
• webpack
• ava/nyc
• aws-cli

可是，这显然不够，咱们还须要一种机制，保证团队使用的工具版本一致。

轻量级的作法是，在项目初始化模板中定义npm script而且在npm dev-dependency中规定它的版本号。

重量级的作法是，开发一个包装工具，在命令行中不直接使用命令，而使用包装过的命令。如在我以前的团队，使用的工具名为def，它规定了一些命令：

• def init
• def dev
• def test
• def publish

这样，工具链的使用者只需指定工具链名称，就不须要知道项目具体使用了哪些工具，这样只须要专一本身的需求就够了。

同时，统一的命令行入口，意味着整个团队不须要互相学习工具链，就能够接手别人的项目开发。

在稍微大一些的团队内部，每每会须要不止一种开发模式，如移动开发和桌面开发，这样，所须要的工具链也不同，所以咱们须要多条工具链。

要想开发新的工具链，可使用复制分支的方式来扩展原来的工具链。在我原来的工做中，不一样的工具链被称做“套件”，每一种套件对应着一组互相配合的工具。

工具体系的执行

由于工具体系服务的是团队内部成员，因此执行很是简单，同时，工具体系的入口是初始化项目，因此只要初始化工具在手，能够控制其它全部工具。

咱们在性能的那一课里，已经讲过工程体系的执行分红三个层次：纯管理、制度化和自动化。

工具体系由于其自身特性，能够说是最容易作到自动化的一个体系了。

工具体系的监控

工具体系的结果虽然是软性的，也不能彻底不作监控。

纯粹的社区方案比较难作到监控，可是若是咱们使用了前面提到的统一命令行入口包装，那么就能够作一些简单的统计工做了。

通常来讲，如下指标跟开发者体验较为相关：

• 调试/构建次数；
• 构建平均时长；
• 使用的工具版本；
• 发布次数。

在我以前的工做中，工具团队曾经从构建平均时长数据中发现构建效率问题，对webpack作了大量深度优化来改善开发体验。

同时，工具的相关数据还可以帮助发现一些问题，好比某个项目频繁发布，可能说明它风险很高。工具的相关数据还能帮咱们发现老旧的工具，若是某个套件使用频率极低，则能够考虑把它下线。

总之，工具体系的监控不只仅是衡量工具体系的好帮手，也是很是珍贵的研发数据，里面有不少可挖掘的价值。

总结

这一课，咱们讲解了工具相关的工程知识。

咱们仍然从目标、方案设计、执行和结果四个方面来说解，工具体系的目标除了单个工具解决具体问题以外，还要注意一致性和配合问题，所以咱们须要工具链。

工具链通常会涵盖研发阶段的各个主要操做。工具体系的执行比较简单，很容易就能够作到彻底的自动化。工具体系的监控一样很是重要，工具的监控除了帮助咱们改进工具体系，对研发体系的其它部分也有帮助。