42、工具链：什么样的工具链才能提升团队效率？

今天我们的主题是工具。

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

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

所以我们今天从工程的角度谈一谈工具体系的规划。

工具总论

跟性能不同，工具体系并非业务结果，所以我们没法用简单的数据指标来衡量工具，它的结果更多程度是一种开发体验：帮助技术团队内的同学提升效率和体验。

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

不过，对工具而言，指标和结果都是一种“软性指标”，也就是团队的开发效率和开发体验。这里我不太推荐把开发效率和开发体验过度数据化，我的经验是：开发效率提升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做了大量深度优化来改善开发体验。

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

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

总结

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

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

工具链一般会涵盖研发阶段的各个主要操作。工具体系的执行比较简单，很容易就可以做到完全的自动化。工具体系的监控同样非常重要，工具的监控除了帮助我们改进工具体系，对研发体系的其它部分也有帮助。

最后，请你思考下自己所在的团队，是否已经建立了工具体系？听完了今天的课程，你认为它有哪些可改进的部分？