版本迭代控制(Not Git/svn)
說到版本控制,大多數人的大腦中都一定會立刻想到 git
和 svn
吧,只可惜,這次的主角可不是他們
雖說 git 和 svn 雖好,對於一些專案也能夠進行很好的開發,但是呢,對於某些場景,還是有些 hold 不住的
比如,我們來舉一個場景:
現在我們的原始碼大約有 500M,然後呢,採用的是分支開發,主幹釋出,但是呢,因為我們是提供中間層 service 的,迭代週期很短,對於一些特殊的客戶,會時常有些特殊的邏輯處理,每個開發者可能會有好幾個分支進行開發,這個樣子的話,對於這些特殊邏輯,特殊版本的管理就非常的不方便,而且,因為每次都要拉出來一個分支,然後改動可能非常小,這就造成了非常大量的冗餘量
於是,這個場景中,冗餘量、大量迭代版本的管理,就上升到了我們的一個主要問題
如何解決呢?
單體程式碼庫
在這裡,我們引入一個節點(標籤)的概念,先來說一下整體思路
現在,我們就拋棄 git
和 svn
的思想,把所有的程式碼都放在一起,通過控制 節點粒度
來控制整體的冗餘
首先,節點粒度我們先設定為以檔案為單位,同時呢,約定我們的命名規範,檔名.節點標識.php
,例如 Test.v1.php
接下來呢,就會有我們原始的版本,在這個原始的版本里面,所有的檔案都是 base 節點
所有的檔案都會有一個父節點,最終都是繼承與 base 節點的
當我們需要迭代到 1.0.1 版本的時候,我們只要把需要改動的檔案 copy 一個副本,然後按規範命名,接著只需對於這一個檔案進行改動,這樣,冗餘的粒度就控制在了這個檔案內
大大減少冗餘的同時,還大大的提高了程式碼的複用,避免了菱形依賴,不同團隊間的跨團隊協作也變得更加靈活
接下來,我們怎麼能夠正常呼叫呢?
所以說,這種單體程式碼庫需要一個路由引擎來驅動,這就要我們根據實際情況來實現了,可以直接根據節點表示來路由,也可以在中間加一層路由對映表,這就看具體需求了
同理,我們可以進一步調整節點粒度,來控制整體的冗餘,比如,粒度細化到介面級別
~~~~~~~~~~~~~~~~~~~~~~~ 萌萌噠的分割線 ~~~~~~~~~~~~~~~~~~~~~~~
好了,下面就來分析一下這種單體程式碼庫的優劣
優點:
統一版本控制
廣泛地程式碼共享和複用
簡化依賴管理,避免菱形依賴
原子修改
大規模重構
跨團隊協作
靈活的團隊邊界和程式碼所有權
程式碼可見性以及清晰的樹形結構提供了隱含的團隊名稱空間
但是呢,隨著程式碼量的增加,也會出現以下問題:
單體模型讓程式碼結構更容易理解,但卻讓程式碼發現變得更困難
開發人員需要能夠檢視程式碼庫,找到相關程式庫,並看看如何使用它們以及誰編寫了它們。這就需要有程式碼搜尋和程式碼瀏覽工具
依賴重構和程式碼清理輔助工具,定期對無用程式碼進行清理
版本管理的重心轉移到了冗餘控制上
所以說呢,對於管理,我們就需要開發一套額外的自動化工具了,比如說:
程式碼庫搜尋工具:因為我們採用了單體程式碼庫,所以慢慢的程式碼越來越多,程式碼搜尋工具就變的必不可少了
程式碼發現工具:也是為了維護程式碼庫,定期發現清理無用程式碼
可能根據大家的實際情況,也需要一些其他的自動化工具
歡迎關注我的部落格,不定期更新干貨哦 ~