4.5　加速各項活動

4.5.1　為什么要加速

我們希望縮短從寫完一行代碼到這個改動發布上線、被用戶感知到之間的時間。為此，要盡量減少這個過程中的各種等待，也就是要小批量持續流動。那么，還有沒有其他辦法可以幫助縮短流程的整體時間呢？答案是肯定的。另一種直觀的辦法是，加快整個過程中每一項具體工作的處理速度，比如加快構建的速度、單元測試的速度、部署的速度等。當然，這些加速是在保質保量地開展該項活動的前提下進行的。

這些加速其實是有一些通用的思路的。比如不少構建加速的思路，也可以用在單元測試的加速上。下面我們來具體看看這些思路。

4.5.2　加速的通用思路

第一，提高硬件的能力。使用更快的CPU、更快的存儲設備、更高的帶寬等。此外，在執行某項任務時獨占一臺機器，或者至少不要在一臺機器上并行執行太多的任務，也能加速。

第二，考慮并行處理。把整個任務拆分成若干個小任務，然后這些小任務在不同的進程中甚至不同的機器上并行執行。典型的，如自動化測試時把1000個測試腳本分成10組，在10臺機器上并行執行；或者人工測試時把1000個測試用例分成10組，讓10個人并行執行。再比如部署和分發時可以考慮使用P2P的方法加速。當然，這需要一系列的支持和保障，比如測試數據不能相互干擾、P2P需要特定算法實現等。

第三，避免重復。做過的事情不用再做一遍。比如，某個源代碼版本在部署到集成測試環境前已經做過一次構建，當將它部署到預生產環境中時就不用再做一次構建了，使用上一次構建產生的安裝包就行。類似地，可以消除一些重復的代碼靜態分析、自動化測試、自動化部署等活動。

第四，只關注增量。這其實是避免重復的升級版，但是更細致。在構建時，如果其中的一部分源文件已經被自己（或別人）編譯過，那么在鏈接時把這些源文件對應的目標文件拿來用就行，不用再編譯一遍了。代碼靜態分析也可以只分析本次改動的部分。在人工測試中長期以來廣泛采用的方法是：集中力量優先測試本次修改可能影響到的功能。

第五，使用某種緩存方法。先預備好要使用的東西，而不是在需要的時候現做。比如Maven構建時在本機緩存的.m2庫。把外來制品同步到組織內部的制品庫，而不是每次需要時都從外網下載，這是緩存的思路。把構建環境做成資源池，想用的時候，立刻就能分配用上現成的資源，用完還回去而不是立刻銷毀，這也是緩存的思路。

當然，除了上述這些通用的思路，還有一些是特定活動可以使用的特定思路。比如測試的加速，不僅僅是測試執行的加速，還包括測試用例和腳本編寫的加速。