[TOC] ## 概述 ### 單一代碼庫的好處 乍一看，單一代碼庫和多代碼庫之間的選擇似乎不是什么大問題，但這是一個會深刻影響到公司開發流程的決定。至于單一代碼庫的好處，可以列舉如下： * **可見性（Visibility）**：每個人都可以看到其他人的代碼，這樣可以帶來更好的協作和跨團隊貢獻——不同團隊的開發人員都可以修復代碼中的 bug，而你甚至都不知道這個 bug 的存在。 * **更簡單的依賴關系管理（Simpler dependency management）**：共享依賴關系很簡單，因為所有模塊都托管在同一個存儲庫中，因此都不需要包管理器。 * **唯一依賴源（Single source of truth）**：每個依賴只有一個版本，意味著沒有版本沖突，沒有依賴地獄。 * **一致性（Consistency）**：當你把所有代碼庫放在一個地方時，執行代碼質量標準和統一的風格會更容易。 * **共享時間線（Shared timeline）**：API 或共享庫的變更會立即被暴露出來，迫使不同團隊提前溝通合作，每個人都得努力跟上變化。 * **原子提交（Atomic commits）**：原子提交使大規模重構更容易，開發人員可以在一次提交中更新多個包或項目。 * **隱式 CI（Implicit CI）**：因為所有代碼已經統一維護在一個地方，因此可以保證持續集成\[3\]。 * **統一的 CI/CD（Unified CI/CD）**：可以為代碼庫中的每個項目使用相同的 CI/CD\[4\]部署流程。 * **統一的構建流程（Unified build process）**：代碼庫中的每個應用程序可以共享一致的構建流程\[5\]。 ### 單一代碼庫的缺陷 隨著單一代碼庫的發展，我們在版本控制工具、構建系統和持續集成流水線方面達到了設計極限。這些問題可能會讓一家公司走上多代碼庫的道路： * **性能差（Bad performance）**：單一代碼庫難以擴大規模，像 git blame 這樣的命令可能會不合理的花費很長時間執行，IDE 也開始變得緩慢，生產力受到影響，對每個提交測試整個 repo 變得不可行。 * **破壞主線（Broken main/master）**：主線損壞會影響到在單一代碼庫中工作的每個人，這既可以被看作是災難，也可以看作是保證測試既可以保持簡潔又可以跟上開發的好機會。 * **學習曲線（Learning curve）**：如果代碼庫包含了許多緊密耦合的項目，那么新成員的學習曲線會更陡峭。 * **大量的數據（Large volumes of data）**：單一代碼庫每天都要處理大量的數據和提交。 * **所有權（Ownership）**：維護文件的所有權更有挑戰性，因為像 Git 或 Mercurial 這樣的系統沒有內置的目錄權限。 * **Code reviews**：通知可能會變得非常嘈雜。例如，GitHub 有有限的通知設置，不適合大量的 pull request 和 code review。 ### 真實案例 查看 [React](https://github.com/facebook/create-react-app/tree/main/packages).可以看到`packages`文件夾下面有很多個子模塊，如`create-react-app`、`react-dev-utils`、`react-scripts`...，這些模塊全都可以獨立的發布到`npm`上 ## 前端使用 lerna 進行管理 [lerna 管理包含多個軟件包](../../%E5%89%8D%E7%AB%AF/lerna%E7%AE%A1%E7%90%86%E5%8C%85%E5%90%AB%E5%A4%9A%E4%B8%AA%E8%BD%AF%E4%BB%B6%E5%8C%85.md)