仓库源文

:Authors: Kenneth Lee :Version: 1.0

理解架构版本

架构版本是个很难维护的东西，它很容易被认为只是被选中的其中一个战术版本，和战术版本的区别仅仅是选择不同。这种理解带来很多战略和战术错误。本文解释到底什么是架构版本。

我提个建议，读者最好不要在认真看完本文的观点前直接认为自己懂什么是架构版本。因为架构版本看起来确实和战术版本是一样的，但它的使用方法不用，会导致它和战术版本完全不同。如果你非要先入为主地理解它，我们是无法形成共识的。

你写一个软件，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或者市场，甚至包括很多没有这种工作量控制经验的开发者）错误的思考模型，所以，不能让组织跳出这个模型，架构工作就无法展开了，而架构工作无法展开的最大问题就是把未来砸进去了。