.. Kenneth Lee 版权所有 2021
:Authors: Kenneth Lee :Version: 1.0
架构首先是一种信念
架构首先是一种信念。
架构设计有很多具体的技术，但要理解架构，理解这些技术是没有用的。架构首先是一种 信念，没有这个信念，所有技术都没有意义。
这句话听起来特别鸡汤。所谓鸡汤，喝起来香甜，感觉上充满能量，做起来不可行。 所以，其实所有“前识”，都是鸡汤，因为都不是实在的东西。所以，鸡不鸡汤的，最终还 是看结果，我这里的总结，是我的认知，是否信任，需要你和经验去校验，我不在乎它 “像”还是“不像”鸡汤，我只是把这个Pattern建出来。
所谓Pattern，有人翻译做“模式”，但从英文的原意来说，它是印在一些布料上一个个重复 的图案，也许翻译为“花纹”才是合适的。很多时候，我们用这个词，是用它的两个意象：
我们看到一件事情的“因果”，认为其他事情也会具有一样的“因果”；
我们把因果看作是一种“自然观察”，而不是一种必须发生的程序。是人（大自然）印了 多个重复的图案，不是有了那个因，就必然有那个果。
现在我们看看这个Pattern，为什么说架构首先是一种信念。
我们应该有一个基本的共识：架构不是现在做什么，而是为现在应该做什么提供“理由”的 一种未来设计。而正如前面说的，对于这些“理由”，我们只是在描述一种Pattern，而这个 Pattern是否必然成立，不到未来，我们无法确认。而且就算到了未来，Pattern千千万， 凭什么认为你认为的那个Pattern才是Pattern。为什么非要认为你现在饱了，是因为你刚 才吃了饭，而不是因为你刚才你喝了水，或者你被你男朋友气着了（气饱了）？
但经验仍然存在，你看过一次次吃饭吃饱了，喝水没有喝饱，你的信念支持你必须吃饭。 千百次做一个高层设计然后编码效果更好，你就是知道先Layout高层设计，然后再编码效 果就是会好，这就是你的经验。也是你坚持做这种“不直接产出”的事情的“信念”。
我们必须强调这种信念，是因为，缺乏信念的支持，“不直接产出”的事情是没法干的。房 子马上要塌了，但不是还没有塌吗？为什么要马上住到窝棚中？为什么现在就要拆房子重 盖？住窝棚中这个煤炉放哪里？这套美丽的沙发放哪里？我们还赶着去上学，为什么回家 连睡个好觉都不行？……
不做架构不会有“表面上”的问题的，你永远都可以用“这个事情本来就是会这样发生的”， 或者“这本来就是架构设计的一部分”，来做解释。一旦你可以这样解释了，你就无所谓架 构了，因为你可以自由地放飞自己，为自己的一切行为做解释。
所以，把架构放高，让我们为这个目标不得不进行选择，让我们在进行细节设计的时候必 须承担失败，非常重要。比如，我们设定一组交付件，要求我们的特性都落实到这组交付 件上（4+1架构方法中开发视图的标准功能），这会保证我们在进行每个具体细节设计的时 候，不得不面对我们的代码必须可以在不同情况下都是可以落地下去的。而你不设定这组 交付件，你甚至可能最后都可以宣称，我确实也有一组这样的交付件。你觉得结果是一样 的，但其实不是，因为这是“自然发生”的结果，你逃过了所有的困难，你的设计逻辑不是 向着一个可以满足市场交付目标去的，最后你都能解释得通，但你的目标可能就丢失了。
我要说的Pattern说完了。但我想经过我这个描述，读者不一定注意到我说的Pattern是什 么，请允许我换一个角度再说一遍，以便读者更容易定位到我说的Pattern是什么：
架构是为了达成目标抽象出来的Pattern，它不是达成目标的全部逻辑。所以，做了架 构和没有做架构，常常是看不出区别的。你可以把你做某件事情的过程中做过的事情提 取一些要素出来，说“这就是我的架构，就是我的控制，因为我做了这件事情，所以我 们才有今天的局面”。我甚至见过一些架构师，接手某个产品以后，扔一句口号出来（ 比如“版本归一”），然后把所有工作都归结为是在执行这句口号，最后做成啥样都声称 这是“成功的”。这种情况下，所有行为其实都是被细节设计所驱动的，他们仍把这称为 是“架构设计”，但其实这不是。对于守成的产品，只要产品还能卖，你都可以说这是 “最好的结果”，但这并不是在做架构。
真正在做架构的，是在“自由的细节设计之外”，针对一个更高的目标做一个高层逻辑， 然后在一定程度上坚信这个高层逻辑，这会对“自由的细节设计”产生额外的约束。这些 约束让细节设计的工程师感到痛苦，也让希望马上看到效果的管理者也感到痛苦，但 因为我们要达成那个真正的目标，我们上下都承认，我们必须承担这种痛苦。
比如，我们希望给硬件建立一个广泛的生态，我们架构上把每个驱动都上传Linux的主 线，再变成发行版，这是一个痛苦而没有“肉眼可见”收益的过程，但这样以后，我们随 时可以用到各种最新的特性。如果我们放弃架构控制，我们同样可以做一个自己的Linux 分支，而且你觉得你做了什么，按时就能得到什么，好像一切很美好，但这个分支最后 只会被限制在一个小众的范围内。前者是架构控制，后者是自然生长。前者才是有必要的， 后者，你不能说它这样就不行了，但后者没有架构设计，不需要架构师在那里装样子。
又比如，我们要给生态的用户一个稳定的使用环境，我们就不但要做驱动的上传，我们 还要主动维持一组稳定的发行版，但确实，发行版不是我们自己的，这中间会有变化， 但一旦我们决定要维持这个局面，我们进行各种优化，我们新工具的开发，都要以这个 变化的集合为中心进行控制。这样一个控制的过程会让团队很痛苦，远不如“直接上传 主线，其他不是我的问题”这种“自然生长”来得痛快和简单。但正因为有了前者，我们才 有了架构控制的需要，这是所图者大才有的需要，否则也不需要架构师。
说到底，我这里强调的“信念”，要强调的是：不同于具体设计，架构设计是很容易被放弃 的一种设计，因为它的距离太长，人很容易迷失在中间的具体问题上，如果操盘者没有坚 持下去的决心（决心不等于死板），架构很容易成了一句口号，最终什么都没有做。
我的架构设计理念，给过很多具体做设计的人讲，也给过很多管理者讲。我最容易听到的 一种意见是“你到底要我们干什么？你能不能具体一点？”
这句话常常让我很失落。因为我是一个挺务实的人，我一点都不希望自己变成一个只说鸡 汤，不会实操的人。
我也尝试去接受这个意见，给他们一些“具体的要求”，最后我发现这是不可能的。因为如 果我指导一个人写架构设计，如果我可以给他们“具体的要求”，那结果就是我帮他们把整 个设计文档写出来，如果这个文档他们还看不懂，我就只能把代码给他写出来了。
对待管理者，我好像就只能解释为：“你只要信任我好了”。这句话说出来我自己都不好意 思。唯一能解释的只能是：我过去弄的产品都成功了，你觉得信得过，就继续让我做下去 ，你信不过，只能请你另请高明了。别让我给你讲技术原理，技术上你们肯定是不懂的， 科普的原理最多就是双方有个共同讨论的基础。
这个背后的锅，就在于：架构只是抽象，不是具象。如果你问道“具体要干什么”，那我已 经把代码写完啦，你哪里还需要架构设计呢？
好比前面说的，我们维持一组发行版，你让我写死这组发行版，那我一定会犯错的啊。我 在架构上决定：“我们需要有一组发行版”，而对于应该是哪一组发行版，我是要调资源去 调研，去跟踪，去更新，然后用这组发行版去规划其他的工具，优化，互联这些行为的设 计，你问我“具体什么发行版”，我也回答不了你啊。
所以，我常常用这种方法引导大家对这个问题的思考：我说，“那行，这个事情我不干了， 你们还觉得我们有什么问题吗？如果你觉得有，你觉得问题是什么？”，然后我就可以针对 这个问题建逻辑，一点点让大家发现：果然最后还是得用架构师说的方法才能解决这个问 题。
但很多时候，我得到的结果是“我们真没有什么问题”，你看，对于上上下下都这样想的团 队，我就真的不会担任这种团队的架构师了。因为这意味着，这个团队就算采纳我的意见 ，也是为我的欲望服务的，而我并没有我自己的欲望。
这是对于“信念”这个概念的另一个解释：架构设计是团队的共同信念，如果我们凝聚不起 这个团队的信念，那么架构是无法实施的。
这个部分，我想引入一个例子，具体看看所谓“信念”是怎么回事。
我负责鲲鹏解决方案的时候，定下一个基本的战略：“主线开源”。做这个战略的原因是， 当时我们有一个目标：我们要做一个生态出来，要让尽可能多的人可以用到我们的方案。 为了支持这个目标，我们要让我们目标客户群的人尽可能可以用我们的方案，而在发展 的初期，我们软件这边只有十几二十人，一个个客户去打，根本就没法打下来。所以上 分支的顶端，首先支持主线Linux，gcc，glibc这些软件的根分支，就是必然的选择。
但我们当时的情况是，代码是按私有风格写的，掌握在不同的部门的团队的人手中，这些 团队每个都有很多理由：“软件就得这样写”，“你说的那个修改其实是因为当时硬件有这么 一个问题……”，“你看代码都写好了，现在还改需要延期啊”，“这个地方我们也不知道为什 么写成这样，但这是经过XXX专家Review的”……特别是他们有个非常Solid的理由：你们搞开 源，能保证按时交付吗？什么时候才能上传成功？成功以后怎么维护？都开源了，我们的 针对对手的竞争力怎么保证？
你看，要找理由，永远都有理由。所以我当时的方法很简单：首先找到业务老大的支持， 投资上你们这些部门的代码都是我们投资的对吧？行，别的东西也别说了。统统给我，我 全部扔外面去。然后拉着我可以控制的人一起改这些代码，让主线接受它们，我自己也直 接改写了第一个驱动，直接先上传了。其他人还想来拿我的投资，都给我在主线上改，其 他代码你们都可以干，但我不付钱。
你看，这个事情运作了六七年。到现在，大家都说开源才是正确的路线，我们必须开源，“ 我们早说开源才能做成这件事了”，甚至我现在向更高的方向走了，还有人想来说服我：“ 开源才是我们基本策略”……试想一下，当初我们走这条路走了一半，由于某个原因没有搞定 ，最终先开发了一个针对鲲鹏的私有版本顶住，今天大家可能就会解释为“提供私有版本是 应有之义”，“我们的特性比开源那些版本好多了”……等等了，但一个私有版本会失去多少市 场，能不能撑下去，我看难说得很呐。
所以，架构这件事啊，你既可以走真正带领团队走向胜利的路线，你也可以为细节设计的 一切行为张目，成为细节设计的传声筒，吉祥物。这在表面上都是看不出来的。但失去了 信念，就没有了架构设计了。
真正的架构设计，就不可能“我没错”，就不可能和实施的团队没有冲突，所以还是那句话 ，这个工作如果对应的团队上下，没有决死的心，就不可能做。