經典講座 — 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 吧!

對抗久坐職業傷害

研究指出每天增加 2 小時坐著的時間,會增加大腸癌、心臟疾病、肺癌的風險,也造成肩頸、腰背疼痛等常見問題。

然而對抗這些問題,卻只需要工作時定期休息跟伸展身體即可!

你想輕鬆改變現狀嗎?試試看我們的 PomodoRoll 番茄鐘吧! PomodoRoll 番茄鐘會根據你所設定的專注時間,定期建議你 1 項辦公族適用的伸展運動,幫助你打敗久坐所帶來的傷害!

追蹤新知

看完這篇文章了嗎?還意猶未盡的話,追蹤粉絲專頁吧!

我們每天至少分享 1 篇文章/新聞或者實用的軟體/工具,讓你輕鬆增廣見聞提升專業能力!如果你喜歡我們的文章,或是想了解更多特定主題的教學,歡迎到我們的粉絲專頁按讚、留言讓我們知道。你的鼓勵,是我們的原力!

贊助我們的創作

看完這篇文章了嗎? 休息一下,喝杯咖啡吧!

如果你覺得 MyApollo 有讓你獲得實用的資訊,希望能看到更多的技術分享,邀請你贊助我們一杯咖啡,讓我們有更多的動力與精力繼續提供高品質的文章,感謝你的支持!