這兩年工作中比較大的一個感受就是隨着產品的B端用戶增多，產品的架構版本開始變得難以維護，這和我之前做C端產品是完全不一樣的。本文就來分享一下ToB產品的架構版本維護中的坑，希望能讓大家對架構版本有更多的瞭解。
我們開發了一套系統，從無到有寫過來，這個時候我們還沒有具體的客戶，只是形成了一套初始的代碼，這套系統具備第一個架構版本，我用A來表示。
現在商務找到了我們第一名客戶，我們需要交付給客戶了，我們把這套系統做成版本B1，這個版本就是我們的客戶版本。我們把B1的代碼稱爲B。看起來，在這個時間，A和B的代碼是完全一樣的，不過由於B，我們還實際交付了B1的個性化信息（配置項，編譯選項等）。
毫無疑問的，我們還是需要繼續開發的，新開發的功能合入什麼地方？顯然是A。而對於B而言，我們就要不斷基於它對應的場合進行優化，而且不能輕易加入新功能。A和B被不同的邏輯左右着，決定了我們對B分支的升級，是不會輕易做很大改動。
隨着市場的擴展，我們除了B之外，就會發生C，D，E這樣的客戶版本。我當然希望用一個版本打所有的市場，但這個其實受市場本身的限制，在現實中需要很高的成本。
當我們有多個版本需要維護，那麼就有挑戰來了。
首先，我們平時的精力主要投在B，C，D上，我們對它們有更充足的質量保證措施，A反而被“冷落”了，由於我們的新特性做在A上的，B，C，D都缺某個特性，客戶又急着要，臨時把A做一個版本出來，拿去頂一下好不好？結果發現A的質量又跟不上，部署上去就無法給客戶一個交代。。。
其實，這個問題的本質是：開發要不斷補充特性，質量保證和性能調優要有穩固的特性，這兩者都需要分支來支持，而質量保證和性能調優有很高的工作量要求，我們要控制這個工作量，就要正視這個工作量。
所以，到最後，我制定了一套統一做法：
主幹版本開發新特性並保證質量，交付局點時使用對應分支，維護不同的分支。
分支上一般少新特性開發，僅問題修改。
不同分支版本多了以後，就考慮版本收編，使用主幹的版本升級。
由於制定了這套策略，我們會花更多的時間在A上，確保A一直處於“戰備”狀態，及時響應不同客戶的更新訴求。
本篇是拋開了技術架構本身來談版本的維護，接下來我會重點談談從架構的角度來做好ToB產品的版本維護。
描二維碼或手動搜索微信公衆號【架構棧】： ForestNotes
歡迎轉載，帶上以下二維碼即可
點擊“閱讀原文”，所有【架構棧】近期的架構文章彙總
↓↓↓