理解架構版本

01-28

架構版本是個很難維護的東西，它很容易被認為只是被選中的其中一個戰術版本，和戰術版本的區別僅僅是選擇不同。這種理解帶來很多戰略和戰術錯誤。本文解釋到底什麼是架構版本。

我提個建議，讀者最好不要在認真看完本文的觀點前直接認為自己懂什麼是架構版本。因為架構版本看起來確實和戰術版本是一樣的，但它的使用方法不用，會導致它和戰術版本完全不同。如果你非要先入為主地理解它，我們是無法形成共識的。

你寫一個軟體，a.c, b.c, c.c, a.h, b.h, c.h, Makefile, http://configure.in，README，好吧，一點點寫過來，這形成一套代碼，這個軟體（的源代碼形態），我稱為構架版本，我用A表示。

現在我需要交付給客戶了，我把這個程序編譯成B1，這個版本，我稱為戰術版本，或者戰地版本。B1和編譯成的二進位是關聯的，我們把B1的代碼稱為B。看起來，在這個時間，A和B的代碼完全一樣，但他們不是同一個東西——因為B中實際上還包含了如何編譯B1的信息（配置項，編譯選項等）。因為你交付了，所以必須關注在乎你當時是如何編譯B1的。

這看起來是個小事，但你很快會看到，這個小事會造成一個巨大的決策誤區。

大部分時候，你還是需要繼續開發的，新開發的功能合入什麼地方？顯然是A。B和A已經脫離開了。這個是不受你控制的，你要能在得到這個客戶的認可，要把在他這個場合把性能調到最優，你就要不斷基於這個場合進行優化，而且不能輕易加入新功能。A和B被不同的邏輯左右著。你也許看到你的手機不斷在升級軟體，但那個升級其實是B分支的升級，不可能作很大改動的。

OK，隨著市場的擴展，你在B之外，就會發生C，D，E這樣的戰地版本。你當然希望盡量用一個版本打所有的市場，但這個其實受市場本身的限制，你在存儲伺服器和前端伺服器上使用一個配置和優化？你這幾乎就是綁著手和別人打了。要不你像Apple一樣牛，靠創新來拉出距離，控制供應商，限制範圍，你可以在一定程度上做到，但這是要很高成本的。

一旦進入這種局面。誤判就來了。

首先，A，B，C，D都不過是代碼，看起來毫無區別，那麼我們對待B，C，D這麼多質量保證措施，A要不要也一樣？QA部門天天過來給我聒噪這個，反正B，C，D的人都投進去了，怎麼你的A團隊例外呢？你們也應該做這種測試，算bug收斂曲線才對啊。「我們『知道』（其實是『原諒』）你們有點特別，但至少要差不多嘛」。

接著就是市場的兄弟過來了，B，C，D都缺某個特性，客戶又急著要，臨時把A編譯一下，拿去頂一下好不好。「我靠，新功能還沒有用呢，怎麼性能比B還差20%，你們怎麼搞的？平時都不用測試一下的嗎？投在A上的錢都喂狗了。」

所以，維護A是很被動的，「僅僅編譯一下」，是會形成一個戰術版本的好不好？戰術版本要調優的好不好，要市場目標的好不好？開不開調試選項？用-O0還是-O3編譯？性能/質量都會不一樣的好嗎？戰地版本真的只是編譯的成本嗎？

我們當然可以讓開發者都投在B上，這些問題就可以解決，但B頂著市場壓力，如果開發者投在B上，新功能根本就不敢開發。所以，這種情況通常會形成這種局面：讓A依附在B上（說A是B的一個分支即可，QA和市場都看不懂這個），A開發完了，馬上到B上轉測試，A也存在，另一方面B的質量是有保證的，市場要用，反正特性沒有到B之前，我們認為特性沒有開發完就可以了。

在不做開源前，我就是這樣和質量部/市場部的同學們玩的。但到玩開源的時候，這個遊戲就玩不了了。比如你基於Linux做開發，Linux主線現在是4.9，但Ubuntu的1604LTS版本還是4.4呢，你怎麼讓你4.9的開發依附在4.4的開發後面？

我們還有一個選擇，就是基於4.9出一個戰術版本，開發完4.9，通過戰術版本進行質量保證和性能調優。但Linux內核的升級速度是2個半月，我用兩個半月時間保證了一個版本的質量和性能，然後這個版本（如果用不上）馬上作廢，然後升級為4.10，然後我又做一次質量保證和性能調優？敗家不是這樣敗的是吧？

所以，除了不斷掃盲什麼是架構版本，已經無路可走了。如果在宣傳戰上不能讓人接受構架版本的概念，團隊很容易就掉落成為一個戰術版本。而在戰略比拼中，只有戰術版本的，如何保證未來？

其實，這個問題的本質是：開發要不斷補充特性，質量保證和性能調優要有穩固的特性，這兩者都需要分支來支持，而質量保證和性能調優有很高的工作量要求，我們要控制這個工作量，就要正視這個工作量，但過去版本少的經驗給了非開發部門（比如QA或者市場，甚至包括很多沒有這種工作量控制經驗的開發者）錯誤的思考模型，所以，不能讓組織跳出這個模型，架構工作就無法展開了，而架構工作無法展開的最大問題就是把未來砸進去了。