《重学前端》学习笔记Day131

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

工具总论

与性能不同，工具体系并非业务结果，所以非法简单的通过数据指标来衡量工具，它的结果更多是一种开发体验，帮助团队内的同学提升效率和体验。
作为工程体系，我们考虑工具的时候同样要遵循基本原则：现状和指标、方案、执行、结果和监控。
不推荐把开发体验和开发效率过滤数据化。

工具体系的目标

工具是为技术团队本身服务的工程体系，那么，目标是什么呢？所有工具的出现，必然是有一个很具体的目标。
假设你是一个前端团队的工具体系负责人，现在要你来规划工具体系，你会怎么做呢？
如果是去社区找了一大堆工具，并把它们要解决的问题罗列出来，作为工具体系的目标，那就完全走向了错误的道路。
实际上，在考虑具体的问题之前，先找到解决工具体系的元问题，即：我们对工具本身的要求是什么？
考虑到工程行为都是团队合作，我们对工具基本的要求就是：版本一致。
工具体系另一个重要需求是：避免冲突。
所以在谈及具体问题之前，我们必须要有这两个要求的解决方案。这就需要引入一个新的概念，工具链。
工具链是一系列相互配合的工具，能够协作完成任务(注：工具链最早是由C/C++开发者引入的概念，一般包含编译、链接、调试等工具)。

工具体系的设计

要想设计一个工具链，首先需要整理下前端开发需要做哪些事：

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

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

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

这显然还不够，还需要一种机制，保证团队使用工具的版本一致

轻量级的做法：在项目初始化模板中定义npm script并且在npm dev-dependency中规定它的版本号。
重量级的做法是，开发一个包装工具，在命令行中不直接使用命令，而使用包装过的命令。--def

这样统一的命令入口，意味着团队不需要互相学习工具链，就可以直接接受别人的项目。
再稍微大一些的项目团队，往往不止一种开发模式，如移动端开发和桌面开发，这样所需要的工具链也不一样，因此我们需要多条工具链。

工具体系的执行

因为工具体系服务的是团队内部成员，所以执行非常简单，同时，工具体系的入口是初始化项目，所以只要初始化工具在手，可以控制其它所有工具。
在性能的一课里，已经讲过工程体系的执行分为三个部分：纯管理，制度化和自动化。
因为工具链自身特性，所以很容易做到自动化的一个体系了。

工具体系的监控

工具体系虽然是软性的，但是也不能完全不做监控。
纯碎的社区方案比较难做到监控，但是如果使用前面提到的统一命令行入口包装，那么就可以做一些简单的统计工作了。
一般来说，以下指标跟开发者体验较为相关：

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

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

此文章为8月Day3学习笔记，内容来源于极客时间《重学前端》，日拱一卒，每天进步一点点💪💪