說到版本控制，大多數人的大腦中都一定會立刻想到 git 和 svn 吧，只可惜，這次的主角可不是他們

雖說 git 和 svn 雖好，對於一些專案也能夠進行很好的開發，但是呢，對於某些場景，還是有些 hold 不住的

比如，我們來舉一個場景：

現在我們的原始碼大約有 500M，然後呢，採用的是分支開發，主幹釋出，但是呢，因為我們是提供中間層 service 的，迭代週期很短，對於一些特殊的客戶，會時常有些特殊的邏輯處理，每個開發者可能會有好幾個分支進行開發，這個樣子的話，對於這些特殊邏輯，特殊版本的管理就非常的不方便，而且，因為每次都要拉出來一個分支，然後改動可能非常小，這就造成了非常大量的冗餘量

於是，這個場景中，冗餘量、大量迭代版本的管理，就上升到了我們的一個主要問題

如何解決呢？

單體程式碼庫

在這裡，我們引入一個節點（標籤）的概念，先來說一下整體思路

現在，我們就拋棄 git 和 svn 的思想，把所有的程式碼都放在一起，通過控制 節點粒度 來控制整體的冗餘

首先，節點粒度我們先設定為以檔案為單位，同時呢，約定我們的命名規範，檔名.節點標識.php，例如 Test.v1.php

接下來呢，就會有我們原始的版本，在這個原始的版本里面，所有的檔案都是 base 節點

所有的檔案都會有一個父節點，最終都是繼承與 base 節點的

當我們需要迭代到 1.0.1 版本的時候，我們只要把需要改動的檔案 copy 一個副本，然後按規範命名，接著只需對於這一個檔案進行改動，這樣，冗餘的粒度就控制在了這個檔案內

大大減少冗餘的同時，還大大的提高了程式碼的複用，避免了菱形依賴，不同團隊間的跨團隊協作也變得更加靈活

接下來，我們怎麼能夠正常呼叫呢？

所以說，這種單體程式碼庫需要一個路由引擎來驅動，這就要我們根據實際情況來實現了，可以直接根據節點表示來路由，也可以在中間加一層路由對映表，這就看具體需求了

同理，我們可以進一步調整節點粒度，來控制整體的冗餘，比如，粒度細化到介面級別

~~~~~~~~~~~~~~~~~~~~~~~ 萌萌噠的分割線 ~~~~~~~~~~~~~~~~~~~~~~~

好了，下面就來分析一下這種單體程式碼庫的優劣

優點：

• 統一版本控制

• 廣泛地程式碼共享和複用

• 簡化依賴管理，避免菱形依賴

• 原子修改

• 大規模重構

• 跨團隊協作

• 靈活的團隊邊界和程式碼所有權

• 程式碼可見性以及清晰的樹形結構提供了隱含的團隊名稱空間

但是呢，隨著程式碼量的增加，也會出現以下問題：

• 單體模型讓程式碼結構更容易理解，但卻讓程式碼發現變得更困難

• 開發人員需要能夠檢視程式碼庫，找到相關程式庫，並看看如何使用它們以及誰編寫了它們。這就需要有程式碼搜尋和程式碼瀏覽工具

• 依賴重構和程式碼清理輔助工具，定期對無用程式碼進行清理

• 版本管理的重心轉移到了冗餘控制上

所以說呢，對於管理，我們就需要開發一套額外的自動化工具了，比如說：

• 程式碼庫搜尋工具：因為我們採用了單體程式碼庫，所以慢慢的程式碼越來越多，程式碼搜尋工具就變的必不可少了

• 程式碼發現工具：也是為了維護程式碼庫，定期發現清理無用程式碼

可能根據大家的實際情況，也需要一些其他的自動化工具

歡迎關注我的部落格，不定期更新干貨哦 ~