4.5　加速各项活动

4.5.1　为什么要加速

我们希望缩短从写完一行代码到这个改动发布上线、被用户感知到之间的时间。为此，要尽量减少这个过程中的各种等待，也就是要小批量持续流动。那么，还有没有其他办法可以帮助缩短流程的整体时间呢？答案是肯定的。另一种直观的办法是，加快整个过程中每一项具体工作的处理速度，比如加快构建的速度、单元测试的速度、部署的速度等。当然，这些加速是在保质保量地开展该项活动的前提下进行的。

这些加速其实是有一些通用的思路的。比如不少构建加速的思路，也可以用在单元测试的加速上。下面我们来具体看看这些思路。

4.5.2　加速的通用思路

第一，提高硬件的能力。使用更快的CPU、更快的存储设备、更高的带宽等。此外，在执行某项任务时独占一台机器，或者至少不要在一台机器上并行执行太多的任务，也能加速。

第二，考虑并行处理。把整个任务拆分成若干个小任务，然后这些小任务在不同的进程中甚至不同的机器上并行执行。典型的，如自动化测试时把1000个测试脚本分成10组，在10台机器上并行执行；或者人工测试时把1000个测试用例分成10组，让10个人并行执行。再比如部署和分发时可以考虑使用P2P的方法加速。当然，这需要一系列的支持和保障，比如测试数据不能相互干扰、P2P需要特定算法实现等。

第三，避免重复。做过的事情不用再做一遍。比如，某个源代码版本在部署到集成测试环境前已经做过一次构建，当将它部署到预生产环境中时就不用再做一次构建了，使用上一次构建产生的安装包就行。类似地，可以消除一些重复的代码静态分析、自动化测试、自动化部署等活动。

第四，只关注增量。这其实是避免重复的升级版，但是更细致。在构建时，如果其中的一部分源文件已经被自己（或别人）编译过，那么在链接时把这些源文件对应的目标文件拿来用就行，不用再编译一遍了。代码静态分析也可以只分析本次改动的部分。在人工测试中长期以来广泛采用的方法是：集中力量优先测试本次修改可能影响到的功能。

第五，使用某种缓存方法。先预备好要使用的东西，而不是在需要的时候现做。比如Maven构建时在本机缓存的.m2库。把外来制品同步到组织内部的制品库，而不是每次需要时都从外网下载，这是缓存的思路。把构建环境做成资源池，想用的时候，立刻就能分配用上现成的资源，用完还回去而不是立刻销毁，这也是缓存的思路。

当然，除了上述这些通用的思路，还有一些是特定活动可以使用的特定思路。比如测试的加速，不仅仅是测试执行的加速，还包括测试用例和脚本编写的加速。