.. Kenneth Lee 版权所有 2020
:Authors: Kenneth Lee :Version: 1.0
一个例子：架构的重要性和从权
昨天和人讨论一个方案，有人提了一个需求，要求访问设备的时候，从一个进程发请求， 从另一个进程收回应。我很奇怪为什么要这样做，因为这是同一个设备，收发之间是有匹 配关系的，如果分在两个进程中，这种匹配关系就需要通过进程间通讯实现，这个对开发 者并没有什么好处。需求的提出者也没有什么理由，他说你们要做到这一点只是需要允许 一个设备对应两个独立的页表而已，没有什么难的。
我强烈反对这个需求，从实现者的角度，能做就能讨好客户，所以我们团队中有人对此很 有兴趣，因为又有工开了，而且这个功能不难实现。一般实现者最喜欢这种，没有难度， 客户又喜欢的需求了。
但从架构师的角度，我是很反对这种看不到直接收益的需求的，“客户喜欢”这种东西轻飘 飘的东西，今天说喜欢，明天就可以翻脸不认，不能成为他的收益的“喜欢”，毛用没有。 做一个功能很容易，但这个功能会成为未来加功能的障碍，现在容易，将来就会麻烦。这 种需求不能接。
这个讨论到后面，突然另一个团队的人提供了另一个信息：这个一边发一边收的需求，软 件已经上了站点（用旧版本的硬件），有十几万个部署了。然后——我的态度马上一百八十 度转弯，坚定支持要在我们的新硬件中实现这个功能了。
我觉得这个例子挺典型的，很多人不知道细节是怎么改变决策的。这个就是。很多人在乎
决策，决策非常重要，但决策只在一个特例上生效，你学习这个决策，直接复用在其他决
策上，你以为你复用了经验，其实根本没有。这就是我在这个地方：
:doc:../花朵的温室/读史的方法 ，说到的，复盘历史的时候要多考量实际发生的事情
，少判断人家的细节，因为你根本不知道人家面对什么细节。决策对每个个例很重要，但
对于Pattern不重要。做具体的时候要重视决策，整理经验的时候决策本身并不值得参考。
这个例子还是一个典型的说明的为什么我们需要重视架构的例子。在产品的初期，通常你 往左走也行，往右走也行。如果你不考虑收益，看怎么方便怎么来，一旦他变成事实，这 个事实本身就变成这个毫无收益的约束的利益了，这时，你继续一条路走到黑是唯一的选 择，这时谈什么架构不架构的，就是浪费时间了。
我们重视架构，是怕我们最后没得选。