近日，谷歌工程師Rachel Potvin和Josh Levenberg在《美國計算機學會通訊》上發表了一篇論文，介紹谷歌為什么采用一個定制的大型單體共享庫。該庫有一個集中式源代碼控制系統管理。谷歌采用該方法已達16年之久。如今，谷歌大部分的資產都存儲在這個單體共享庫中。

谷歌的軟件開發人員不斷增加，其代碼庫也成倍地增大，管理代碼庫的技術也在相應地發展。為管理這個谷歌95%的軟件開發人員都在使用的代碼庫，谷歌開發了自己的版本控制系統。該集中式系統是谷歌開發工作流的基礎，支撐著谷歌“基于主干的開發策略”，確保了代碼庫的健康，包括靜態分析、代碼清理和簡潔的代碼評審。這個代碼庫包含大約10億個文件，86TB的數據，其中包含大約20億行代碼，18年間大約產生了3500萬次提交。通常，一個工作日就會有16000次提交，以及24000個來自自動化系統的提交。此外，該庫每天還要處理數以10億計的文件讀取請求以及每秒500000次查詢。

管理這樣一個大規模的庫及其相關活動是一項巨大的挑戰。雖然經過了多年的試驗，但谷歌還是沒能找到一個商業或者開源版本控制系統來管理這種規模的單體代碼庫。于是，谷歌基于標準的基礎設施（最初是BigTable，現在是Spanner）構建了Piper來存儲和管理它。Piper分布在谷歌全球范圍內的10多個數據中心里，基于Paxos算法來保證副本之間的一致性。該架構提供了很高的冗余水平，并幫助谷歌的開發人員優化網絡延遲，而不管他們工作地點在哪里。該系統的工作流程如下：

大多數開發人員都是使用Clients in the Cloud（CitC）訪問Piper。該系統包含一個基于云的存儲后端和一個Linux特有的文件系統FUSE。CitC 支持代碼瀏覽和常見的Unix工具。開發人員可以瀏覽和編輯Piper庫中的文件，但只有修改過的代碼會存儲在用戶的工作區里。也就是說，CitC工作區通常只占用很小的存儲空間。

谷歌在這個巨大的Piper源代碼庫上踐行著“基于主干的開發”策略。大多數Piper用戶都工作在“主干”的唯一最新副本上。代碼庫的修改順序是一個串行序列。提交完成后，其他所有的開發人員立即就可以看到和使用新的代碼。Piper的所有用戶都使用一個一致的代碼庫視圖，這可以避免代碼合并的痛苦，是單體大型代碼庫能夠具備如下優勢的關鍵所在：

統一版本控制廣泛地代碼共享和重用簡化依賴管理，避免菱形依賴原子修改大規模重構跨團隊協作靈活的團隊邊界和代碼所有權代碼可見性以及清晰的樹形結構提供了隱含的團隊命名空間

總之，將所有源代碼存儲在一個公用的版本控制庫中，讓代碼庫維護人員能夠有效地分析和修改源代碼。類似Refaster和ClangMR這樣的工具可以利用谷歌代碼庫的單體視圖執行高級的代碼轉換。單體代碼庫包含了所有依賴信息。舊的API可以很有把握地刪除，因為可以證明，所有的調用者都已經遷移到了新API。

雖然有許多好處，但構建這樣一個龐大的單體代碼庫也有幾個方面的問題需要權衡。

工具投入

單體代碼庫在許多方面簡化了工具，但它們需要能夠擴展并適用于代碼庫的規模。例如，谷歌開發了一個Eclipse IDE插件，以便能夠在該IDE中操作這個巨大的代碼庫。谷歌的代碼索引系統為靜態分析、代碼瀏覽工具交叉引用等提供了支持。這些工具都需要不斷的投入以適應代碼庫的不斷增長。除了構建和維護這些可擴展的工具之外，谷歌還需要承擔運行這些系統的成本，有些是計算密集型的。

代碼庫復雜性

雖然單體模型讓代碼結構更容易理解，但卻讓代碼發現變得更困難。隨著代碼庫規模的增長，像grep這樣的標準工具就無法使用了。開發人員需要能夠查看代碼庫，找到相關程序庫，并看看如何使用它們以及誰編寫了它們。這就需要有代碼搜索和代碼瀏覽工具。此外，由于添加依賴變得簡單，所以開發團隊對依賴圖的考慮就比較少，這增加了代碼清理時犯錯的可能性。因此，需要有依賴重構和代碼清理輔助工具。

代碼健康

谷歌在代碼健康上投入了大量的精力。例如，專用工具可以自動檢測和刪除無用代碼、分派代碼評審任務等。

另外，隨著分布式版本控制系統（如Git）的流行，谷歌也考慮過是否用Git取代Piper作為基本的版本控制系統。由于外部合作伙伴和開源協作方面的原因，谷歌的Android和Chrome團隊就使用Git。Git社區強烈建議使用更多更小的代碼庫，而且Git克隆操作會把所有內容都復制到本地機器上。因此，如果要遷移到Git，谷歌就需要把那個巨大的代碼庫分割成成千上萬的小代碼庫。對谷歌的開發人員而言，這意味著文化和工作流程的變革。鑒于單體代碼庫所帶來的好處，他們放棄了這種遷移。

這篇論文在Hacker News上引發了激烈的討論。網友rzimmerman認為，如果沒有人致力于維護構建環境、自動化測試和開發環境，那么大型單體代碼庫的許多好處將不復存在。如果運行測試、生成構建需要幾個小時才能完成，就會嚴重降低團隊的效率。但wtbob認為，多代碼庫只是模糊了單體庫中明確需要完成的工作，但并沒有減少相關工作。例如，在單體庫中，一項破壞性修改所產生的全部影響立即就會顯現出來；但在多代碼庫的情況下，有一些影響要在很長時間之后才能發現。

網友hpaavola認為單代碼庫確實便于處理依賴問題。據他介紹，他們的產品族包含多個產品。每個產品都有自己的代碼庫，每個代碼庫又有自己的功能測試。每當測試自動化核心功能發生變化，他就需要為每個產品的代碼庫生成一個分支，并逐個進行測試，看修改是否破壞了向后兼容性。如果破壞了，他就需要通過向多個團隊提交pull request修復測試。這是一個痛苦的過程。在單代碼庫的情況下，修改要容易得多，只需要生成一個分支，提交一個pull request。

上述觀點只是其中部分頗具代表性的觀點。網友們還就一些具體的工作流程和實踐進行了討論，感興趣的讀者可以移步Hacker News。