背景

去年下半年，我在微信书架里加入了许多技术书籍，各种类别的都有，断断续续的读了一部分。

没有计划的阅读，收效甚微。

新年伊始，我准备尝试一下其他方式，比如阅读周。每月抽出1~2个非连续周，完整阅读一本书籍。

这个“玩法”虽然常见且板正，但是有效，已经坚持阅读十一个月。

已读完书籍：《架构简洁之道》、《深入浅出的Node.js》、《你不知道的JavaScript（上卷）》、《你不知道的JavaScript（中卷）》、《你不知道的JavaScript（下卷）》、《数据结构与算法JavaScript描述》、《WebKit技术内幕》、《前端架构：从入门到微前端》、《秒懂算法：用常识解读数据结构与算法》、《JavaScript权威指南》、《JavaScript异步编程设计快速响应的网络应用》。

当前阅读周书籍：《编写可测试的JavaScript代码》。

自动化

编写可测试JavaScript的重点是让我们自己和同事在后期可以很容易地修复并维护代码，因此这是我们需要具备的一项良好技能。为代码的未来版本编写测试将会变得很简单，并且这一坚实的基础将让自动化变得更加有效。自动化可以确保我们尽快地以可重复的方式编写可测试的JavaScript。考虑自动化时，必须知道自动化什么内容、何时进行自动化，以及如何进行自动化。

自动化什么内容

确定自动化什么内容是很容易的：自动化一切！这包括JSLint和其他形式的静态分析、所有的测试、代码覆盖率报告、应用程序打包、应用程序部署，包括回滚、反馈、bug提交、统计、分桶测试或功能测试。任何不止一次操作的内容都应该自动化。任何时候，只要先前使用了自动化，在代码整个生命周期内的回报都远大于付出。

何时进行自动化

关于何时进行自动化，有三个时机：编码阶段、构建阶段、部署阶段。这三个时间点在软件开发过程中都有不同的需求，即便是每个过程所使用的一些工具都一样。例如，将代码部署进行测试的过程可能与代码部署到生产环境中的过程不同。尽管两个流程应该保持尽可能多的相同，但事实上它们是不同的。将代码部署到测试虚拟机不同于将其部署到遍布全世界的多个服务器。同样很可惜，在本地开发环境运行单元测试并生成代码覆盖率与在构建过程中运行所有的单元测试稍有不同。

当然，在本地部署和生产环境部署时，都应该使用相同的工具。由于在构建细节上会有所不同，所以也应该使用相同的工具运行本地的单元测试。处理这些差异的唯一途径是确保过程和工具自动化。

建立自动化的本地环境和建立自动化的构建环境类似，本质上这是开发环境的超集。自动化构建环境将聚合自动化开发环境的工具和测试，并在其之上进行门面整合。

如何进行自动化

自动化JavaScript环境需要工具的支持。无论是自己编写工具还是使用现成的工具，最后的结果必须是一个智能的持续集成环境。这意味着，构建和测试代码都是以简单且可重复的方式进行的。

持续集成系统通常会自动启动（一段时间间隔或签入代码之后），开发人员还必须知道如何手动启动持续集成环境，以便应付那些似乎总是发生的一次性情况。如果该过程很困难或很神秘，那就不会成功启动，混乱的局面就会接踵而至。

可重复（repeatable）意味着在构建过程或测试测试中每次完整运行的流程都没有虚假错误。在持续集成环境中，避免大量电子邮件和假阳性测试结果是至关重要的，因为，如果收到构建环境中带有坏信息（过多或错误）的大量电子邮件的话，电子邮件很快就会被忽略，并且持续集成环境也会被浪费。

持续集成自动化必须是非常可靠的。

含有持续集成的自动化

也许完全自动化环境的最大优势就是持续集成环境的能力。通过不断构建和测试（每次提交时），就能在代码部署到其他地方之前很快发现错误。

在签入代码之前，开发人员要负责运行单元测试，但单元测试仅仅是个开始。在持续集成环境中，任何不匹配的代码都会作为一个整体进行测试（并且，如果不破坏任何东西，单元测试就会在整个代码库上进行执行！）。

为此对每一个提交，都需要尽快构建并运行测试。可以并行运行单元测试，其次是快速部署到测试环境做一些基本的集成测试。持续集成时不是所有的测试都需要运行——通常只需要运行单元测试和一些集成测试，以便测试一些非常基本和核心的应用程序功能。

我们将能够跟踪提交直接带来的失败，并且开发人员负责处理这些失败。在这一点上，在问题被修复之前，所有的构建都应该停止。现在所有的注意力都应该集中在修复构建上，以便团队的其他成员可以继续前行。

构建成功后，可以将构建部署到QA环境以进行更广泛的测试，然后从QA环境再到其他环境，一直到生产环境。

快速、完全自动化的开发构建会产生一个持续集成环境。带有很多集成点的应用程序，在可移动部件之间特别容易出错。具有以自动化方式快速辨别问题的能力，就无需麻烦开发人员或QA人员，从而不在破碎的构建上浪费时间。

在项目中，几乎没有什么理由不使用持续集成。

开发环境自动化

软件开发阶段是软件项目过程中使用手工最多、容易出错、耗时最多的一部分。除非我们可以教电脑为我们编写代码，否则我们只能一个字符一个字符地在编辑器里敲。所有的现代工业都已经全部变成了自动化，使用更新、更闪亮、更快速的机器完成人类的重复性工作。但软件编程却不是。软件编程的“科学”和“艺术”从终端机面世以来40多年都没有变过——该终端机是19世纪70年底的穿孔卡片的俗称，是软件创建中的“突破性进展”。现在，我们不用在穿孔过的圆柱状垫纸上编写程序了，而是直接可以在计算机里进行输入编程了——喔哦！

单元测试

在开发过程中，花时间编写了单元测试，那就应该自动化运行它们并享受一下劳动成果了。多个单元测试框架都提供类似的特点：可以从命令行运行单元测试、动态代码覆盖率报告生成，以及多浏览器支持。JUTE是一个很方便的工具，可以实现所有这一切功能，甚至更多。在本节，我们将重点把JUTE集成到开发环境中，以便尽可能轻松地运行单元测试并生成覆盖报告。

JUTE可以使用npm包进行安装，其最大的依赖是YUI3 Test和目录结构。在Yahoo！Mail的项目中，我和我的同事确定，应用程序和测试代码之间的智能目录结构是一个镜像的层次结构。在根目录下有两个主要子目录：src和test。test目录树是src目录树的镜像。在src目录树中，每个文件的单元测试都存在于test目录树中对应的目录中。当然，大家的情况可能有所不同，但也不需要设置存储库——有些人喜欢将测试文件和源代码文件放在同一个目录，JUTE可以配置该场景。然而，我的经验表明，使用test镜像树是最优选择。

代码审查

除了成熟的Fagan代码分析审查外，在代码签入之前，将代码分享给同事进行代码审查至关重要，从而确保你和你同事知道你在做什么。除了分享知识外，代码审查还可以在团队中建立风格指南，并帮助新成员更快地融入代码开发工作。

应该审查什么内容？审查一个巨大的JavaScript块会让我目光呆滞，所以对大型代码块进行逐行审查正是Fagan分析真正闪光的地方。至少，与同事一起进行大块的代码审查是有道理的。然而，只有在bug修复的代码审查中，自动化才能真正起作用。

代码审查就像给一些人或所有人发送电子邮件的区别一样简单，但通常更可靠的解决方案才可以更加持续。我很喜欢开源Review Board应用程序。它的建立相对简单（只需要设置一次！），并且与CVS、Subversion、Git（和其他源代码控制系统）以及Bugzilla都可以有良好的集成。

提交钩子

大多数的源代码管理存储库都允许预先提交钩子，这意味着，在代码签入之前，可以运行任意方面的检查并拒绝提交。这是进行代码审查的地方，检查该提交是否与bug关联，确保运行了单元测试和冒烟测试，对代码进行JSLint检查，在代码签入到系统之前，通常要强制执行一些我们希望进行的分析和检查。

对于设置预先提交钩子的细节，每个代码库有所不同，但通常它们只是shell脚本，在非零时退出并中止提交。当然，并不是所有的开发人员在签入代码之前都遵循所有必需的流程和实践，所以“信任，但要核查。”

构建环境自动化

构建环境中创建的自动化是开发环境过程中的一个超集。如果在开发环境中还没签入的话，就不要让大型复杂度的数字导致构建失败。同样，如果还没有在开发环境中运行JSLint进行检查，就不要因为JSLint错误而让构建失败。我们开发人员讨厌构建环境中出现意外，所以不要尝试在构建环境中添加开发环境中都没有出现的任何新需求。

总结

自动化开发、构建和部署过程对于一个完整的应用程序生命周期来说至关重要。幸运的是，很多JavaScript工具（大部分）组合在一起可以帮助我们解决这个问题。利用并融合这些工具，从预先提交钩子到Jenkins插件，可以尽快地进行泡沫、冲洗以及重复操作。和大多数事情一样，这些工具只能按照自己的用法来用。开发人员必须不断关注他们的代码和进展，以确保一切进展顺利，并且发现问题尽快处理。

作者介绍
非职业「传道授业解惑」的开发者叶一一。
《趣学前端》、《CSS畅想》等系列作者。华夏美食、国漫、古风重度爱好者，刑侦、无限流小说初级玩家。
如果看完文章有所收获，欢迎点赞👍 | 收藏⭐️ | 留言📝。