本文同步刊載於個人連載網站

Day 17 寫到，一個使用者看到的功能，進到系統裡之後，可能會被拆成很多不同性質的責任。

這個專案在真正開始實作以前，mentor 就已經建議把前端、後端和文件處理服務拆成不同 repo。

當時的理由很直接：

未來部署和維護時，這些部分可能需要分開管理。

所以專案一開始就是 multi-repo。

但我的開發方式同時又是 AI Coding。

這就帶來另一個需求：

部署時要能分開，開發時又不能把整套產品看碎。

repo 可以分開，但功能本身不會跟著分開

從 Git 的角度看，前端、後端和文件處理服務都在不同 repo。

但對使用者來說，他還是在使用同一套產品。

一個功能可能同時需要：

前端增加操作。

後端處理規則和資料。

文件處理服務讀取或產生文件。

這些事情在程式裡分散在不同地方。

但對使用者來說，它們共同完成的還是同一件工作。

所以 multi-repo 不代表：

把產品切成幾個彼此無關的小專案。

更接近的是：

讓不同責任可以分開管理，但仍然必須一起完成同一套產品。

開發時，我需要的是整套產品的上下文

因為我的實作主要交給 Codex，所以本機會把這些 repo 放在同一個 workspace 裡。

這樣討論一個跨系統需求時，Codex 可以一次看到相關的程式和文件。

如果它只站在後端 repo 裡看問題，可能只會看到這個功能的其中一段。

後端改完了，不代表前端不用改。

API 回傳格式變了，前端接資料的方式可能也要一起變。

文件處理方式改了，也可能影響主要後端怎麼呼叫它。

所以對我的開發方式來說：

repo 可以分開，但 AI 需要的產品上下文不能跟著被切斷。

Coordination repo 負責保留「整件事情」

這個專案另外還有一個純文件的 Coordination repo。

它不負責執行產品功能。

主要用來保存跨 repo 都需要知道的東西，例如：

• 共同規格
• 架構資訊
• 跨系統變更
• 彼此之間的約定

對我來說，它回答的是一個很直接的問題：

每個 repo 都在做自己的部分，那整件事情放在哪裡？

不同程式 repo 可以各自管理自己的實作。

但一個真正跨過多個 repo 的需求，還是需要有地方保存：

這次整體要改什麼。

哪些部分一起受到影響。

前後端彼此怎麼配合。

哪些約定需要一起維持。

這些共同脈絡如果只散落在各 repo 裡，很容易每一邊都只看見自己的部分。

每個 repo 正常，不代表產品就正常

這件事情最具體的一個例子，就是 API Contract。

前端和後端已經是不同 repo。

但它們還是需要對彼此交換的資料有共同理解。

假設後端把一個欄位名稱改掉。

單看後端，API 可能正常。

前端 repo 自己也可能沒有任何錯誤。

但兩邊一接起來，前端還在等舊欄位，整套產品就會出問題。

這讓我開始看懂：

不能只確認每一個 repo 自己有沒有正常。

還要確認：

它們彼此之間原本說好的東西，有沒有一起維持。

API Contract 是其中一種約定。

跨 repo 的規格與設計也是。

系統一旦拆開，這些「中間」的東西就變得更重要。

拆開之後，還需要有人維持整體

Day 17 時，我開始理解：

不同性質的工作可以拆成不同系統責任。

到了這裡，我又看到另一面。

責任拆開，不代表整體就會自己維持。

前端可以專心做好前端。

後端可以專心做好後端。

文件處理服務也可以專心處理文件。

但真正的產品還存在於它們彼此配合的地方。

對我來說，Coordination repo、本機 workspace 和跨 repo 的共同規格，本質上都在做同一件事：

讓已經拆開的部分，還看得到它們共同在完成什麼。

所以我現在會把 multi-repo 理解成兩個同時存在的需求：

責任要能分開管理。

以及：

產品脈絡不能因此被切斷。

拆開，是為了讓不同部分各自負責適合自己的事情。

但真正的產品開發，還是要讓這些分開的部分一起完成同一件事。

而當這些共同規格和架構資訊開始越來越多之後，我又遇到下一個問題：

只知道現在決定怎麼做，夠嗎？