Monorepo 是一種管理企業代碼的方式，在這種方式下會摒棄原先一個 module 一個 git repo 的方式，而是把所有的 modules 都放在一個 repo 內來管理。單體倉庫 monorepos 是一個包含了多個獨立 project 的代碼倉庫，一個代碼 repository 包含一個單體倉庫。
目前有 Babel, React, Angular, Ember, Meteor 等等專案都使用了這個專案管理方式。
multirepos
當一個軟體專案隨著功能跟開發人員的擴增，漸漸地會發生共用程式碼的問題，一個大型的專案會拆分出多個小型 repos，每個 repo 代表了一個單獨的離散想法。
但也因為多個平行專案的發展，會發生一些問題：
架構孤島: 因為在一個整合專案中，拆分了功能並分配給不同的開發團隊處理及發展，每個團隊在不同的精進道路上，使用了不同的 library，好處是工程師可以根據自由選擇適當的 library，缺點是越來越多的 library，表示開發人員必須花更多時間學習不同的架構。
依賴地獄（Dependency Hell）: 某個程式的修正，會影響到多少專案，在專案整合建構時，會需要很多時間找出整合的問題並提出修正。
建構耗時: 傳統的循序建構方式，會需要數十分鐘的時間，因應 monorepo 提供的新 build tool，可以平行建構加速建構的過程，也有更快的 incremental build 模式。
build tool
在 monorepo 中會搭配使用一個適當的 build tool，原因當然是為了在這樣的環境下，縮短建構的時間。
沒有萬靈丹
在一個專案建置初期，會因為開發維護的工程師人數不多，傾向於建置一個單一的專案進行開發，隨著應用本身的演進，公司的業務成長，會慢慢增加這個專案開發的參與人員數量，甚至會成長到有一個或多個開發 team。
在多人分工開發的環境下，就會面臨切割專案，抽取共用的函式庫的過程，一般的直覺，就是讓不同的專案模組有各自獨立負責的人員/團隊，也就是有各自獨立的版本演進，最後再整合在一起。
但如果分工是用垂直方式分工，以功能的方式分工，就有可能會造成程式碼的衝突，或是撰寫出來的程式運作的邏輯不同，或是使用了不同的輔助函式庫的問題。
這情況又有 monorepos 這樣的解決方案，想要解決這種問題。
應該說不管什麼樣的方案，都會有相對應的優點及缺點，那就要看每一個使用的情境來決定，該用什麼方式處理，讓優點多一點，缺點少一點，也沒有必要換來換去，畢竟轉換作業方式，加上適應的過程，也需要花上不少時間。
《三國演義》的第一句話就說：「話說天下大勢，分久必合，合久必分。」整體的局勢就是在分分合合中，不斷地來來往往反覆進行。
沒有留言:
張貼留言