仓库源文

:Authors: Kenneth Lee :Version: 1.0

给非专业人士介绍架构设计工作

本文记录一段最近给不是做架构设计工作的普通人介绍什么是架构设计的表述。

架构设计是高层设计，是设计决策之上的决策。它为决策引入的额外的约束，这种约束不产生立即可见的效果。

用一个例子来辅助我们的表述。比如你买了一间新房子，有5个房间，你的床放哪里？书柜放哪里？马桶放哪里？（允许我先假定哪里都有下水管道之类的设施）微波炉放哪里？

如果按眼前的决策，刚进来的时候，哪里都能放。而且，这个判断最快了。但等你在床旁边安装了一个马桶。或者每个房间都安排了书柜，导致想放张大一点的床都放不下的时候，那就不由得感慨：早知道就……了。

那么提前决定买多大的房子，房子有多少房间，不同的房间是什么功能，就是架构设计工作要做的工作了。

从这个例子可以看到很多架构工作的特点：

第一，架构工作呈现为约束。你搬一个微波炉进来，看见有块空地，你觉得就应该放下来了。这毫无约束，但架构工作会要给你增加额外的约束——“你不能放这里，你必须放到那个贴着‘厨房’标签的的房间里”。所以架构工作总是讨人嫌，而且带来的好处人们总是说“这本来就是这样的”（“我自然”），因为这个微波炉本来就是他搬进去的呀。

第二，架构工作在初期都表现为不是非做不可的样子。就如同这个例子中，你买了300平的大房子，把你出租屋的那些破烂搬进来，全扔杂物房就可以了，不需要“设计”，但如果你不“设计”，后面你的房子可能就一塌糊涂，没法用。架构体现价值总出现在设计的后期，特别是所有的约束都被实施上来的时候。那时你会要求睡房里不要有潮湿的东西，书架旁边不要有带火的东西，电源线不能拉太远，洗衣机旁边必须可以排水之类的要求了。这些要求会互相冲突。

第三，有效的架构工作很难呈现被外行直接看到的模式或者表相。比如你找个神棍来给你的房子看风水，他煞有介事地用罗盘给你看半天，要求你每个房间里放个马桶，再养条金鱼进去。这也给你增加约束，也很专业的样子，你也无法事后说他不对：“虽然你每天都要闻着臭味睡觉，但这给你增加财运啊，你现在没有住医院，都是我给你摆的这个阵给你压着的”。虚假的架构师还喜欢用什么是自己做的来声称自己架构做得好，这也只是骗外行，因为架构好不好是看使用效果好不好（一定程度上表现为具体设计，特别是后期的具体设计和使用者自己的‘使用设计’是否容易做），而不是架构设计本身难不难，好不好看，多不多，好不好。

第四，架构无法被简单评价，因为每个架构的实施，都是独一无二的。架构也不是在选择不出任何问题的路线，架构只是在选择出问题比较少的路线。不出问题对你来说可能就是应该的，出了问题你都会说“早知道我就……”。你以为“你早知道就……”，其实你早那样，别的地方就该出毛病了。其实，大部分时候，你的房子住得还可以，没有出什么大问题，没有比起情况差不多的人来说还有些明显的优势，你的架构就可以了。只是大部分情况下，你也不会说架构设计师的什么好话。现在新冠病毒肆虐，你说早该隔离了，但假定早隔离保证这个病毒没有发作，你又该说当初的实施者吃饱了撑的了。

第五，架构无法被细致化，细致化的架构无法响应变化，比如你提前决定每个家具摆放的位置，如果某个家具不能到货，你就处理不了，你考虑所有的可能组合呢，这个工作量你无法承担。所以，架构不是一次性的工作，而是一个长期的过程，是一个设计，响应，再设计，再响应……的一个连续循环的过程。架构设计不能着眼眼前，也不能离开现实。很类似《道德经》的一个表述：豫兮若冬涉川，犹兮若畏四邻，俨兮其若客，涣兮若冰之将释，孰兮其若朴，旷兮其若谷，浑兮其若浊。架构远了不行，近了也不行。

第六，架构的工作很多都表现为不能一次成功，比如你为了装修，在外墙会建脚手架，事后你会拆掉它，你不能说这是“浪费时间”，架构功能常常通过这种脚手架工作体现出来的。它不呈现你想象的纯粹“指挥别人干活”的样子。

第七，架构只能靠建模进行逻辑验证，真正的验证只有实施的时候才知道。你单考虑水、电、通讯、家具的时候，可能逻辑是通的。但把它们放在一起，就不一定了，每个独立的建模都有边际效应，这种边际效应会互相影响。

最后，架构几乎无法回头，如果你一开始就没有做架构设计，房子里面的线拉得到处都是，每个房间都安排了一些排水设施之类的。或者你干脆买错了房子，这个位置根本没有公交系统，你还没车，这除了把房子卖掉重新找一间，你没有任何办法。

所以，架构这种东西，就像鸡汤，你说它没用，没有这种设计的时候，你就是老出问题，你觉得你“做了架构设计”，这只是个名义，它也不保证你不出问题。

架构设计的方法一般来自四个输入：

架构师在这个问题上的经验。比如他以前干过很多次这个事情，每个家庭都是有厨房、卧室、卫生间的，分开有好处，他在没有任何约束的时候，都会制造这个约束，这也确实会带来好处。因此，也不存在跨行业的架构设计，没有实际经验，哲学再好也不能成为架构师（当然，充神棍说不定可以）
高层逻辑建模。设计师会在一个很高的层次上构造一些逻辑链，保证这个逻辑链是自恰的，先用这些逻辑链建立约束。比如他会先问：你住在这里是为了什么？为了孩子上学的方便？那么上班怎么办？……这个逻辑通了，他才会讨论是否买车，房子如何设计车库书房这类的问题。
竞争对比。“别人怎么做的”，特别是“成功者是怎么做的”
反复的投资收益对比。设计师可能想的是一件事怎么做，而架构师想的是这件事的成本是多少，是否有钱做，能否找别人做。架构师还要观察每波投资的时机，让每波投资进入系统的时候，都能成为架构目标的助力（“动善时”）。所以成功的架构过程几乎不可能被复制，因为架构过程是和外部输入的时机紧密结合在一起的。房子要填一个小洞的时候，正好邻居有一些沙子要扔，这个时机，你没有准备，就没有办法利用上。软件更加是这样，使用方的投资的时候，你不成熟不会用你，你成熟了你不需要它，你要做好一这个软件，就要排布一个用户机会计划，靠这些用户催熟你的软件，这需要一个计较和设计。没有应用可以仅在实验室就成熟的。

另外，架构设计还会引入一些其他策略，比如“不为天下先”，每个架构设计引入的约束，都会被要求找到一个“收益”，这样虽然不能解释为什么，但减少了约束，就为未来响应变化增加了机会）。比如有人建议，“所有房间都要装排风机”，加排风机需要成本，但这个成本看不到收益，那么我们宁愿逻辑复杂一点，某些房间装排风机，某些房间不装，某些房间开窗户……我们也不能提前增加这个约束，这样我们才能在后面根据需要决定装排风机，还是保持密封用来存储东西之类的。“不为天下先”，是为未来增加需求留下余地。好的架构师极其反感没有收益的设计约束，而装样子的架构师喜欢引入无效的约束来证明“我也干了活”。

等等。

说到底，架构是在自由阶段增加约束，把未来你有可能遇到的约束提前统一在一起，以保证你设计的后期减少约束。架构师分析逻辑链总是不考虑“这是对的”，而是考虑“少了什么 ”。比如有人说，我在房间里放一张床，两个衣柜，一盏灯，是不是就可以了？架构师不考虑单独的床，衣柜是不是可以，架构师考虑的是总成本是多少，房间有多大，用来干什么，然后才决定一张床两个衣柜是不是对的。所以它总是从逻辑的全集来考虑问题。也正因为这样，架构师比一般具体设计的设计师更关注边界和边界上的需求和约束，因为一个简单的需求判断的不同，就会带来一个软件架构翻天覆地的变化。

最后给架构师们推荐一篇刚看完的论文： https://www.etsi.org/deliver/etsi_gr/NGP/001_099/009/01.01.01_60/gr_NGP009v010101p.pdf ，这基本是手把手教你怎么做架构设计的。里面有一个关于哥特建筑的例子（S4.1）和我这里举的例子非常接近。（我可不是抄它，我是写完本文才看的这个论文）