根據谷歌對外公佈的資料，它的20億行程式碼都部署在同一個程式碼倉庫裡，通過基於基線的方式進行開發工作中的程式碼共享。

從上面這張圖可以看到，一共有檔案10億個，原始檔數量達到900萬個，原始碼行數達到20億行，提交程式碼的深度可以挖掘到3500萬次提交，平均每個工作日提交4萬次，數字真是恐怖。

從大眾的眼光來看，特別是那些谷歌公司外部的人，他們會覺得這種單一程式碼倉庫的管理方式，尤其是程式碼量這麼恐怖的前提下，這種管理方式很不正常，但是它真的很有效，而這種有效是由管理方式決定的，而不是單純讓它自然生長。

Rachel Potvin和Josh Levenberg編寫的一篇文章裡是這麼描述的：谷歌的程式碼庫由全球數十個辦公的超過2.5萬名軟體開發工程師所共享，平均每天他們會提交1.6萬次程式碼修改請求

正如下面這張圖所顯示的，在谷歌，你看不到程式碼分支，拉程式碼分支是很多公司的習慣做法，在開發階段這個很方便，相當於一個個獨立的Docker映象，但是等程式碼合併的時候就不是這麼好玩了。

對於只有一個原始碼倉庫的開發模式來說，你不可能出現應用程式FooBar使用AngularDartV2.2.1版本，而另一個應用程式BarFoo使用2.3.0版本的情況。兩個應用程式必定需要使用同一個版本。這其實是將多版本之間的完全相容性測試由出現問題轉移到了程式碼提交環節。

這裡推薦一下我的前端學習交流q君羊：731771211，裡面都是學習前端的，從最基礎的HTML+CSS+JS【炫酷特效，遊戲，外掛封裝，設計模式】到移動端HTML5的專案實戰的學習資料都有整理，送給每一位前端小夥伴
點選：

加入

每次提交74000個測試用例

我們這裡以AngularDart框架為例，它目前有1601個測試用例。當你向谷歌的程式碼庫提交一次AngularDart程式碼時，會自動為所有依賴於AngularDart框架的工程執行測試用例。也就是說，差不多有74000個測試用例（視依賴的工程數量而定，這裡只是舉一個例子，有些流行的框架可能測試用例會更多）。

我們舉個例子，也許你修改程式碼的數量很少，例如“&& random.nextDouble() > .05”，你只是增加了這麼一個判斷條件，它並沒有觸發1601個測試用例裡面的任何一條，但是因為你增加了這個判斷，它可能會對框架的使用方造成問題。

真正的價值在於，提交程式碼時所作的測試時針對真實的應用程式的。不僅僅測試的量級很大，針對使用方的測試也可以反應你的框架是如何被開發者所使用的。這就好比我們自己寫框架的人，寫出來的測試用例都是符合我們思考方式的，但是你無法左右你的客戶如何使用你。

對於生產環境下的應用程式，我們應該明白它們和測試環境的示例程式存在巨大的區別，你當前支撐得好，他們才會一直使用下去，這種做法也是為了更好地支援後續的開發活動。

你製造麻煩，你修復它

正如標題所說，如果AngularDart的作者引入了一個改變，哪怕只是一行程式碼的改變，他們都需要直接去為客戶解決問題。也正是由於谷歌只有一個程式碼庫，所以AngularDart作者可以直接修復問題。

所有的修改程式碼和針對客戶的修復措施程式碼，它們都需要同時被提交帶程式碼庫，當然，還需要所有相關方的程式碼評審完成之後才能提交。

我們舉個例子。當AugularDart團隊的成員想要做程式碼修改，而這次的程式碼修改會影響AdWords這個應用程式的程式碼，那麼AugularDart團隊的成員需要直接進入AdWords的原始碼，然後修復問題。他們可以執行AdWords已存在的測試用例，也可以自己增加一些新的用例。然後他們把所有的改變寫入改變列表（change list）並提交評審。因為他們的change list涉及到框架（AngularDart）和呼叫方（AdWords）的程式碼，所以系統會自動請求來自雙方面的成員進行程式碼程式碼稽核和批准請求。

當然，業界也有其他的批評，認為AngularDart開發者僅關注了谷歌內部的使用方，例如AdWords，而沒有關注外部的使用方，例如Workivas、Wrikes，以及StableKernels。

大規模改變

如果AngularDart準備進行一次大規模的改變，例如從2.x升級到3.0，是否真的需要為所有的使用者（框架依賴方）修復缺陷、執行測試用例，答案是：Yes。

當類Foo裡的一個方法從bar()變為baz()，你可以構建一個工具，這個工具可以遍歷整個Google程式碼庫，自動搜尋所有的Foo類及其子類的例項，直接把它們修改為baz()。

效能指標

除了關注功能，谷歌還要求框架提供方關注提交程式碼後出現的效能問題。谷歌會自動為每一個使用方生成效能測試結果，這個效能測試是針對生產環境的，絕對真實。

Hermetic構建工具

對於大量的測試用例，開發人員當然不可能一個一個去執行，一個個修復缺陷，他們使用的是Bazel（開源構建程式碼工具）。在這個量級下你不可能使用一系列的shell指令碼構建工程，你需要的是hermetic構建工具。

hermetic在這裡的意思有點類似於“純正”，你構建的步驟不能有單邊影響（例如temo files、changes to PATH這些修改），修改需要是可以判斷的（例如輸入什麼導致輸入改變）。你可以在自己的機器上通過hermetic工具先執行測試用例，相當於你機器上的客戶端，執行通過後把改變程式碼提交到伺服器上並行構建它們。

總結

通過這種類似於提供方作為責任方的制度，讓谷歌的軟體開發人員對於每一行程式碼的提交都會非常謹慎，但是也對生產環境的程式穩定性、效能提供了充分的保障，此外，通過這種方式也會影響開發人員對於產品的開發思維，讓他們可以站在使用者的立場上思考如何更好地構建自己的框架，這其實也是在一定程度上推動技術和產品的發展。