單體中心代碼庫 vs. 分布式代碼庫
去年中旬兩位Google工程師在《美國計算機學會通訊》發表了一篇論文“Why Google Stores Billions of Lines of Code in a Single Repository”，它介紹了谷歌為什么采用一個定制的大型單體中心代碼庫，并且在多個大會上分享了這個話題。InfoQ中文網站也發表了一篇較為客觀的文章”Google為什么要把數十億行代碼放到一個庫中?”來評論Google這種代碼管理方法 ，其中總結了Google宣稱的這種唯一中心庫代碼管理方式的優勢，包括：
- 統一版本控制
- 廣泛地代碼共享和重用
- 簡化依賴管理，避免菱形依賴
- 原子修改
- 大規模重構
- 跨團隊協作
- 靈活的團隊邊界和代碼所有權
- 代碼可見性以及清晰的樹形結構提供了隱含的團隊命名空間
并且也總結了Google這種唯一中心庫代碼管理方式的一些問題，包括：
- 工具投入(Google開發了自己專用的Eclipse ID插件)
- 代碼庫復雜性(需要有依賴重構和代碼清理輔助工具)
- 代碼健康(專用工具可以自動檢測和刪除無用代碼、分派代碼評審任務等)
對于Google這樣的大型團隊或者公司，他們的代碼管理看起來是簡單的單體代碼庫管理方式，其實真正管理起來并不簡單，甚至需要大量的額外投入來輔助管理，因為它是在各種前提和限制條件下的歷史產物，其中最為重要的兩點是：
(1) 由于當前大部分的商業和開源代碼管理工具或者系統在管理一個超過10億個文件，20億行代碼的中心庫時效率都十分低下，而且隨時都有大量的代碼同步(包括代碼獲取和提交)請求。
所以為了在不影響程序員日常工作效率的前提下對海量代碼進行高效管理，一般情況下這樣的團隊或者公司都會開發或者定制自己專用的代碼管理工具和系統，比如Google開發的Piper，Facebook定制化的Mercurial和Microsoft定制化的Git系統GVFS等。
(2) 大型公司一般是經過長時間的積累才有如此巨量的代碼，并且都有自己特定的經歷和原因，比如開發了大量定制化的外圍輔助工具和系統，形成了特有的一套代碼管理模型和流程。所以更換這種大型代碼庫的管理工具成本非常高，而且現實中很難找到一個代碼管理系統能滿足已有的管理和流程需求，所以一般情況下都不會更換。
比如Google最開始使用Peforce來管理其單體中心代碼庫，后來發現它無法支持其巨大的代碼量，所以開發了Piper用以管理中心庫管理，并且其在代碼健康上投入了大量的成本，比如開發了專用的工具來自動檢測和刪除無用代碼、分派代碼評審任務等。雖然Google也嘗試過向Git進行遷移，最終由于文化和工作流程的巨大變更而放棄了，但是仍然對于一些新的實驗性的或者一些開源的項目會嘗試使用一些新的代碼管理工具。
雖然說Google的大部分核心代碼都是使用Piper在一個中心代碼庫進行管理和維護的，但是它仍然有不少開源項目，其中包括Android Open Source Project(2008)和Chromium(2014轉向Git)這樣的大型項目，或者創新的初始項目依然可以選擇使用Git這樣的開源代碼管理工具進行代碼管理，所以應該給予項目組足夠的權利去選擇適合自己項目的代碼管理工具，從而讓團隊感受到足夠的尊重和動力。
而世界范圍內像Google和Microsoft等有財力和物力去開發或者定制一款適合自己的專用代碼管理及其周邊輔助工具的公司是很少的，而絕大多數公司只適合通過購買商用，使用開源免費或者使用基于云的代碼管理系統來管理自己的代碼。
由于選擇單體代碼庫還是分布式代碼庫直接影響了團隊對于代碼管理工具的選擇和使用，所以一些正在快速增長或者需要轉型的中小型公司就對代碼管理方式和代碼管理工具的選擇產生了疑惑：是應該學習Google的核心代碼庫而繼續使用單體代碼庫的管理方式，然后自己開發和定制化自有的代碼管理工具，還是學習Linux，Android以及OpenStack等開源項目而轉向分布式代碼管理方式和免費的分布式代碼管理工具，或者直接使用基于云端的代碼管理系統等。
為此我總結了一個代碼管理工具，選擇四象限圖用以幫助中小型公司選擇代碼管理方式和代碼管理工具：
其中資源主要是指錢和人力資源，而技術是指項目組或者公司里面的大部分工程師的技術能力。
通過這個四象限圖，中小型公司就可以通過另外一個角度去思考和判斷自己應該選用什么樣的代碼管理方式和代碼管理工具。而對于大型軟件公司，比如類似于Google，Facebook，Microsoft等這樣規模的公司就不適合用這個四象限模型，而是需要根據自身具體的情況而自己開發或者定制的代碼管理工具，可以是中心服務器式，也可以是分布式，無論什么形式，只要適合自己的實際情況就可以了。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
