許多成長迅速的工程團隊在初期都會選擇 Polyrepo 模式，也就是每個服務或函式庫都有自己獨立的 Git 儲存庫。這種做法能讓各個小組獨立運作，但在規模擴大到一定程度後，會產生嚴重的依賴管理問題。金融科技巨頭 Block（旗下包含 Cash App 與 Square）就經歷了這個痛點，他們將約 450 個基於 JVM 的儲存庫整合進一個單一的 Monorepo 中，旨在解決依賴漂移與協作成本過高的問題。
什麼是依賴漂移與鑽石依賴問題
在 Polyrepo 模式下，共用函式庫的更新需要經過發佈版本、下游服務更新版本號、重新編譯並部署等多個步驟。這導致不同服務使用的函式庫版本不一致，即依賴漂移 Dependency Drift。
更嚴重的是鑽石依賴 Diamond Dependency 問題。假設服務 A 依賴函式庫 B 和 C，而 B 與 C 同時依賴函式庫 D 但版本不同，這會在運行時導致不可預測的崩潰或錯誤。在 Polyrepo 中，這種衝突往往要到部署後甚至運行時才會被發現。而 Monorepo 允許所有服務直接引用最新的源碼而非預編譯的 JAR 包，讓衝突在編譯階段就能被發現並強制解決。
提升開發者體驗的關鍵技術
將數百個專案塞進同一個儲存庫會帶來巨大的效能壓力，尤其是 IDE 載入速度與 CI 編譯時間。Block 採取了以下實務方案來優化：
動態載入與 Artifact Swap
如果讓 IntelliJ IDEA 一次載入所有 450 個專案，IDE 會直接崩潰或變得極其緩慢。Block 開發了一個自定義插件，讓工程師只需指定目前開發的專案，其餘的依賴專案則透過 Artifact Swap 技術，將源碼引用動態替換為已發佈的 JAR 檔。這樣既能保有局部開發的靈活性，又能維持 IDE 的流暢度。
基於依賴圖譜的精準編譯
為了避免每次 commit 都觸發全量編譯，Block 建立了依賴圖譜 Dependency Graph。CI 系統會分析 PR 中修改的文件，將變更分為三類：直接影響該專案、間接影響下游專案、或屬於全局核心變更。只有受影響的範圍才會被觸發編譯與測試，這讓他們的 p90 CI 時間能維持在 10 分鐘左右。
規範化與所有權管理
為了防止 Monorepo 變成混亂的垃圾場，他們引入了 Gradle Convention Plugins（約定插件），定義了標準的模組類型，例如服務模組不能依賴另一個服務模組。同時利用專屬工具定義每個目錄的所有權，確保代碼審核與維護責任明確。
Monorepo 的限制與適用場景
雖然 Monorepo 帶來了原子更新 Atomic Updates（一次 Commit 即可同步修改多個服務）的便利，但它並非銀彈。Block 的經驗提醒我們，採用 Monorepo 前必須考慮以下兩點：
平台團隊的投入
Monorepo 對基礎設施的依賴極高。如果公司沒有願意投入資源的平台工程團隊來維護編譯工具、Git 性能優化與 CI 管道，Monorepo 會變成所有人的噩夢，因為單個專案的糟糕配置可能會拖慢整個公司的開發速度。
專案的同質性
Monorepo 在語言與框架統一（例如全都是 JVM 體系）時效果最好。如果專案包含大量互不相干的語言、完全不同的框架或開發風格，強行整合可能無法帶來足夠的效益，反而增加管理成本。
AI 時代的新契機
有趣的是，Block 發現 Monorepo 對 AI 輔助開發非常有利。由於所有上下文 Context 都在同一個儲存庫中，AI Agent 能更容易地理解跨服務的邏輯關聯，結合標準化的開發路徑，大幅提升了 AI 生成代碼的準確率與可用性。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。