經典講座 — Why Google Stores Billions of Lines of Code in a Single Repository

“Why Google Stores Billions of Lines of Code in a Single Repository” 是由 Google 的 Engineering Manager 分享的 Talk, 分享 Google 選擇 monolith repository 集中存放所有產品程式碼的理由與 Google 如何進行開發流程等做法。

以 Google 的量級來說，多數人直覺會認為選擇 monolith 的作法相當瘋狂，不過 monolith repository 有個極大的好處是可以提高 code reuse 與團隊協作的能力，避免各團隊重複開發/維護的成本，確保這個 repository 就是 single source of truth, 再也沒有其他變異版本的程式碼了，而且大家都擠在同 1 個 repository 做事，自然就會讓團隊很重視 code health, 把 unused, underuse 的程式碼給盡力清除，避免過高的技術債。

也許正是 Google 的量級夠巨大，才能藉由選擇 monolith repository 的做法，讓所有人能夠更注重 code reuse 與 code health 。

有好處就有壞處，使用 monolith repository 的明顯壞處則是一旦弄壞某個程式碼，或者某個關鍵核心組件，相依賴的所有產品/功能都會因此故障，所以在開發/測試流程也會需要更謹慎，時間肯定會拖得久一些，也因此 Google 相當倚賴自動化工具的幫忙，從 talk 中可以知道 Google 投資了相當多自動化工具，以在開發流程的每個步驟都確保程式碼的品質與避免有人的程式碼毀了大量功能。

雖然採用 monolith 還是 multi-repo 並沒有絕對正確的作法，一切都是依照團隊需求與面臨的問題而做出不同的選擇，但根據經驗多數情況下，採用 monolith 會比較好，畢竟在多個 repositories 之間切換、開發很花時間之外，多個 repositories 如果要共享程式碼/邏輯也容易產生後續維護的問題，一旦某個 repo 改了共享的核心程式碼，那麼所有的 repo 的開發團隊會有 2 種選項，一是保持在舊版本，二是跟上新版本，但我想多數團隊都是選擇保持在舊版本，如此長久下來，一份核心程式碼就有著各種版本存在，絕對會對維持 code health 形成一種挑戰。

個人就曾遇過用沒幾項產品/服務的公司，卻有著超過上千 repositories 的情況，開發時需要重新發明輪胎或者把 code 從某 repo 複製過來的情況，或者一旦要升級、移除某個 API 還要四處詢問有哪個團隊正在使用該 API 的情況⋯⋯，或者三不五時要清查各個 repository 到底用途是什麼，以及有沒有人使用。

這時候我總會心底浮現疑問「使用 multi-repo 到底是在製造問題還是解決現階段還不存在的問題？」

總之，如果你想使用 multi-repo 管理程式碼嗎？在動手之前，不妨先看看 Google 為什麼選擇 monolith 吧！