版本迭代控制（Not Git/svn）

說到版本控制，大多數人的大腦中都必定會馬上想到 git 和 svn 吧，只惋惜，此次的主角可不是他們

雖然說 git 和 svn 雖好，對於一些項目也可以進行很好的開發，可是呢，對於某些場景，仍是有些 hold 不住的

好比，咱們來舉一個場景：

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

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

如何解決呢？

---

單體代碼庫

在這裏，咱們引入一個節點（標籤）的概念，先來講一下總體思路

如今，咱們就拋棄 git 和 svn 的思想，把全部的代碼都放在一塊兒，經過控制 節點粒度 來控制總體的冗餘

首先，節點粒度咱們先設定爲以文件爲單位，同時呢，約定咱們的命名規範，文件名.節點標識.php，例如 Test.v1.php

接下來呢，就會有咱們原始的版本，在這個原始的版本里面，全部的文件都是 base 節點

全部的文件都會有一個父節點，最終都是繼承與 base 節點的

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

大大減小冗餘的同時，還大大的提升了代碼的複用，避免了菱形依賴，不一樣團隊間的跨團隊協做也變得更加靈活

接下來，咱們怎麼可以正常調用呢？

因此說，這種單體代碼庫須要一個路由引擎來驅動，這就要咱們根據實際狀況來實現了，能夠直接根據節點表示來路由，也能夠在中間加一層路由映射表，這就看具體需求了

同理，咱們能夠進一步調整節點粒度，來控制總體的冗餘，好比，粒度細化到接口級別

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

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

優勢：

• 統一版本控制

• 普遍地代碼共享和複用

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

• 原子修改

• 大規模重構

• 跨團隊協做

• 靈活的團隊邊界和代碼全部權

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

可是呢，隨着代碼量的增長，也會出現如下問題：

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

• 開發人員須要可以查看代碼庫，找到相關程序庫，並看看如何使用它們以及誰編寫了它們。這就須要有代碼搜索和代碼瀏覽工具

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

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

因此說呢，對於管理，咱們就須要開發一套額外的自動化工具了，好比說：

• 代碼庫搜索工具：由於咱們採用了單體代碼庫，因此慢慢的代碼愈來愈多，代碼搜索工具就變的必不可少了

• 代碼發現工具：也是爲了維護代碼庫，按期發現清理無用代碼

可能根據你們的實際狀況，也須要一些其餘的自動化工具