一個簡單但整體式的代碼庫與許多明確記錄的依賴關係

Question

通常，當開始一個新項目時，我首先從我認爲是如何構建代碼庫的最佳意圖入手。我喜歡無數小模塊的想法，這些模塊能夠很好地完成一件事，從代碼庫的其他部分分離出來，並且可能會在其他（類似）項目中被我自己重用，或者爲其他人利用而開源。但是，當我實際嘗試將某些東西投入到生產中時，已經有不止一次的情況，即管理所有這些不同模塊的複雜性已經證明了過多的開銷（儘管具有良好的文檔和部署方法）。在那些時候，我只是改變了方向，並將所有模塊捆綁到一個存儲庫中，並將其作爲一個代碼庫進行管理，這意味着我可以通過不同的分支一起跟蹤所有內容，部署到分段和測試環境等...

這些不同方法的優缺點是什麼，以及如何以某種方式管理工作？

優勢之一單片代碼庫：

• 易於部署
• 易於回滾
• 易於分支/管理所有的變化一起
• 沒有（或更少）的潛在複雜的依賴關係記錄和管理

模塊化依賴關係的優點：

• 重用
• 清潔架構（一個模塊做一件事）

Answer 1

我沒有看到對立​​和你一樣多。以.NET體驗爲例，我可以確保我的代碼部分適合於定義明確的職責，我可以將我的代碼庫構造到名稱空間中，確保名稱空間的觸摸點已定義良好，並且相同名稱空間內的類真的屬於一起。

但是，所有這些都可能發生在單個部署單元，單個項目，分支，你有什麼。如果你堅持這樣做，那麼在你做的項目的上下文中可能重用的代碼單元將會結晶化，這就是你可能決定引入一個新的代碼單元的地方，它有自己的部署製品，源代碼控制分支等

Answer 2

這是Google explaining (a little bit) how they handle their gigantic monolithic code repository的演講。爲什麼他們有一個。

順便說一句，我不認爲它必須反對一個明確定義的依賴關係。我甚至會說，要處理一個單一的代碼庫，你必須對依賴關係圖和責任進行超級小心。因爲有了這樣的組織，很容易添加很多更多或更少的有用代表...